python-dev Summary for 2003-07-01 through 2003-07-31
Brett C.
brett@python.org
Sun, 10 Aug 2003 14:23:57 -0700
python-dev Summary for 2003-07-01 through 2003-07-31
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from July=20
1, 2003 through July 31, 2003. It is intended to inform the wider=20
Python community of on-going developments on the list. To comment on=20
anything mentioned here, just post to python-list@python.org or=20
`comp.lang.python`_ with a subject line mentioning what you are=20
discussing. All python-dev members are interested in seeing ideas=20
discussed by the community, so don't hesitate to take a stance on=20
something. And if all of this really interests you then get involved=20
and join `python-dev`_!
This is the twenty-first/twenty-second summary written by Brett Cannon=20
(who is still learning how to count; gave the wrong summary count last=20
month).
All summaries are archived at http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which=20
can be found at http://docutils.sf.net/rst.html . Any unfamiliar=20
punctuation is probably markup for reST_ (otherwise it is probably=20
regular expression syntax or a typo =3D); you can safely ignore it,=20
although I suggest learning reST; its simple and is accepted for `PEP=20
markup`_ and gives some perks for the HTML output. Also, because of the=20
wonders of programs that like to reformat text, I cannot guarantee you=20
will be able to run the text version of this summary through Docutils_=20
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=20
at http://www.python.org/dev/doc/devel/ and should be used when looking=20
up any documentation on something mentioned here. Python PEPs (Python=20
Enhancement Proposals) are located at http://www.python.org/peps/ . To=20
view files in the Python CVS online, go to=20
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .
.. _python-dev: http://www.python.org/dev/
.. _python-dev mailing list:=20
http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=3Dcomp.lang.pytho=
n
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. contents::
.. _last summary:=20
http://www.python.org/dev/summary/2003-06-01_2003-06-30.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Summary Announcements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
It's experimentation time again! In preparation for having to cut down=20
on the breadth of the summary thanks to my return to school I am=20
starting this summary off as the inaugural release of the new format.=20
Pretty much everything is going to change somewhat.
First, though, I think I should explain my new viewpoint towards the=20
summaries that I am taking. In order to continue to provide a certain=20
level of quality and coverage while retaining my personal sanity and to=20
not feel like the Summaries are a job instead of something I do for fun=20
and to help others, I am going to start viewing the Summaries more from=20
a journalistic perspective than a historical one. Before I felt more=20
like a historian that was summarizing *everything* that happened on=20
python-dev. Now, though, I am be more like a journalist, covering only=20
the pertinent ideas. This also allows me to inject more of my=20
personality into my writing.
But what ramifications does this new perspective cause? Well, it will=20
dictate what I do and do not summarize. I plan on several types of=20
discussions to be covered in the Summaries. One is new features of the=20
language. This is so people can know about them ASAP and thus comment=20
on them. Since practically any feature mentioned here is experimental=20
there is a chance to remove it if a community movement mounts. I will=20
also cover any major thinking on the future of Python. I have always=20
wished there was an easy way to see what pie-in-the-sky ideas python-dev=20
was thinking of in the back of our collective mind; the summaries might=20
as well fill this desire. And of course any random discussion that is=20
large, important, and/or complex will continue to be covered.
In terms of formatting and layout, that will also change along with the=20
new viewpoint. I am planning to follow something more along the lines=20
of the Perl's `This Week...=20
<http://dev.perl.org/perl6/list-summaries/>`__; yes, I am taking a cue=20
from Perl but AM Kuchling and Michael Hudson originally used this format=20
as well. This means titles of summary sections will more reflect the=20
topic being summarized rather than the specific thread(s). I will=20
continue to list all of the threads that contributed to the summary,=20
though, for reference purposes. I feel this will be beneficial since I=20
know I have personally looked back into the Summary archives and had a=20
hard time finding something specific since the subject of a thread does=20
not always match the topic of discussion; if I can't find something and=20
I know about what month it happened I can only imagine what everyone=20
else has had to go through to find something!
I am removing the Quickies section from the Summaries. This section was=20
nice to have, but it just ate away at my time. This also goes along=20
with the new viewpoint.
I am sure not everyone will be happy with this change, that's fine. But=20
if someone out there *truly* hates the direction I am going then they=20
can step forward and take the reigns from me. But as I have stated=20
before, the fine print on me giving up this post is that the person who=20
takes over must be as thorough as I *used* to be; I can do the summaries=20
in a half-assed fashion as well as anyone else.
Enough of that topic. One thing I would like to mention is that the=20
`Python Software Foundation`_ can now accept donations through PayPal.=20
Specifics can be found at http://www.python.org/psf/donations.html . It=20
would be great if people could donate since the PSF is more than just a=20
non-profit to hold the Python intellectual property. One of the goals=20
of the group is to get enough money to do something like the Perl=20
Foundation does and sponsor someone to hack on Python for a living for a=20
set amount of time. Right now we are a ways off from having that kind=20
of revenue, but there is no reason why we can't. Heck, if we can just=20
get enough to sponsor one person to do full-time Python hacking for a=20
week it would be beneficial. Or better yet, the PSF could sponsor one=20
of their own members to write a summary of the python-dev mailing list=20
for the betterment of the community. =3D)
.. _PSF:
.. _Python Software Foundation: http://www.python.org/psf/
.. _PayPal: http://www.paypal.com/
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Summaries
=3D=3D=3D=3D=3D=3D=3D=3D=3D
--------------------------
Python 2.3 final released!
--------------------------
In case for some odd reason you didn't know, Python 2.3 final has gone=20
out the door. The team managed to meet the goal of getting it out by=20
the end of the month so that Apple_ can use a final release instead of a=20
release candidate in OS X 10.3 (a.k.a. Panther).
The goal of this release was to continue to improve Python without=20
adding any new keywords. This was met while speeding things up, fixing=20
bugs, adding to the standard library, and adding some new built-ins. To=20
find out what is new or has changed look at the changelog at=20
http://www.python.org/2.3/highlights.html or `What's New in Python 2.3`_.
As with all software, there are bound to be bugs. What bugs that are=20
known are listed at http://www.python.org/2.3/bugs.html . If you find=20
bugs not listed there, please report them on the SourceForge bug tracker=20
at http://sourceforge.net/tracker/?group_id=3D5470&atid=3D105470 . Runni=
ng=20
the regression test suite (details on how to do this is covered in the=20
documentation for the 'test' package as found at=20
http://www.python.org/doc/current/lib/module-test.html) is always=20
appreciated.
Contributing threads:
- `Problem with 2.3b2 tarfile?`__
- `MacPython 2.3b2 binary installer for MacOSX`__
- `Running tests on freebsd5`__
- `Python 2.3 release schedule update`__
- `Vacation and possibly a new bug`__
- `Doc/ tree closes at noon, US/Eastern`__
- `I've tagged the tree`__
- `cygwin errors`__
- `test_strptime; test_logging; test_time failure`__
- `2.3rc1 delayed`__
- `Python 2.3 release candidate 1`__
- `post-release festivities`__
- `New branch for r23c2 work`__
- `Serious CallTip Bug in IDLE`__
- `MacPython-OS9 test failures`__
- `Doc/ tree on trunk closed`__
- `Cutting the 2.3c2 tonight 8pm EDT`__
- `Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827`__
- `RELEASED Python 2.3c2`__
- `2.3rc2 IDLE problems on a Win2000sp3 box`__
- `Draft: 2.3 download page`__
- `Last priority >=3D 7 bug for Python 2.3`__
- `CVS Freeze`__
- `RELEASED Python 2.3 (final)`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036669.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036732.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036762.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036783.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036845.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036892.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036899.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036900.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037117.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036921.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036940.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036941.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037024.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037134.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037144.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037193.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037200.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037207.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037208.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037237.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037284.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037311.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037315.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037319.html
.. _Apple: http://www.apple.com/
.. _What's New in Python 2.3: http://www.python.org/doc/2.3/whatsnew/
-------------------------------------------
String Exceptions Going Extinct, Eventually
-------------------------------------------
It has been brought up several times before, but things are now moving=20
along to eventually deprecate string exceptions (e.g., ``raise "this=20
string exception"``). they have now been removed from the tutorial to=20
prevent people new to the language from picking up habits that will=20
eventually be impossible to perform.
As for when the impending deprecation will occur only Guido knows. The=20
chances of it coming before Python 3, though, is most likely small.
Contributing threads:
- `String exceptions in the Tutorial`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036665.html
--------------------------------------------------------
Someday, My CVS updates Will Succeed on the First Try...
--------------------------------------------------------
We all know that SourceForge_ does not have the snappiest or most=20
reliable CVS_ servers in the world; Python 2.3 final's release was=20
targeted a few days earlier than needed for Apple_ in case SF's CVS went=20
down. Solutions to how to deal with this problem have come up.
One specific problem that people are trying to solve is the poor=20
anonymous pserver access. SF has their CVS servers set up so that=20
authorized CVS commands take priority over anonymous ones and thus when=20
there is heavy traffic anonymous CVS basically shuts down. Martin v.=20
L=F6wis put up a link to a nightly tarball at=20
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz of the CVS=20
HEAD. perl.org has provided a nightly tarball as well at=20
http://cvs.perl.org/snapshots/python/ for quite some time now. The=20
suggestion of having a read-only version of the CVS tree on python.org=20
was came up, but how to properly do it and who would set it up was not=20
settled.
And of course there is always the option of moving CVS off of SF=20
entirely. There is one offer on the table with the caveat that we need=20
to know what kind of bandwidth demands we would have. Another offer=20
sprung up this month from Michal Wallace to host our CVS at=20
http://www.versionhost.com/ with the hitch that it requires an external=20
Python script for secure connections (as specified at=20
http://www.sabren.net/code/cvssh/ ).
Contributing threads:
- `alternate pserver access for python CVS?`__
- `[fwd] SourceForge status`__
- `Volunteering to help with pserver cvs on python.org`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036699.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036708.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036860.html
.. _SourceForge: http://www.sf.net/
.. _CVS: http://www.cvshome.org/
---------------------
Which License to Use?
---------------------
Domenico Andreoli wanted to donate `python-crack`_ to the PSF_ and=20
wondered what steps would be necessary to do so. He was first told that=20
the module would not be included in Python since it is too specific.=20
Secondly, it was suggested he not choose the PSF license. Instead, he=20
was told that he should use the BSD or MIT license (both of which can be=20
found at http://www.opensource.org/licenses/index.php); clean, simple=20
licenses that are not viral like the GPL but are GPL-compatible. This=20
is so that it can be included in any software that uses Python.
Contributing threads:
- `donating python-crack module`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036712.html
.. _python-crack: http://savannah.nongnu.org/projects/python-crack
----------------
Not Quite ANSI C
----------------
Every so often someone runs Python against a C code checker and notices=20
failures that get reported to us. Often, though, we have to tell the=20
person that we already know of the failures and that there is nothing to=20
worry about. This time it was failures under Purify. We have also=20
received reports of failures under Valgrind_ which are spurious. The=20
language isn't even fully ANSI C compliant, but as Tim Peters said,=20
"it's not possible to write a useful and portable memory allocator in=20
100% standard ANSI C" among other reasons why strict ANSI C conformity=20
is broken. The only major violations in the code are casting a pointer=20
to a unsigned integer type and assuming "that whatever memory protection=20
gimmicks an OS implements are at page granularity" which is a minor sin=20
at best. There is also some cases of accessing memory without proper=20
casting.
Contributing threads:
- `Invalid memory read in PyObject_Free`__
- `strict aliasing and Python`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036717.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036898.html
.. _Valgrind: http://developer.kde.org/~sewardj/
---------------------------------------
Shadowing Built-ins is Becoming a No-No
---------------------------------------
Before the code was removed, Python 2.3 raised a DeprectionWarning when=20
you overshadowed a built-in in a module from outside the module's actual=20
code. What this means is that doing something like::
import mod
mod.reload =3D 42
would raise the warning. Now doing ``reload =3D 42`` in the module itsel=
f=20
would still be allowed. The idea was (and still is) that the compiler=20
can know when a built-in is shadowed in a module when it compiles the=20
module's code. But allowing someone to overwrite a built-in externally=20
means that the compiler cannot make any assumptions that built-ins will=20
forever reference the actual built-in code. This is unfortunate since=20
if shadowing externally was made illegal the compiler can reference the=20
built-in code directly and skip some steps for a nice speed-up.
This is why there was code to warn against this initially. But it=20
didn't work well enough to be left in Python 2.3 so it has been removed.=20
But this restriction will most likely be enforced at some point so it=20
is something to keep in mind.
Contributing threads:
- `Deprecation warning 'assignment shadows builtin'`__...
- `DeprecationWarning: assignment shadows builtin`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036767.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036879.html
------------------------
Must...Start...Faster...
------------------------
While Python 2.3 sees up to a 30% speed increase over 2.2, it still=20
starts up slower. Originally it was believed that it was because of the=20
importation of the re module. Marc-Andr=E9 Lemburg applied a patch that=20
tried to minimize its possible importation at startup but it was still sl=
ow.
Jeremy Hylton pointed out that 2.2.3 imported re so that probably was=20
not the problem. One thing that is different, though, is the automatic=20
inclusion of warnings, codecs, and the ability to do zip imports. These=20
three things pull more modules and all of this leads to a longer startup=20
time. There is also the importation of distutils thanks to the site.py=20
module, but that only occurs if you execute in a build directory.
Including zip imports also got attacked for the number of failed checks=20
for files it can incur. But it is believed this is not as bad as all of=20
the extra imports being done now and Just van Rossum said he would try=20
to cut down the unneeded checks in the future.
Contributing threads:
- `2.3 startup speed?`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036815.html
---------------------
The World and Numbers
---------------------
People might not be aware of it, but locale.setlocale never changes the=20
LC_NUMERIC locale value. This is so that 'str' and 'float' can return=20
and receive numbers in a consistent way in source code. This causes a=20
problem, though, for people in locales that do not use a period for a=20
decimal point. If you had your locale set to Brazilian and tried to=20
pass the string "3,14" to 'float' it would fail even though that is a=20
legitimate number representation for your locale.
The suggestion became to have a locale-agnostic version of 'str' and=20
'float' in the locale module for people to use when they needed such=20
functionality. It has now reached the stage of a rough draft PEP as=20
found at http://mail.python.org/pipermail/python-dev/2003-July/036996.htm=
l .
Contributing threads:
- `LC_NUMERIC and C libraries`__
- `Be Honest about LC_NUMERIC`__
- `RE: [Spambayes] Question (or possibly a bug report)`__
__ http://mail.python.org/pipermail/python-dev/2003-July/036869.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036996.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037178.html
---------------
Zippin' Nothin'
---------------
The built-in 'zip' function in Python 2.3 raises TypeError when given no=20
arguments. This causes problem when you do ``zip(*args)`` and args is=20
empty. So for Python 2.4 'zip' with no arguments will return an empty li=
st.
Contributing threads:
- `zip() in Py2.4`__
__ http://mail.python.org/pipermail/python-dev/2003-July/037332.html
--------------------------------
A Syntax For Function Attributes
--------------------------------
An old debate (or at least old in terms of it having popped up multiple=20
times during the tenure of your author) has been ways of enhancing=20
function definitions. Previously it has been over ways to make defining=20
classmethod and its ilk in a cleaner fashion along with properties (past=20
summaries on this can be found at=20
http://www.python.org/dev/summary/2003-01-16_2003-01-31.html#extended-fun=
ction-syntax=20
and=20
http://www.python.org/dev/summary/2003-02-01_2003-02-15.html#extended-fun=
ction-syntax=20
).
What made the discussion slightly different this time, though, was the=20
focus was on function attributes specifically. One idea was to tweak=20
Michael Hudson's bracket syntax for method annnotations to allow for=20
function attributes; ``def foo() [bar=3D42]: pass``. Another suggestion=20
was to take the dictionary-like connection even farther; ``def foo()=20
{bar=3D42}: pass``. There was no clear winner in either case partially=20
because this discussion flared up towards the end of the month.
It was also pointed out that using Michael Hudson's method descriptors=20
you could come up with a wrapping function that handled the situation::
def attrs(**kw):
def _(func):
for k in kw:
setattr(func, k, kw[k])
return func
return _
def foo() [attrs(bar=3D42)]: pass
Perk of this is it does not lead to any special syntax just for function=20
attributes. One drawback, though, as pointed out by Paul Moore is that=20
this makes the method annotation idea a little to liberal and open to=20
hackish solutions like this that will lead to abuse. This was not a=20
huge worry, though, since almost anything can be abused and this is all=20
already doable now, just without a nice, clean syntax.
Contributing threads:
- `A syntax for function attributes?`__
__ http://mail.python.org/pipermail/python-dev/2003-July/037338.html