|
From: A.M. K. <aku...@us...> - 2001-07-06 03:42:52
|
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}
|