[Python-Dev] python-dev Summary for 2003-09-01 through 2003-09-15 [draft]

Brett C. bac at OCF.Berkeley.EDU
Fri Sep 19 02:35:01 EDT 2003

Not planning on rushing this summary out the door; most likely will send 
it out on Sunday.

So have a read and show me why I should not pass the writing test I have 
to take next month that is supposed to prove I am a competent writer.


python-dev Summary for 2003-09-01 through 2003-09-15
This is a summary of traffic on the `python-dev mailing list`_ from 
September 1, 2003 through September 15, 2003.  It is intended to inform 
the wider Python community of on-going developments on the list.  To 
comment on anything mentioned here, just post to `comp.lang.python`_ (or 
email python-list at python.org which is a gateway to the newsgroup) with a 
subject line mentioning what you are discussing. All python-dev members 
are interested in seeing ideas discussed by the community, so don't 
hesitate to take a stance on something.  And if all of this really 
interests you then get involved and join `python-dev`_!

This is the twenty-fifth summary written by Brett Cannon (with school 
looming on the horizon).

All summaries are archived at http://www.python.org/dev/summary/ .

Please note that this summary is written using reStructuredText_ which 
can be found at http://docutils.sf.net/rst.html .  Any unfamiliar 
punctuation is probably markup for reST_ (otherwise it is probably 
regular expression syntax or a typo =); you can safely ignore it, 
although I suggest learning reST; its simple and is accepted for `PEP 
markup`_ and gives some perks for the HTML output.  Also, because of the 
wonders of programs that like to reformat text, I cannot guarantee you 
will be able to run the text version of this summary through Docutils_ 
as-is unless it is from the original text file.

.. _PEP Markup: http://www.python.org/peps/pep-0012.html

The in-development version of the documentation for Python can be found 
at http://www.python.org/dev/doc/devel/ and should be used when looking 
up any documentation on something mentioned here.  PEPs (Python 
Enhancement Proposals) are located at http://www.python.org/peps/ .  To 
view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  Reported bugs 
and suggested patches can be found at the SourceForge_ project page.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: 
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html

.. contents::

.. _last summary: 

Summary Announcements
Summary is nice and short this time.  More people went on vacation 
(although Martin came back and so that helped to pick up the traffic a 
little).  I skipped covering some threads that are due for PEPs since 
those will be more in-depth then anything I write.

I should give fair warning that starting on the 22nd of September I will 
begin school.  I am hoping that it will not be difficult and I will have 
a carefree time in school.  But if my workload becomes a burden the 
Summaries might suffer.  I hope they don't, though, and I am going to do 
my best to make sure that doesn't happen.

If It Isn't Documented, Is It a Secret?
Some undocumented methods in readline were discovered by Philip Eby.  He 
asked if this was on purpose and whether he should submit a bug report 
on the lack of documentation.  Guido told him to go ahead and submit the 
bug report.

If you ever find something undocumented in the Python source code and 
there is nothing suggesting the code is meant to be hidden from the user 
(it's for internal use, a comment says it is experimental, etc.), then 
please file a bug report!

Contributing threads:
   - `Undocumented functions in 'readline' module 

"You are more trouble than you are worth!", screamed the micro release 
to the new feature
The topic of what should be backported for micro releases (with Python 
2.3.1 looming on the horizon) came up.  Originally minor improvements 
were allowed in if they didn't break backwards compatibility.  And of 
course bugfixes have been as well as long as they didn't break code that 
came to depend on the buggy behavior (really depends on how long the 
bugginess has been there and how well-known it is).

But then the point of OS X 10.3 possibly becoming the largest install 
base of Python of any version (it will be 2.3) came up.  With rough 
estimates being thrown around of 5 million installs in about a year's 
time, the point that making it difficult to run Python 2.3.x code on 
that size of an install base would be bad.  For instance, if some small 
new feature was added to 2.3.1 then any code using that feature would 
not be able to run on a virgin install of OS X 10.3 (and considering 
that this is Mac it should not be expected that most users will want to, 
let alone know how, to add a secondary install of Python since the 
original is used by the OS and thus should not be overwritten).  It 
looks like a more conservative patching scheme will be taken with micro 

Bytecode will also continue to work between releases.  Guido has always 
unofficially held that position but now it has been vocalized.

Contributing threads:
   - `Documenting branch policy 

PyPy "Berlin" sprint (29th Sep - 4th Oct 2003)
Just what the title says: there is going to be a sprint_ for PyPy_ in 
Berlin from September 29 to October 4.  Read the email for more specific 
details on goals and such.

.. _sprint: http://www.python.org/cgi-bin/moinmoin/SprintPlan
.. _PyPy: http://codespeak.net/pypy/index.cgi?home

Contributing threads:
   - `PyPy "Berlin" sprint (29th Sep - 4th Oct 2003) 

Away with you ambiguous imports!
A discussion on how to create a hierarchy of loggers in the standard 
library led to the idea of having a way to cause an import to come 
directly from the standard library and thus remove any ambiguity from a 
relative import grabbing a similarly named module from the local package.

Barry Warsaw he was thinking of writing a PEP on this idea.

Contributing threads:
   - `Consistent logging in the standard library 

Quick: want to give a Python talk at Linuxworld NY?
If you are interested in what the title asks, then read the email for 
some details.

Contributing threads:
   - `Quick: want to give a Python talk at Linuxworld NY? 

Be careful about saying something is "easy"
A word of advice about saying something is "easy" on python-dev: if you 
say that you should make sure you can back up that claim because 
otherwise you will be told to write the "easy" patch and that will be 
the end of the discussion.

Contributing threads:
   - `Making python C-API thread safe (try 2) 

Parsing dates for datetime
There was some talk about coming up with some code to parse dates for 
the datetime module.  It was kind of hand-wavy since there are multiples 
chunks of code that can do that in the standard library.

If you have an opinion on this (or anything for that matter), make sure 
to make a post to `comp.lang.python`_ about it.

Contributing threads:
   - `datetime issues 

More information about the Python-Dev mailing list