This is a summary of traffic on the `python-dev mailing list`_ between October 1, 2002 and October 13, 2002 (inclusive). It is intended to inform the wider Python community of on-going developments on the list that might interest the wider Python community. To comment on anything mentioned here, just post to python-list@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 fourth summary written by Brett Cannon (with a partially fried brain thanks to the GRE). All summaries are now archived at http://www.python.org/dev/summary/ thanks to A.M. Kuchling. 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 program 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 version. .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _Docutils: .. _reST: .. _reStructuredText: http://docutils.sf.net/ ====================== Summary Announcements ====================== This is a new section to the summary that I have decided to introduce. It is mainly going to serve to make any general announcements or comments on this summary and this summary alone. All universal comments will stay at the top of the summaries. Just to let everyone know, I am taking off for two weeks on vacation starting 2002-10-14 and I will not return until 2002-10-30. Now, before you all start sobbing over the loss of one of my great summaries, you should know that Raymond Hettinger has graciously taken up the job of temp summarizer for me and will do the summary while I am gone. Michael Hudson has made the suggestion that I inject more of my personality into the summary so as to liven it up a little. I am personally quite happy to do this. But the real question is do you, fine reader, mind the idea? If I don't hear from throngs of people going "your sarcastic tone takes away from the wonderfully drawl summaries and that is a bad thing", then I will just go ahead and write with personality. Just don't complain later. =) 2.2.2b1 has been occupying Python-dev during this summary period, and so this summary is shorter than usual. I left out a bunch of threads that were discussing bugfixes that I either didn't find interesting or didn't think the rest of the world would care about. A.M. Kuchling has put all Python-dev summaries up at http://www.python.org/dev/summary/ . So now the archive is centralized instead of spread out among three web sites. I am sure the original archive sites will stay (I will keep mine up), but all future references will go to that page. Now it's time for my personal favor of the month. I am going to start applying to grad school for computer (science | programming) when I get back from vacation. If anyone knows of Python-friendly schools out there, let me know. Heck, I am even willing to leave America to go to school as long as the classes are in English. So if you know of any, please let me know! And now on to the summary. ========================================= `Python 2.2.2 beta release on Monday!`__ ========================================= __ http://mail.python.org/pipermail/python-dev/2002-October/029204.html splinter thread: - `RELEASED: Python 2.2.2b1`__ __ http://mail.python.org/pipermail/python-dev/2002-October/029337.html Python 2.2.2.b1 was released on Monday, October 7. This is the reason (or perhaps excuse is a better description) for the lighter summary this week. A good amount of the traffic on Python-dev was about bugfixing 2.2.2.b1. Most of this probably would not interest the average Python user, and thus I didn't summarize a bunch of threads. Taking the GRE also didn't help with my free time and thus has caused me to cut down on the summary since I am having to go through a huge backlog to get this out the door. ========================================= `Dropping support for Tcl 8.0 and 8.1`__ ========================================= __ http://mail.python.org/pipermail/python-dev/2002-October/029024.html Martin v. Loewis asked if it would be okay to drop support for Tcl_ 8.0 and 8.1 since `_tkinter.c`_ has special code in there just for those outdated versions. Guido ok'ed it, so if you are using those still using a version of Tk from way back when, it's time to upgrade. .. _Tcl: http://www.tcl.tk/ .. __tkinter.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Module... =========================================== `*very* revised proposal for interfaces`__ =========================================== __ http://mail.python.org/pipermail/python-dev/2002-October/029042.html Previously John Williams came up with a proprosal for implementing the stuff from `PEP 245`_ (Python Interface Syntax) and `PEP 246`_ (Object Adaptation). From my understanding of what John has done, it appears he has written an interface system in pure Python. If you want backstory to this long and involved discussion to get an interface system into Python read the Python-dev Summaries for 2002-08-16 to 2002-09-01 and 2002-09-01 to 2002-09-15 . Gerald Williams, Michael Chermside, and Esteban Castro all commented on the implementation and made various suggestions. John said that he was not done yet implementing this. But if you were interested in the whole previous discussion on interfaces you could consider looking at what John has done. As for it going into the language, I suspect that will have to wait until John is done and has convinced the PEP writers and Python-dev that his implementation fits the bill. Stay tuned. If you want some more background info on interfaces, read the previously mentioned summaries. As for object adaptation, read on c.l.py and on Python-dev anything by Alex Martelli on the subject. He has become the main proponent of object adaptation and has written several very extensive essays on the subject. .. _PEP 245: http://www.python.org/peps/pep-0245.html .. _PEP 246: http://www.python.org/peps/pep-0246.html ===================== `perplexed by mro`__ ===================== __ http://mail.python.org/pipermail/python-dev/2002-October/029035.html Splinter threads: - `Re: my proposals about mros (was: perplexed by mro)`__ - `C3 implementation`__ __ http://mail.python.org/pipermail/python-dev/2002-October/029167.html __ http://mail.python.org/pipermail/python-dev/2002-October/029230.html Samuele Pedroni said he was "trying to wrap [his] head around the mro computation in 2.2". Apparently there is the algorithm mentioned at http://www.python.org/2.2.1/descrintro.html (dubbed the naive algorithm) and then the one implemented in `typeobject.c`_ (called the 2.2 algorithm). Samuele discovered some inconsistencies with the implemented algorithm that he desired some explanation about. Guido responded, thankful that someone was giving this a look because his "intuition about the equivalence between algorithms turned out to be wrong". Guido stated that he thought that he wrote the algorithm from the book "Putting Metaclasses To Work" correctly sans raising an error when major conflicts occur in the ordering. In a later email Guido explained that the naive algorithm came about by his attempt to simplify the explanation of the 2.2 algorithm. Guido pretty much wrote the algorithm from the aforementioned book. Now the algorithm is not simple, so Guido did his best to simplify the explanation. Unknowningly, though, he came up with a variant on the algorithm in his explanation. Greg Ewing pointed out that he thought the naive algorithm was nicer since it seemed to work more intuitively and was easier to explain (and remember kids, these are basic tenants in Python programming). Guido ended up stating that "If Samuele agrees that the naive algorithm works better, [Guido will] try to make it so in 2.3". Well, Samuele said that the "2.2 mro is the worst of our options". There was a problem, though, with the naive algorithm; it is not monotonic as pointed out by Samuele. This led him to put out two options: 1. Use the naive algorithm, which had the drawback of not being monotonic. Samuele also believed that it didn't produce "the most natural results". 2. Adopt C3_ as described at http://www.webcom.com/haahr/dylan/linearization-oopsla96.html and apparently used by Goo_ . This algorithm is monotonic and Samuele says is more intuitive in its results. Guido got around to reading the C3_ paper and agreed that "we should adopt C3". He thought that the 2.2 algorithm was like the L*[LOOPS] algorithm mentioned in the paper, but he is not positive. Samuele then wrote a C implementation of the algorithm. Guido said he would get to the patch after 2.2.2b1 got out the door. .. _C3: http://www.webcom.com/haahr/dylan/linearization-oopsla96.html .. _Goo: http://www.ai.mit.edu/~jrb/goo/manual.43/goomanual_55.html .. _typeobject.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Object... =============================== `Psyco requests and patches`__ =============================== __ http://mail.python.org/pipermail/python-dev/2002-October/029038.html Armin Rigo of psyco_ an email to Python-dev with some thoughts on psyco and some requests. After mentioning how he wished more people realized psyco is meant to be used by anyone and not speed-hungry coders (it is a cool app and if you have any interest in compilers you should take a look) and that psyco could get some more advertising he mentioned three patches that he wrote (patches 617309_ , 617311_ , and 617312_ ) against 2.2.2 that he would like to see be accepted so as to ease maintenance of psyco. Armin also mentioned how he would like to move psyco forward. He pointed out he would like to eventually write it all in Python. This would require tracking changes in the interpreter that psyco dealt with. He would like to keep this in mind when Python 3 discussions kick up (and don't ask when that will happen; not for a VERY long time). In regards to Armin's patches, Martin v. Loewis thought they broke binary compatibility (big no-no between micro releases), but Armin claimed it didn't. After glancing over the patches it seems they have all been applied against 2.2.2 and are being actively worked on by Armin for application to 2.3. .. _617309: http://www.python.org/sf/617309 .. _617311: http://www.python.org/sf/617311 .. _617312: http://www.python.org/sf/617312 .. _psyco: http://psyco.sf.net/ ====================================================================== `PEP239 (Rational Numbers) Reference Implementation and new issues`__ ====================================================================== __ http://mail.python.org/pipermail/python-dev/2002-October/029065.html splinter threads: - `Re: PEP239 (Rational Numbers) Reference Implementation and new issues`__ __ http://mail.python.org/pipermail/python-dev/2002-October/029068.html Christopher Craig uploaded `patch 617779`_ that implemented `PEP 239`_ (Rational Numbers). He had some questions for Python-dev, though, regarding a couple points. These few points have become the bane of my summarizing existence; this thread is huge. One was whether division should return rationals instead of floats. Since rationals keep precision in division they are the most accurate way to perform division. THey also make the most output sense (e.g. 1/3). Problem with this is that rational math is slow and this would cause issue with any code that expected a float. The next issue was about comparison. Should a rational compare only when it is exactly equal to a float or when the float is really close? Lastly, Christopher wondered if rationals should hash the same as floats. The answer to the second issue would influence the answer to this issue. Issue 1. Eric Raymond was for returning a rational. Francois was kind of on the fence. Christian was +1 for returning rationals. Guido said ABC did this and that numeric processes thus ended up being slow. Issue 2. Christian said "Let it grow! Let the user feel what precision he's carrying around, and how much they throw away when they reduce down to a float." Issue 3. Eric Raymond suggested a global "fuzz" variable that defines a "close-enough-for-equality range"; this idea was used by APL. Andrew Koenig was against this because you don't always want a fuzzy comparison and it destroys substitutability: "If a==b, it is not always true that f(a)==f(b)". Andrew said he preferred Scheme's numeric model. To this, Guido said that "'It works in Scheme' doesn't give me a warm fuzzy feeling that it's been tried in real life"; Tim later laid the smack down on Scheme's numeric model and ended it with "There's a reason the NumPy folks never bug you for Scheme features <wink>". Christian pointed out that keeping it as a rat would prevent overflows from ever occuring from long division. Tim was staunchly against a fuzz variable. Raymond suggested a fuzz comparison function that took in a fuzz value. Christopher said that the way it stands now in the implementation is that rationals are coerced to floats and then compared. Oren Tirosh suggested a thired boolean, 'Undetermined', that would be raised when the "difference between A and B is below the error margin". David Abrahams said that Boost discussed this and said that the cost of adding ternary logic was not worth it. Andrew asked how rats could be optimized. He suggested ditching trailing zeros. Tim wondered how much of a save you would get from this. Raymond Hettinger suggested having a builtin variable that would specify the "maximum denominator magnitude". Christian liked this idea. Greg didn't think this would be a good solution because people using rats are going to want them specifically because they are exact. So Raymond suggest the default be unrestricted denominator. Guido brought up the question of how rats should be represented when printed. The syntax for rats came up. Greg Ewing got the ball rolling by suggesting the syntax for rat division as ``\\\``. M.A. Lemburg suggested just having a constructor like ``rat(2,3)``. The discussion then had a gamut of suggested syntax: ``2:3``, ``2r3``, ``{2/3}`` (Guido shot this down because he wants to leave the option open for possible set notation), ``<2/3>``,``2r/3``, something by Barry using an extended character that Pine wouldn't display (it was a joke), and finally ``2/3r`` by Guido. People agreed that this last one suggested by Guido was the best one. Tim also pointed out that Scheme has notation to specify whether a number is exact or not and using the 'r' notation would basically provide the same functionality. But regardless of what syntax people preferred, it was overwhelmingly agreed that choosing the syntax should wait until rationals have been in the language for a while and it is known how they are used. If you only read one thing, read Tim's emails since he explains all of this really well and is the resident math whiz on Python-dev. .. _patch 617779: http://www.python.org/sf/617779 .. _PEP 239: http://www.python.org/peps/pep-0239.html ================================================== `Non-ASCII characters in test_pep277.py in 2.3`__ ================================================== __ http://mail.python.org/pipermail/python-dev/2002-October/029247.html Guido pointed out that test_pep277.py_ uses an encoding cookie which was not being recognized by his toolchain. At some point he stated that he is "still not 100% comfortable with using arbitrary coding cookies in the Python distribution". The reason I mention this thread (beyond for the quote above) is that info on how to get XEmacs to recognize the cookie came out. Sjoerd Mullender sent out the link http://www.xemacs.org/Documentation/packages/html/mule-ucs_2.html which helped some people. As for Linux distro-specific problems, M.A. Lemburg noticed that SuSE puts Mule support in a package named 'mule-ucs-xemacs' and once he got the package loaded XEmacs worked. .. _test_pep277.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/te... ====================================================== `Unclear on the way forward with unsigned integers`__ ====================================================== __ http://mail.python.org/pipermail/python-dev/2002-October/029249.html Splinter threads: - `PEP 263 in the works`__ __ http://mail.python.org/pipermail/python-dev/2002-October/029289.html Mark Hammond was "a little confused by the new world order for working with integers in extension modules". Mark wanted know how to create objects that were more like a collection of bits than an integer. Tim suggested creating a Python long; that would act more like an unsigned int in terms of its bits. The FutureWarning for hexadecimal constants was brought up and it was pointed out that to deal with those just stick an 'L' at the end. Remember folks, that in Python 2.3 ``0x80000000L == 2147483648``. The usefulness of __future__ statements also came up. Tim wondered how useful they were. Thomas Wouters, though, came to __future__'s defense and explained how it helped him migrate people to newer versions of Python without being yelled at for breaking their code. ================================================= `segmentation fault with python2.3a0 from cvs`__ ================================================= __ http://mail.python.org/pipermail/python-dev/2002-October/029286.html Gersen Kurz was having problems importing a huge file. The bug was attributed to cygwin's malloc implementation, so people might want to watch out for that. It was also pointed out that a loop with a bunch of items in a dict created a huge number of references. It turns out that dicts use dummy references in its implementation for when something is deleted. So don't be alarmed by huge references even after you deleting an immense dict. ========================================== `Snapshot win32all builds of interest?`__ ========================================== __ http://mail.python.org/pipermail/python-dev/2002-October/029352.html As mentioned in the last summary, Mark Hammond wondered if anyone would care to have access to compiled snapshots of CVS for Windows. He got enough of a response to give access at http://starship.python.net/crew/mhammond . This is not like the standard Windows installer, though; "This version installs no shortcuts, does not compile .pyc files etc - you are pretty much on your own. Pythonwin\start_pythonwin.pyw is installed to start Pythonwin, but you must do so manually". Mark would like to know if you end up using this. =========================================== `Set-next-statement in Python debuggers`__ =========================================== __ http://mail.python.org/pipermail/python-dev/2002-October/029377.html Richie Hindle wants to write a pure Python debugger; the problem is that it would be difficult without certain C-level stuff exposed to Python. Specifically, he wants frame.f_lasti (to be found in frameobject.c_ ) to be writable by Python so he "could implement Set-Next-Statement". Michael Hudson is the first email I have of someone chiming against this. He thought it would be better to make it a descriptor so as that "you can do some sanity checking on the values". Guido then chimed in saying that if it was writable that would open up a hole for crashing a program. Guido eventually said making it read-only would be fine. This led to Armin Rigo pointing out that you can crash the interpreter already with the new module "or by writing crappy .pyc files". Guido acknowledged this, but said he didn't want to add anymore if it could be helped. He pointed out that he wants to stick with the idea that a segfault is Python's fault unless proven otherwise. .. _frameobject.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Object... ===================== `Multibyte repr()`__ ===================== __ http://mail.python.org/pipermail/python-dev/2002-October/029442.html A patch was applied that allowed repr() to return characters with the high bit set; repr() used the "multibyte C library for printing string if available". This had caused a bug and made Guido wonder if this was a good thing to do. For an example::

