[Py-howto-checkins] CVS: pyhowto python-dev.tex,1.1,1.2

[A.M. K. <aku...@us...>]

Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv7437

Modified Files:
	python-dev.tex 
Log Message:
First bunch of rewrites, following GvR's feedback


Index: python-dev.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-dev.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** python-dev.tex	2001/07/06 02:30:12	1.1
--- python-dev.tex	2001/07/06 03:42:49	1.2
***************
*** 4,8 ****
  
  \title{Becoming a Python Developer}
! \release{0.01}
  \author{A.M. Kuchling}
  \authoraddress{\email{aku...@me...}}
--- 4,8 ----
  
  \title{Becoming a Python Developer}
! \release{0.02}
  \author{A.M. Kuchling}
  \authoraddress{\email{aku...@me...}}
***************
*** 13,20 ****
  
  This article shows you how to become one of the people who develop
! Python.  This means not just a person who develops \emph{using}
  Python, but a person who works on the core interpreter itself, and who
  contributes to the design of the language and the direction its
! development will take.
  
  \section{Why Work on Python?}
--- 13,22 ----
  
  This article shows you how to become one of the people who develop
! Python, meaning not just a person who develops \emph{using}
  Python, but a person who works on the core interpreter itself, and who
  contributes to the design of the language and the direction its
! development will take.   This document will try to motivate you
! to take up Python development, and provides a high-level 
! explanation of the development process, online forums,
  
  \section{Why Work on Python?}
***************
*** 27,32 ****
    for your purposes.
    
!   \item You like hacking on language interpreters.
!   (XXX is that a bit snarky?  not sure I phrased that well...)
  
    \item You want to gain experience as a developer on an open source
--- 29,34 ----
    for your purposes.
    
!   \item You like hacking on sizable software systems in general, or
!   language interpreters in particular.
  
    \item You want to gain experience as a developer on an open source
***************
*** 62,66 ****
  
    \item Python is over 10 years old, and its development process is
!   quite (XXX elaborate? evolved? mature?).  There's a public CVS
    repository.  There's a coding standard for both C and Python code.
    There's a framework for writing test suites.  There's infrastructure
--- 64,68 ----
  
    \item Python is over 10 years old, and its development process is
!   quite mature at this point.  There's a public CVS
    repository.  There's a coding standard for both C and Python code.
    There's a framework for writing test suites.  There's infrastructure
***************
*** 72,107 ****
  
    \item The most important skill Python can teach is the delicate
!   skill of working in a diverse group.  Python is developed by a group
!   of about 30 people, about 10 of whom are very active and make the
!   bulk of actual check-ins, and 20 of whom make more occasional
!   checkins and provide opinions and advice.  People oscillate between
!   the more active and less active groups in an irregular way,
!   depending on their free time, availability, and current interests.
!   You'll have to learn who's the right person to ask each question, 
!   how to convince the other developers of the usefulness of a patch, 
!   and how to offer helpful criticism.
  
    \item C programmers will find that the C source code for the Python
    interpreter is clearly written and easy to dive into.  It's
    relatively easy to familiarize yourself with the code, and to begin
!   writing extensions or making changes.
  
  \end{itemize}
  
! XXX should something be written about CPython / JPython / Stackless /
! Python.NET?  I only know about CPython.
  
  \section{How Python is Developed}
  
! Guido van Rossum has the title of Benevolent Dictator For Life, or
! BDFL.  In theory the BDFL makes all the decisions about what goes in
! to Python and what doesn't.  In practice, often the BDFL will defer to
! someone else's expertise in a specialized domain; for example, Tim
! Peters is the resident master of floating point arcana, Jeremy Hylton
! usually wrestles the Python compiler, and so forth.  Modules in the
! standard library are also often the responsibility of a particular
! individual who's the first choice to review patches or fix bugs in it,
! but anyone can modify any line of code at any time, and simple,
! obviously correct fixes can be applied by anyone.
  
  
--- 74,154 ----
  
    \item The most important skill Python can teach is the delicate
!   skill of working in a diverse group.  There's a core group of around
!   30 developers, roughly 10 of whom are very active and make the bulk
!   of actual check-ins, and roughly 20 of whom make more occasional
!   checkins and provide opinions and advice, but lots of people outside
!   this core group contribute significantly, too.  Developers oscillate
!   between the more active and less active groups in an irregular way,
!   depending on their free time, availability, and current interests;
!   sometimes other things have to take precedence over Python hacking.
!  
!   To work with this large and dispersed group, you'll have to learn
!   who's the right person to ask each question, how to convince the
!   other developers of the usefulness of a patch, how to offer helpful
!   criticism, and how to take criticism.
  
    \item C programmers will find that the C source code for the Python
    interpreter is clearly written and easy to dive into.  It's
    relatively easy to familiarize yourself with the code, and to begin
