Python-dev Summary for 2002-09-16 through 2002-09-30
Brett C.
drifty at bigfoot.com
Wed Oct 2 15:58:40 EDT 2002
This is a summary of traffic on the `python-dev mailing list`_ between
September 16, 2002 and September 30, 2002 (inclusive). It is intended
to inform the wider Python community of ongoing developments on the
list that might interest the wider Python community. To comment on
anything mentioned here, just post to python-list at python.org or
comp.lang.python in the usual way; give your posting a meaningful
subject line, and if it's about a PEP, include the PEP number (e.g.
Subject: PEP 201 - Lockstep iteration). All python-dev members are
interested in seeing ideas discussed by the community, so don't
hesitate to take a stance on a PEP (or anything else for that matter)
if you have an opinion. And if all of this really interests you then
get involved and join Python-dev!
This is the third summary written by Brett Cannon (with no more wisdom
teeth).
Summaries by me (2002-09-15 to ... when I burn out) are archived at:
http://www.ocf.berkeley.edu/~bac/python-dev/summaries/index.php
You can find summaries by Michael Hudson (2002-02-01 to 2001-07-05)
at:
http://starship.python.net/crew/mwh/summaries/index.html
Summaries by A.M. Kuchling (2000-12-01 to 2001-01-31) are at:
http://www.amk.ca/python/dev/
Please note that this summary is written using reStructuredText_ which
can be found at http://docutils.sourceforge.net/rst.html . Any
unfamiliar punctuation is probably markup for reST; you can safely
ignore it (although I suggest learning reST; its nice and is accepted
for PEP markup). Also, because of the wonders of reformatting thanks
to whatever you are using to read this, I cannot guarantee you will be
able to run this text through DocUtils as-is. If you want to do that,
get the original text from the archive.
Since not a single person sent me an email about my idea of compiling
a list of nicknames of people on Python-dev I won't bother.
.. _python-dev mailing list:
http://mail.python.org/mailman/listinfo/python-dev
.. _reST:
.. _reStructuredText: http://docutils.sf.net/
========================================
`flextype.c -- extended type system`__
========================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028736.html
(continuation from `last summary`_)
To clarify what Christian Tismer's metatype patch basically
implements, he said that his "additions support a subset of C++
virtual methods". And in response to a question from me about how
this might affect magic methods, he said he "*could* support any magic
slot and put it into the extended type object with a Python name. And
even better, this version could have full type checking, as my other
methods have as well!"
Martin v. Loewis doesn't see the use of this because extensions in C
are usually just wrappers and C++ extensions already have the
functionality. Thomas Heller, though, likes it because he wants a way
"to add additional C accessible structure fields to types".
As an aside, a suggestion to David about having to put
instance-specific info in __dict__, Thomas said "You can (but you
probably know this already) replace the type's tp_dict by a custom
subclass of PyDict_Object, which adds additional fields."
.. _last summary: http://www.ocf.berkeley.edu/~bac/python-dev/summaries/2002-09-01--2002-09-15.html
==================================
`Moratorium on changes to IDLE`__
==================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028776.html
Guido said that he would "like to put a stop to all changes to the
version of IDLE in the Python source tree (`Tools/idle/*`_ -- let's
call it Python-idle)". All changes should go through IDLEfork_ . It
will then get merged into CVS before 2.3 is released. Currently
Idlefork is working with 2.2 and Guido would like to keep it that way
so that more people use IDLE.
.. _Tools/idle/*: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/idle/
.. _IDLEfork: http://idlefork.sf.net/
===========================================
`Weeding out obsolete modules and Demos`__
===========================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028718.html
(continuation from `last summary`_)
Guido removed the obsolete SGI demos from Demo_ as mentioned from the
last summary.
If anyone else out there has any demos that they think are no longer
needed, submit a `SF patch`_ mentioning what you think should be
removed and why.
.. _Demo: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Demo/
.. _SF patch: http://sourceforge.net/tracker/group_id=5470&atid=305470
=======================
`ReST-ing Misc/NEWS`__
=======================
__ http://mail.python.org/pipermail/python-dev/2002-September/028799.html
Skip changed `Misc/NEWS`_ into a reST document. Hopefully this will
end up somewhere on http://www.python.org so people can be kept very
up-to-date on what changes have been made in CVS_ .
.. _Misc/NEWS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/NEWS
.. _CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/
====================================
`mysterious hangs in socket code`__
====================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028555.html
(continued from `last summary`_)
People are still trying to weed out issues with threaded code that
seems to act single-threaded. The suspect is still glibc's
getaddrinfo() implementation; POSIX says it is supposed to be
thread-safe but not everyone is believing that.
=====================================================
`ATTENTION! Releasing Python 2.2.2 in a few weeks`__
=====================================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028806.html
Guido announced that he would like to get Python 2.2.2 out the door by
October 8. PythonLabs is busy as it is and thus do not have time to
thoroughly make sure everything gets done. What can you do to help?
Glad you asked: "the best thing you can do is take your favorite set
of modules or core files and systematically backport anything that's
clearly a bugfix and backports easily. Or you could simply make sure
that your favorite bugfix is backported".
If you don't have checkin, either team up with someone who does or
request checkin rights (decision will be based on reputation).
SF should not be used for saying what should and shouldn't be
backported. This should all be done through Python-dev. Michael
McLay suggest a wiki to handle all of this (thank goodness; the amount
of traffic this would have generated would have killed me). Skip said
he could set one up rather quickly and he did at
http://manatee.mojam.com/py222wiki/ .
Laura Creighton mentioned what she planned to do for Python-in-a-Tie
(Py-tie). Looks like the current plan is to make Python 2.2.2 the
initial release and add in things from there based on developer
feedback instead of taking future releases and removing what they
don't need. Perhaps Py-tie will end up taking the place of the
elusive `Sumo distro`_?
Ralf W. Grosse-Kunstleve brought up how a bug report about C++
compatibility had not been handled yet. Both Tim and Guido said that
if he wanted a solution put in they would need a patch; neither of
them are C++ users (Ralf subsequently provided a patch that Neal
Norwitz has assgined to himself and will apply and backport at
http://www.python.org/sf/607253 ). C++ uses should keep that in mind
when trying to get C++ stuff into the core.
Gustavo Niemeyer said that he has a script for adding moin pages using
your favorite editor. He also has a syntax highlight file for Vim.
All of this can be found at http://moin.conectiva.com.br/EditMoin .
.. _Sumo distro: http://www.python.org/peps/pep-0206.html
================================
`Built-in functions, kw args`__
================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028811.html
Jp Calderone brought up the question of whether ParseTupleAndKeywords
should be used more often then ParseTuple in the core.
Guido pointed out that ParseTupleAndKeywords did not exist since the
beginning of time, it's slower, and much harder to use. Guido
basically ended up saying use it if you want, it isn't required.
=======================
`Python for OpenVMS`__
=======================
__ http://mail.python.org/pipermail/python-dev/2002-September/028814.html
Skip Montanaro announced that Jean-Francois Pieronne had ported Python
2.1.3 over to OpenVMS_ . Skip has also informed me that Jean-Francois
has submitted some patches against the 2.3 tree.
.. _OpenVMS: http://www.openvms.org/
================
`-zcombreloc`__
================
__ http://mail.python.org/pipermail/python-dev/2002-September/028822.html
In Andrew Koenig's continual quest to get Python to build with
Binutils 2.13 under Solaris, Andrew discovered through discussions
with the Binutils developers "that -zcombreloc just plain doesn't work
in any release of binutils". Andrew thinks this will get fixed in
Binutils 2.13.1 .
But what about until then? Well, you are out of luck on Solaris with
Binutils 2.13 . There is a test you can run to see if you will be
affected by this bug in this email at
http://mail.python.org/pipermail/python-dev/2002-September/028822.html
.
===================================================
`Need advice: cloning python cvs for CE project`__
===================================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028842.html
Brad Clements of the "python ce" project asked for advice on how to
"maintain a single working directory that can be checked into two
different CVS systems". Guido said they could have a branch in the
CVS tree if they were all Python developers "or can be sworn in
easily". The other option Guido presented was for them to start their
own SF project and do a vendor branch checking; this is how IDLE-fork
does it.
Martin gave some instructions on how to do this in an email which can
be reached at http://mail.python.org/pipermail/python-dev/2002-September/028852.html
.
=============================
`Assign to errno allowed?`__
=============================
__ http://mail.python.org/pipermail/python-dev/2002-September/028868.html
Thomas Heller was patching selectmodule.c_ for Windows to deal with
the fact that it does not set errno. Thomas wondered if it would be
okay to set errno himself. Everyone in the end said it was fine (even
the man page for errno).
Through the discussion over whether not setting errno was proper, it
was pointed out by Thomas that the entire reason he was fixing this
was for asyncore_ to work; apparently it has always been broken on
Windows. Guido suggested a simple fix to the module to make it work.
The other point that came up that Windows CE and NetWare don't allow
for direct signing to errno; ``errno = 0`` is an error on those
platforms. Brad Clements submitted a patch to add a macro to Python
for setting errno. Well, Tim pointed out that it is an ISO C
requirement that errno be assignable. This led Guido to "have a very
strong urge to tell [Brad's patch] to go away". Let me say that from
my personal experience on Python-dev I have noticed that Python-dev
does not like work-arounds for things that don't work because
something does not follow a standard; this is especially true for
anything dealing with ISO C. So if you have a problem and it is
because your platform is not standards-compliant, I would not expect
to get much sympathy from Python-dev (unless it is a Windows desktop
OS =).
In the end it was suggested to the CE guys to just keep a branch of
the CVS where they fixed the whole errno issue. That way they can
just sync with the core and not have to go through and change all of
the errno lines every time they sync.
This thread even split into another one entitled `Reserved keywords in
source`_ in which Brad Clements pointed out that ``finally`` is a
reserved word on Windows CE. This, once again, flies in the face of
ISO C.
.. _selectmodule.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/selectmodule.c
.. _asyncore: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/asyncore.py
.. _Reserved keywords in source:
http://mail.python.org/pipermail/python-dev/2002-September/028912.html
=============
`sorted()`__
=============
__ http://mail.python.org/pipermail/python-dev/2002-September/028925.html
Francois Pinard brought up the point that most beginners don't realize
that ``.sort()`` does not return anything; the sorting is done
in-place. He thought that adding a ``.sorted()`` method to lists that
would work just like ``.sort()`` but also return the list would be
nice. Would not only possibly simplify some code by allowing a sort
method to be called in the header of a ``for`` loop, but possibly
prevent newbie errors as previously mentioned.
Greg Ewing suggested a ``sorted()`` function instead that would
basically do what Francois wanted. This causeed Timothy Delaney to
suggest possible magic methods ``__sort__`` and ``__isort__``.
Guido responded saying that "this is a problem that should not be
addressed by changes to the language, builtins or library". So there
you go, the BDFL has spoken.
==============================
`Lib/plat-xxxx directories`__
==============================
__ http://mail.python.org/pipermail/python-dev/2002-September/028933.html
In case people are interested, the Lib/plat-xxx directories are "for
platform-specific modules". Most of them, apparently, "are
collections of system constants generated by Tools/scripts/h2py.py" .
.. _Tools/scripts/h2py.py:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/scripts/h2py.py
==================================
`How to add an encoding alias?`__
==================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028936.html
For the spambayes_ project, Guido asked how to add an encoding to
``encodings.aliases``. He wondered if there was an official API or
if::
import encodings.aliases
encodings.aliases.aliases['ansi-x3-4-1968'] = 'ascii' # This is
wrong! Read on for why...
was the way to do it.
M.A. Lemburg pointed responded that the above-mentioned way is the
only way to do it in 2.2 . He also mentioned that hyphens must be
changed to underscores for names. MAL suggested that all
non-alphanumeric characters be mapped to underscores before referring
to the aliases dictionary.
Guido voted +1 for the change and +1 to backporting to 2.2.2 .
.. _spambayes: http://spambayes.sf.net
========================================
`User extendable literal modifiers?!`__
========================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028945.html
M.A. Lemburg asked what everyone thought of having the ability to add
new literal modifiers (e.g. ``L`` in ``123L``) to the interpreter.
Gareth McCaughan suggest "uder-definable *prefixes*". His example is
of Common Lisp's ability to have you define something as
``#<character><anything>`` and then parse it based on <character>.
Alex Martelli liked the idea and suggested that ``@`` be the proposed
symbol instead of ``$`` as originally suggested. Alex also said that
being able to parse multiple tokens would be important.
Jeff Epler pointed out that this could all be done right now with some
ugly syntax::
class Dimension: ...
class DimensionMaker:
def __call__(self, v):
return Dimension(v)
def __add__(self, v):
return Dimension(v)
D = DimensionMaker()
>>> D+"123" # Can be considered same as defining D"123"
Guido said that "Given all the discussion, this will need a PEP". He
later pointed out that a possible problem is that if you are not very
familiar with a program you might probably won't know what a specific
prefix is. With a function the worst would be having to look through
a module that was imported with ``from <module> import *`` ("that's
one reason to avoid these" types of imports). MAL said that Guido was
"probably right" about this possible confusion.
===========================================
`Keyword for first argument of methods?`__
===========================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028960.html
David Abrahams noticed that if he defined the code::
class X:
def foo(self, y): print y
that ``X.foo(y=1, self=X())`` fails with a TypeError.
Guido said that "You can't pass in self to an unbound method as a
keyword argument". Best way to have an unbound method is with
__call__ . I think using something like the new staticmethod() or
classmethod() functions in Python 2.2 would get the job done.
============================================
`Strange bug only happens with Python 2.2`__
============================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028966.html
Gerhard Haring discovered a funky bug dealing with an error saying
that a custom object was a string and lacking a __bases__ attribute.
What is pertinent to this thread is not the bug (it got fixed in
Python 2.3 and has been backported to 2.2.2), but what caused the bug.
In abstract.c there was some code that forgot to call PyErr_Clear() .
When your extension code catches an error and you decide to either
ignore it or go another direction, you must call this function in
order to prevent the exception from propogating to the top when the
call is finished and raising the exception in the end.
=================================================
`builtins instance have modifiable __class__?`__
=================================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028978.html
Samuele Pedroni asked if being able to directly assigning to __class__
was allowed for builtins. Guido said "In 2.3, it's disallowed". It
is highly discouraged in 2.2.2 but still doable.
Guido clarified that "setting __class__ for instances of user-defined
new-style classes will be allowed (if the new __class__ value is
compatible with the old)" .
==========================================================
`Why are useful tools omitted from the Win bin distro?`__
==========================================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028988.html
Alex Martelli asked why the Windows distribution lacked some of the
Tools subdirectory. Most of the scripts are left out since they are
meant for developers. Since if you are using the pre-packaged Windows
installer chances are you are not a developer since you would have
compiled it. Thus these scripts are left out.
Tim Peters (who maintains the WISE installer) said that in order to
add a script he would have to add an individual line to the installer
for each file; a definite PITA (Pain In The Ass) for Tim.
There have been calls (which still stand) to document, fix, and clean
out the Tools_ and Demo_ directories. No one has ever really stepped
up to take this on. Any help, though, no matter how small, would be
appreciated in cleaning these directories up.
.. _Tools: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/
=======================================
`Extension module difficulty w/pgen`__
=======================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028976.html
Jonathan Riehl was having difficulty getting his extension module that
exposes pgen to link properly. He got it to work with a little
command-line hack; that does not work for the official distro and thus
he was searching for a more proper solution. He discovered that if he
put dummy calls into a global function that seemed to allow it to be
linked. Jonathan hoped there was a better solution. Guido,
unfortunately, destroyed that hope by stating "AFAIK you have to
create a dummy reference somewhere". He suggested at the end of
`Python/pythonrun.c`_ to Jonathan.
.. _Python/pythonrun.c:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/pythonrun.c
=========================
`New logmerge feature`__
=========================
__ http://mail.python.org/pipermail/python-dev/2002-September/028998.html
Guido added a new feature to `Tools/logmerge.py`_ that "restricts the
output to a specific branch tag". This is useful if you are helping
to sort through all of the commits to Python 2.3 to see what should go
into 2.2.2 .
.. _Tools/logmerge.py:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/logmerge.py
==========================================
`Snapshot win32all builds of interest?`__
==========================================
__ http://mail.python.org/pipermail/python-dev/2002-September/029005.html
Mark Hammond was wondering if people would be interested in him
"making regular, basically untested win32all builds against the
current Python CVS tree". If you would like Mark to do this, let him
know.
More information about the Python-list
mailing list