python-dev Summary for 2003-08-01 through 2003-08-15
Brett C.
brett@python.org
Mon, 18 Aug 2003 14:49:25 -0700
python-dev Summary for 2003-08-01 through 2003-08-15
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from=20
August 1, 2003 through August 15, 2003. It is intended to inform the=20
wider Python community of on-going developments on the list. To comment=20
on 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-third summary written by Brett Cannon (about to move=20
for the umpteenth time).
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-07-01_2003-07-31.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
Well, Michael Chermside responded to my question from the last summary=20
about whether the new format and style of the Summaries was good. Once=20
again a single person has led to how the summaries will be handled. You=20
guys need to speak up (although I like the side that won this time =3D)!
I am playing with layout once again. This time I am changing how the=20
"contributing threads" lists are formatted. I know some of you hate=20
inlined links in reST markup, but when these lists become huge it=20
becomes really hard to keep track of the URIs when I have to list them=20
away from the actual item on a separate line below the list of thread nam=
es.
With `Python 2.3` out the door bug reports have started to come in.=20
Work on 2.3.1 has begun. Please keep running the regression tests=20
(easiest way is to run either ``make test`` or run regrtest.py in the=20
test package; see the docs for the test package for help).
On a personal note, if anyone knows of any Python users and such in the=20
San Luis Obispo area of California, drop me a line at brett at python.org.
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Summaries
=3D=3D=3D=3D=3D=3D=3D=3D=3D
-----------------------------------------
Python user helping Parrot? Treacherous!
-----------------------------------------
Michal Wallace decided to get AM Kuchling's `previous work=20
<http://www.amk.ca/conceit/parrot.html>`__ on getting Python code to run=20
on the Parrot_ virtual machine (which is what Perl 6 will use). Well,=20
the rather nutty fellow managed to get pretty damn far with it as shown=20
at http://pirate.versionhost.com/viewcvs.cgi/pirate/ . Michal was=20
actually almost done with handling pure Python code and was getting=20
ready to try to figure out how to get Parrot to handle C extension=20
modules with that being the biggest sticking point.
Since Parrot is not Python it does not have a parser for Python code;=20
problem if your code has an exec statement. This turned out to not be a=20
worry, though, since there are pure Python parsers out there.
All of this has direct relevance to python-dev because of the bet=20
between Guido and Dan Sugalski, developer of Parrot. The rules are=20
outlined at http://www.sidhe.org/~dan/blog/archives/2003_07.html#000219=20
. What is going to happen at OSCON 2004 is a benchmark program written=20
in pure Python will be run using a CVS checkout of Python against a=20
Parrot (after converting the bytecode to Parrot's own bytecode)=20
checkout; slowest implementation's author gets a pie in the face, buy=20
the winner's dev team a round of beer, and $10.
So why have this bet? This was discussed and basically came down to=20
finding out whether Parrot really can run Python fast. Parrot wants to=20
be the VM for as many languages as possible, including Python. This=20
acts as a way to motivate people to see how feasible this is.
And don't think that the CPython interpreter will disappear if Parrot=20
wins. Dan pointed out that even if he did win the bet that Guido would=20
probably want to keep CPython around since that is under his control and=20
allows testing out new language features much easier then having to deal=20
with Parrot and an external dev team. In other words, let other people=20
worry about forcing a Python-shaped peg into a Parrot-sized hole.
.. _Parrot: http://www.parrotcode.org/
Contributing threads:
* `pirate (python+parrot)=20
<http://mail.python.org/pipermail/python-dev/2003-August/037407.html>`__
----------------------------------------------------
python-mode gets its own SF project; Vim users laugh
----------------------------------------------------
Barry Warsaw, citing lack of time to "properly maintain python-mode.el",=20
has created a SourceForge project for the Emacs mode at=20
http://sf.net/projects/python-mode . This means all bug reports,=20
patches, etc. should be done at that project.
Martin v. L=F6wis suggested removing `python-mode.el`_ from Python itself=
=20
and to get it distributed with Emacs_ and XEmacs_. This way there does=20
not have to be any synchronization between the new SF project and the=20
Python CVS tree. As of right now, though, python-mode.el is still in=20
the Python CVS.
And to give equal billing to Vim_, my code editor of choice, since it=20
does not get as much coverage on python-dev as XEmacs does, here are=20
some scripts you might want to check out:
taglist.vim : http://vim.sourceforge.net/scripts/script.php?script_id=3D2=
73
"provides an overview of the structure of source code files" by=20
splitting the window.
python_fold.vim :=20
http://vim.sourceforge.net/scripts/script.php?script_id=3D515
"This script uses the expr fold-method to create folds for python=20
source code."
vimDebug : http://vim.sourceforge.net/scripts/script.php?script_id=3D663
" integrates your favorite debugger with vim."
.. _python-mode.el: http://sf.net/projects/python-mode
.. _Emacs: http://www.gnu.org/software/emacs/emacs.html
.. _XEmacs: http://www.xemacs.org/
.. _Vim: http://www.vim.org/
Contributing threads:
* `New python-mode project at SourceForge=20
<http://mail.python.org/pipermail/python-dev/2003-August/037410.html>`__
* New place for python-mode bug reports and patches=20
<http://mail.python.org/pipermail/python-dev/2003-August/037451.html>`__
--------------------
Caching tuple hashes
--------------------
Raymond Hettinger asked if there was any reason why tuples, being=20
immutable, didn't cache their hash values. Strings cache their hashes=20
and they are immutable, so it seem to make sense.
It was pointed out, though, that tuples could contain an object that=20
changed its hash value between hash calls. Guido said, though, that it=20
was the responsibility of the object and not tuples to worry about=20
keeping a consistent hash value.
Guido also explained why strings cache their hashes. It turns out that=20
since strings are used so often for keys in dicts that caching their=20
hashes gave a large performance boost for almost any program, so the=20
effort was felt justified. But Guido did not see this same=20
justification for tuples. Thus tuples will not cache their hash values.
Contributing threads:
* `Caching tuple hashes=20
<http://mail.python.org/pipermail/python-dev/2003-August/037416.html>`__
-------------------------------
PyCon 2004 is under development
-------------------------------
Preparation for PyCon_ 2004 have now begun. With us getting the ball=20
rolling much earlier this conference should turn out to be even better=20
than last year (which, in my opinion, was great)! You can go to=20
http://www.python.org/pycon/dc2004/ to find links to lists to get=20
involved in organizing or just to be kept abreast of new developments.
.. _PyCon: http://www.python.org/pycon/dc2004/
Contributing threads:
* `PyCon DC 2004 Kickoff!=20
<http://mail.python.org/pipermail/python-dev/2003-August/037437.html>`__
----------------------------
Let the fixing of 2.3 begin!
----------------------------
The maintenance branch of Python 2.3 (named release23-maint) has been=20
created in CVS. Several bugs have already been fixed. For instructions=20
on how to check out a copy of the branch, read=20
http://www.python.org/dev/devfaq.html#c10 .
Contributing threads:
* `Python 2.3 maintenance branch is now open=20
<http://mail.python.org/pipermail/python-dev/2003-August/037440.html>`__
------------------------------------
When a void doesn't equal an integer
------------------------------------
After clearing up the confusing issue of the difference between a Python=20
int and a Python Integer (the former is <type 'int'> while the latter is=20
the union of <type 'int'> and <type 'long'> which is what Python is=20
moving towards so that the distinction practically disappears), the=20
discussion of how to handle a quirk of Win64 commenced. It turns out=20
that Win64 thinks that ``sizeof(void *) > sizeof(long)`` is a reasonable=20
thing to do. Well, all other platforms now and most likely for the rest=20
of Tim Peter's life (at least according to Tim's guess) don't and won't=20
hold this to be true.
As of right now Python claims that a void pointer can be held in a=20
Python int, but Win64 breaks that claim. Do we muck around with=20
Python's internals for this one strange exception that does not make=20
sense, such as making Python ints use long long? No, of course not.=20
Code would break, let alone the added complexity. So the needed changes=20
to the failing tests were dealt with and all seems to be fine with the=20
world again ... well, Win64 is still thinking on crack, but that is=20
someone else's problem.
Contributing threads:
* `sizeof(long) !=3D sizeof(void*)=20
<http://mail.python.org/pipermail/python-dev/2003-August/037465.html>`__
------------------------------------
Where do I put all of my packages?!?
------------------------------------
As it stands now there are four places where packages can reside:
1. standard library
2. site-packages
3. site-python (on UNIX this is the same directory where your python2.3=20
directory exists)
4. PYTHONPATH environment variable
It was pointed out that this does not necessarily give one all the=20
options one might want. The above covers the Python core easily, but=20
there is not clear distinction for vendor packages, network-installed=20
packages, system-wide packages or user-installed packages; they are=20
covered by 2-4 above. The suggestion was to make more distinct places=20
available for installation and to make distutils aware of them.
A good way to see how this would be useful is to look at how OS X's=20
Panther will handle Python 2.3 . It will have the standard library in=20
the standard location of /usr/local/python2.4 . In that directory, the=20
site-packages directory is a symlink to a more system-aware location.=20
This is fine but what about a sysadmin who would rather avoid the=20
possibility of breaking OS X by messing with the OS's Python=20
installation? What about a user on that system who does not have root=20
but wants to have their own place to put their packages? There is=20
definitely room for adding more standard path locations for package=20
installations.
A PEP was being mentioned but appears to not have been written yet.
Contributing threads:
* `Multiple levels of site-packages=20
<http://mail.python.org/pipermail/python-dev/2003-August/037487.html>`__
-------------------------
Be careful with __slots__
-------------------------
Raymond Hettinger observed that using __slots__ or overriding=20
__getattribute__ fails silently when mistakenly used with old-style=20
classes. This has bitten him and others in the bum so he wanted to add=20
warning/error messages. Guido recommended passing on the warnings=20
because 1) those are "expert use only" tools, 2) PyChecker can already=20
detect the issue, and 3) there are other new-style/classic issues cannot=20
as readily be flagged.
It should be known that "__slots__ is a terrible hack with nasty,=20
hard-to-fathom side effects that should only be used by programmers at=20
grandmaster and wizard levels". So only use __slots__ if you can apply=20
the label of "programmer at grandmaster or wizard level" to yourself=20
without your programming peers laughting their bums off; you have been=20
warned.
Contributing threads:
* `Make it an error to use __slots__ with classic classes=20
<http://mail.python.org/pipermail/python-dev/2003-August/037537.html>`__
--------------
Plugging leaks
--------------
Michael Hudson thought he had discovered a leak somewhere and went off=20
on a little hunt. It turned out to be a red herring more or less, but=20
there was some discussion on the best way to find leaks through=20
regression tests.
The basic scheme that everyone seemed to use was to run the regression=20
test once to get any caching out of the way and then run the test a set=20
number of times and see if the reference counts seemed to grow. Michael=20
Hudson posted a diff to add such a testing feature to test/regrtest.py=20
at http://mail.python.org/pipermail/python-dev/2003-August/037617.html .=20
Tim Peters also posted a link to Zope's test driver at=20
http://cvs.zope.org/Zope3/test.py which includes a class named TrackRefs=20
which can help keep track of the leaked references as well as leaked=20
objects.
Contributing threads:
* `CALL_ATTR patch=20
<http://mail.python.org/pipermail/python-dev/2003-August/037485.html>`__
* `refleak hunting fun!=20
<http://mail.python.org/pipermail/python-dev/2003-August/037617.html>`__
-----------------------------------------
Making the interpreter its own executable
-----------------------------------------
As it stands now the Python interpreter is distributed as a bunch of=20
files mostly made up of the standard library. But wouldn't it be nice=20
if you could make the interpreter just a single executable that was easy=20
to distribute with your code? Well, that discussion cropped up on=20
`comp.lang.python`_ at=20
http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&safe=3Doff&threa=
dm=3Dptji8wgr.fsf%40python.net=20
. The idea was to somehow introduce a hook into Py_Main() that could=20
harness the new zipimport facility.
The idea came up of appending the stdlib to the end of the Python=20
interpreter and to have a flag set to signal that the appending had=20
occurred. The problem is that this could cause unzipping problems.
But setting the flag is not necessarily simple either. One suggestion=20
was to literally patch the interpreter to set the flag. But there was=20
some confusion over the use of the term "patch"; Thomas Heller thought=20
more of "link with an object file defining this global variable".
This thread was still going as of this writing and had not yet reached a=20
clear solution.
Contributing threads:
* `hook for standalone executable=20
<http://mail.python.org/pipermail/python-dev/2003-August/037528.html>`__