!   writing extensions or making changes.  
  
  \end{itemize}
  
! There are a few different implementations of Python.  
  
+ \begin{itemize}
+ 
+ \item The first
+ implementation, and the one in widest use, is the implementation
+ written in C.  This is the implementation usually meant when people
+ refer to ``Python'', but it's called CPython when people want to
+ distinguish between it and some other implementation.  
+ 
+ \item Stackless Python is a fork of CPython, but not one that diverges
+ very far from the main tree.  Its author, Christian Tismer, rewrote
+ the main interpreter loop of CPython to minimize its use of the C
+ stack; in particular, calling a Python function doesn't occupy any
+ more room on the C stack.  This means that, while CPython can only
+ recurse a few thousand levels deep before filling up the C stack and
+ crashing, Stackless can recurse to an unlimited depth.  Stackless is
+ also significantly faster than CPython (around 10\%), supports
+ continuations and lightweight threads, and has found a community of
+ highly skilled users, who use it to do things such as writing
+ massively-multiplayer online game.  The Stackless Python home page is
+ at \url{http://www.stackless.com}.
+ 
+ \item Jython is a reimplementation of Python, written in Java instead
+ of C.  (It was originally named JPython, but the name had to be
+ changed for stupid trademark reasons.)  Jython compiles Python code
+ into Java bytecodes, and can seamlessly use any Java class directly
+ from Python code, with no need to write an extension module first, as
+ is necessary for CPython.   The Jython home page is at
+ \url{http://www.jython.org}.
+ 
+ \item Python for .NET is an experimental implementation of Python for
+ the .NET Framework.  Currently this seems to be a research effort,
+ because while compiling Python to .NET bytecodes has been implemented,
+ and the resulting code works, making the resulting code \emph{fast}
+ seems to be a difficult problem.  See the Python.NET home page, at
+ \url{http://www.activestate.com/Initiatives/NET/Research.html}, to get
+ an overview of the current state of progress.
+ 
+ \end{itemize}
+ 
  \section{How Python is Developed}
  
! Guido van Rossum is the project's lead developer.  In recognition of
! this role, he's sometimes jokingly called the Benevolent Dictator For
! Life, or BDFL; the acronym is occasionally used in \email{python-dev}
! postings, especially in contexts such as ``that will require a BDFL
! pronouncement''.  In theory the BDFL makes all the decisions about
! what goes in to Python and what doesn't.  In practice, often Guido
! will defer to someone else's expertise in a specialized domain; for
! example, Tim Peters is the resident master of floating point arcana,
! Jeremy Hylton usually wrestles the Python compiler, and so forth.
! Modules in the standard library are also often the responsibility of a
! particular individual who's the first choice to review patches or fix
! bugs in it, but anyone can modify any line of code at any time, and
! simple, obviously correct fixes can be applied by anyone.
  
  
***************
*** 173,179 ****
  
  All the PEPs are available online at
! \url{http://python.sourceforge.net/peps/}.  PEP 1, ``PEP Purpose and
  Guidelines'' (online at
! \url{http://python.sourceforge.net/peps/pep-0001.html}), explains the
  purpose of PEPs, their life cycle, and the prescribed format for a
  PEP.  Read it before beginning to write a PEP.
--- 220,226 ----
  
  All the PEPs are available online at
! \url{http://www.python.org/peps/}.  PEP 1, ``PEP Purpose and
  Guidelines'' (online at
! \url{http://www.python.org/peps/pep-0001.html}), explains the
  purpose of PEPs, their life cycle, and the prescribed format for a
  PEP.  Read it before beginning to write a PEP.
***************
*** 191,195 ****
  bugs and fix or close them.  PEP 3, ``Guidelines for Handling Bug
  Reports'' (online at
! \url{http://python.sourceforge.net/peps/pep-0003.html}), explains the
  procedures for handling bugs once they've been reported.
  
--- 238,242 ----
  bugs and fix or close them.  PEP 3, ``Guidelines for Handling Bug
  Reports'' (online at
! \url{http://www.python.org/peps/pep-0003.html}), explains the
  procedures for handling bugs once they've been reported.
  
***************
*** 203,216 ****
  to be checked in.
  
! Context diffs are preferred, so generate the patch using \code{diff
! -C2}.  (XXX is that correct?)  Patches to C code should follow
! Python's standard style, described at \url{XXX}.  (XXX Is there a
! description of it anywhere?)  If you're using Emacs to edit your C
! code, cc-mode supports Python's standard style; run the 'c-set-style'
! command and select the 'python' style.  Code written in Python should
! follow the style in Guido's style guide, at
! \url{http://www.python.org/doc/essays/styleguide.html}.
  
  
  \section{Mailing Lists}
  
--- 250,274 ----
  to be checked in.
  
! Some conventions that should be followed when preparing a patch are:
  
+ \begin{itemize}
+   \item Context diffs are preferred, so generate the patch using \code{diff
+ -c}.  
+ 
+   \item Patches to C code should follow Python's standard style,
+ described in PEP 7, ``Style Guide for C Code'', at 
+ \url{http://www.python.org/peps/pep-0007.html}.  If you're
+ using Emacs to edit your C code, cc-mode supports Python's standard
+ style; run the \code{c-set-style} command and select the 'python' style.
+ 
+ \item For patches to Jython, the standard formatting and indentation style
+ for Java code should be followed. 
+ 
+ \item Code written in Python should follow the style in Guido's style guide,
+ described in PEP 8, ``Style Guide for Python Code'',
+ (\url{http://www.python.org/peps/pep-0008.html}).  
  
+ \end{itemize}
+ 
  \section{Mailing Lists}
  
***************
*** 222,231 ****
  The most general and most high-traffic list is \email{python-list}
  (\url{mail.python.org/mailman/listinfo/python-list}), which is
! gatewayed to the Usenet newsgroup \newsgroup{comp.lang.python}.  Pretty
! much anything Python-related is fair game for discussion, and the
! group is fairly tolerant of off-topic digressions.  It's quite
  possible to have a reasoned discussion of programming languages other
  than Python; in the past there have been lengthy and informative
! threads about Lisp, floating point, and XXX, for example.
  
  \email{python-list} mostly has discussion of development in Python,
--- 280,290 ----
  The most general and most high-traffic list is \email{python-list}
  (\url{mail.python.org/mailman/listinfo/python-list}), which is
! gatewayed to the Usenet newsgroup \newsgroup{comp.lang.python}.
! Pretty much anything Python-related is fair game for discussion, and
! the group is fairly tolerant of off-topic digressions.  It's quite
  possible to have a reasoned discussion of programming languages other
  than Python; in the past there have been lengthy and informative
! threads about Lisp, floating point, and the principles of good
! software design, for example.
  
  \email{python-list} mostly has discussion of development in Python,
***************
*** 236,248 ****
  frequently-made ones that are always rejected, but there have been
  other times when suggestions turned into a PEP, and then into a new
! feature.  (XXX Argh! I had an example of this, but forgot it!)
  
  Rudeness and personal attacks, even in reaction to blatant flamebait,
! are strongly frowned upon.  Either ignore such postings, quietly plonk
! the offending poster in your killfile or mail filters, or write a
! sharp but still-polite response, but resist the urge to flame back.
! Generally \email{python-list} is a high-signal, low-noise group.  The
! traffic is also quite high, currently running at around 150 posts per
! day.
  
  \subsection{python-announce}
--- 295,309 ----
  frequently-made ones that are always rejected, but there have been
  other times when suggestions turned into a PEP, and then into a new
! feature.  % XXX Argh! I had an example of this, but forgot it!
  
  Rudeness and personal attacks, even in reaction to blatant flamebait,
! are strongly frowned upon.  People may strongly disagree on an issue,
! but usually discussion remains civil, though vehement.  In case of an
! actual flamebait posting, you can ignore it, quietly plonk the
! offending poster in your killfile or mail filters, or write a sharp
! but still-polite response, but at all costs resist the urge to flame
! back.  Generally \email{python-list} is a high-signal, low-noise
! group.  The traffic is also quite high, currently running at around
! 150 posts per day.
  
  \subsection{python-announce}
***************
*** 307,320 ****
  concise way to express opinions in a straw poll, and the result isn't
  binding in any way.  The BDFL will take note of the reaction to a
! proposal, but is free to ignore it.  (While the BDFL can ignore
  community reaction, I can't think of an instance where he's actually
! done so.  Perhaps the closest one is the \code{print >>} statement,
! where everyone was roughly evenly divided between liking it and hating
! it.  It was added to the language in Python 2.0.)
! 
! \section{Tour of the Python Distribution}
  
! XXX List significant directories and source files; point to relevant
! documents...
  
  \end{document}
--- 368,387 ----
  concise way to express opinions in a straw poll, and the result isn't
  binding in any way.  The BDFL will take note of the reaction to a
! proposal, but is free to ignore it.  While the BDFL \emph{can} ignore
  community reaction, I can't think of an instance where he's actually
! done so in the face of united disapproval by the community.  The
! closest case to that might be the \code{print >>} statement, where
! everyone turned out to be divided 50/50 between liking it and hating
! it.  Guido exercised his right to decide, and the feature was added to
! the language in Python 2.0.  Some people still hate it; some people
! who argued against it, such as this author, have now grown sneakily
! fond of it.  
! 
! %\section{Tour of the Python Distribution}
! %
! %XXX List significant directories and source files; point to relevant
! %documents...
  
! % XXX write a conclusion
  
  \end{document}