[Python-Dev] Python-dev Summary for 2002-09-16 to 2002-09-30
Brett Cannon
drifty@bigfoot.com
Tue, 1 Oct 2002 00:44:09 -0700 (PDT)
Once again, here is the rough draft for the next Summary. Usual review
deal (24 hours, blah blah).
Have fun.
========================================
`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. Currently [he is] attaching them
to the the type's dict, as I reported before" by David Abrahams.
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/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/*:
.. _IDLEfork:
===========================================
`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`_)
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. 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-Fran?ois Pi?ronne had ported Python
2.1.3 over to OpenVMS_ and had begun work on porting 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 (link to email).
=======================================
`binutils/solaris -- one more thing`__
=======================================
__ http://mail.python.org/pipermail/python-dev/2002-September/028826.html
Andrew Koenig discovered another issue with Solaris/Binutils. In Binutils
2.12, the output from ``ld -V`` which is used to find out if dynamic
linking is available changed and broke the test. It turns out Martin v.
Loewis already committed a patch to Python 2.2.2 and 2.3 that deals with
this issue.
===================================================
`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 XXX .
=============================
`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. Guido said "In 2.3, it's disallowed". It is highly discouraged
in 2.2.2 but still doable.
==========================================================
`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.