...

...

u = u'\u1f40' # Python 2.2 s = u.encode('utf8') s '\xe1\xbd\x80'

...

...

u = u'\u1f40' s = u.encode('utf8') s '1⁄2\x80' # Notice the extended character

"The latter output is not helpful, because the encoding of s is not the locale's encoding". Martin v. Loewis said that he thought author of the patch's intention was "to get 'proper' output in interactive mode for strings". Part of the issue with all of this is the GNU readline calls setlocale() automatically. A patch came about to reset it in the extension module back to its original state. The issue of whether pickling would break because of this. Guido tried it and had no issue. Atsuo Ishimoto (who brought up the possible problem) said it broke when using the ShiftJIS locale. But the worry of having repr() be locale-specific still lingered. Martin said he was "convinced that having repr locale-specific is unacceptable". He said, though, that having the tp_print slot use a locale-aware print function was fine and to have it differ from tp_repr was fine. But this was shot down by Guido; "tp_print only gets invoked when sys.stdout is a real file; otherwise str() or repr() get invoked". Apparently tp_print is a performance optimization and thus should be fully transparent and not be different in any way to the user. Guido said that the multibyte-string patch should be backed out. With the pickle issue and different semantics for sys.stdout because of tp_print, Guido said the patch had to be backed out. As Tamito Kajiyama said, "one of the virtues of Python is that Python has no language feature that is (automagically) affected by locale settings". ======================================= `tp_dictoffset calculation in 2.2.2`__ ======================================= __ http://mail.python.org/pipermail/python-dev/2002-October/029502.html Guido asked David Abrahams and Kevin Jacobs if a change in how tp_dictoffset (found in `typeobject.c`_ ) was calculated would affect them. To give some background, tp_dictoffset "tells us where the instance dict pointer is in the instance object layout". This was a three step process (all Guido's words): 1. (Line 1113) For dynamically created types (i.e. created by class statements), if the new type has no __slots__, the dominant base class has a zero tp_dictoffset, and the dominant base doesn't have a custom tp_getattro, a __dict__ will be added to the instance layout, and its tp_dictoffset is calculated by taking the end of the base class instance struct (or in a more complicated way if tp_itemsize is nonzero). 2. (Line 1941) If the dominant base has a nonzero tp_dictoffset, copy the tp_dictoffset from the dominant base. 3. (Line 2090) The tp_dictoffset of the first non-dominant base class that has a nonzero tp_dictoffset is copied. That last rule had caused Guido and Jeremey Hylton some problems with some code they were bugfixing. Guido wanted to just get rid of that rule since he though "it is *always* wrong". Both David and Kevin said that nothing broke for them, so that is now all straightened out. ========================== `Memory size overflows`__ ========================== __ http://mail.python.org/pipermail/python-dev/2002-October/029535.html Armin Rigo pointed out some potential overflow errors "with objects of very large sizes". The issue was when the amount of memory needed to allocate was calculated there was the chance that it would overflow. Armin suggested adding macros to deal with various issues. Arrive Tim Peters, creator of pymalloc. He admitted that he "always ignore[s] these [errors] until one pops up in real life" since "Checking slows the code, and that causes [Tim] pain <0.5 wink>". He pointed out another possible overflow calculation problem. But it was a basically a hopeless battle since malloc() has its own cross-platform issues. But Tim did say that if it was decided to go down the macro route, then he wanted something like what Zope does: ``DO_SOMETHING_OR(RESULT_LVALUE, INPUT1, ..., ON_ERROR_BLOCK);``. The result goes into RESULT_LVALUE unless there is a problem, in which case ON_ERROR_BLOCK is run. Christian Tismer chimed in and said that he thought we should just move completely over to 64 bit math. Ruby had done it successfully so it wasn't like we were taking a blind leap. It would also save us the hassle from doing it down the road when 64 bit processors become the norm instead of the exception.