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 firstname.lastname@example.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).
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.
(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."
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.
(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.
(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.
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 .
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.
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.
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 .
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 .
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.
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.
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" .
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 .
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.
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.
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.
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)" .
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.
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.
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 .
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.