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/N... .. _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/Module... .. _asyncore: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/as... .. _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/... ================================== `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... ========================= `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/... ========================================== `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.