Mailman 3 February 2001 - Python-Dev

platform specific files
by Steven D. Majewski 16 Feb '01

16 Feb '01

On macosx, besides the PyObjC (i.e.NextStep/OpenStep/Cocoa) module, I now have a good chunk of the MacOS Carbon based toolkit modules ported (though not tested): Python 2.1a2 (#1, 02/12/01, 19:49:54) [GCC Apple DevKit-based CPP 5.0] on Darwin1.2 Type "copyright", "credits" or "license" for more information. >>> import Carbon >>> dir(Carbon) ['AE', 'App', 'Cm', 'ColorPicker', 'Ctl', 'Dlg', 'Drag', 'Evt', 'Fm', 'HtmlRender', 'Icn', 'List', 'Menu', 'Qd', 'Qdoffs', 'Res', 'Scrap', 'Snd', 'TE', 'Win', '__doc__', '__file__', '__name__', 'macfs'] >>> Jack has always maintained the Mac distribution separately, but that was largely because the Metrowerks compiler environment was radically different from unix make/gcc and friends. That's no longer the case on macosx. ( Although, it looks like we will end up, for a while, at least, with 3 versions on OSX: Classic, Carbonized-MacPython, and the unix build of Python with Carbon and Cocoa libs. ) I note that 2.1a2 still has BeOS and PC specific directories, although the Nt & sgi directories that were in older releases are gone. I'm guessing the current wish is to keep as much platform dependent stuff as possible separate and managed with disutils, and construct separate platform-specific distributions my merging them on each release. How is all of this handled in the various Windows distributions ? ( And in the light of that, is there anything particular I should avoid? ) -- Steve M.

1 0

Documentation Tools (was Unit Testing)
by Andy Robinson 16 Feb '01

16 Feb '01

Moshe Zadka <moshez(a)zadka.site.co.il> write: > As someone who works primarily in Perl nowadays, and hates > it, I must say > that as horrible and unaesthetic pod is, having > > perldoc package::module > > Just work is worth everything -- [snip] > We had a DevDay, we have a sig, we have a PEP. None of this > seems to help -- > what we need is a BDFL's pronouncement, even if it's on the > worst solution > possibly imaginable. ReportLab have just hired Dinu Gherman to work on this. We have crude running solutions of our own that do both HTML+Bitmap and PDF on any package, and are devoting considerable resources to an automatic documentation tool. In fact, it's part of a deliverable for a customer project this spring. We need both these PEPs or something like them for this to really fly. Dinu will be at IPC9 and happy to discuss this, and we have the resources to do trial implementations for the BDFL to consider. I suggest anyone interested contacts Dinu at the address above. And Dinu, why don't you contact the doc-sig administrator and find out why your membership is blocked :-) - Andy Robinson

4 4

Re: [Python-Dev] Adding pymalloc to 2.1b1 ?! (python-dev summary, 2001-02-01 - 2001-02-15)
by Michael Hudson 16 Feb '01

16 Feb '01

Guido van Rossum <guido(a)digicool.com> writes: > > Michael Hudson wrote: > > > > > > The use > > > of Vladimir Marangoz's obmalloc patch in some of the benchmarks > > > sparked a discussion about whether this patch should be incorporated > > > into Python 2.1. There was support from many for adding it on an > > > opt-in basis, since when nothing has happened... > > > > ... I'm still waiting on BDFL pronouncement on this one. The plan > > was to check it in for beta1 on an opt-in basis (Vladimir has written > > the patch this way). > > > > -- > > Marc-Andre Lemburg > > If it is truly opt-in (supposedly a configure option?), I'm all for > it. It is very much opt-in. > I recall vaguely though that Jeremy or Tim thought that the patch > touches lots of code even when one doesn't opt in. That was a no-no > so close before the a2 release. Anybody who actually looked at the > code got an opinion on that now? I suggest looking at the patch. Not at the code, but what it does as a diff: 1) Add a file Objects/obmalloc.c 2) Add stuff to configure.in & config.h to detect the --with-pymalloc argument to ./configure 3) Conditionally #include "obmalloc.h" in Objects/object.c if WITH_PYMALLOC is #defined 4) Conditionally #define the variables in Include/objimpl.h to #define the #defines needed to override the memory imiplementation if WITH_PYMALLOC is #defined And *that's it*. That's not my definition of "touches a lot of code". Cheers, M. -- Or here's an even simpler indicator of how much C++ sucks: Print out the C++ Public Review Document. Have someone hold it about three feet above your head and then drop it. Thus you will be enlightened. -- Thant Tessman

4 4

threads and gethostbyname
by Martin v. Loewis 16 Feb '01

16 Feb '01

> Under 1.5.2, this worked without a hitch. However, under 2.0, the > same program tends to lock up on some computers. I'm not 100% sure > (it's a bit hard to debug), but it looks like a global lock > problem... > Any ideas? Is this supposed to work at all? Can you post a short snippet demonstrating how exactly you initiate the DNS lookup, and how exactly you get the result back? I think it ought to work, and I'm not aware of a change that could cause it to break in 2.0. So far, in all cases where people reported "Tkinter and threading deadlocks", it turned out that the deadlock was in the application. Regards, Martin

1 0

Re: whitespace normalization
by Guido van Rossum 16 Feb '01

16 Feb '01

Tim, I've seen a couple of checkins lately from you like this: > Modified Files: > random.py robotparser.py > Log Message: > Whitespace normalization. Apparently you watch checkins to the std library and run reindent on changed modules occasionally. Would it make sense to check in a test case into the test suite that verifies that all std modules are reindent fixpoints, so that whoever changes a module gets a chance to catch this before they check in? --Guido van Rossum (home page: http://www.python.org/~guido/)

3 3

Re: [Python-Dev] python-dev summaries?
by Michael Hudson 15 Feb '01

15 Feb '01

Andrew Kuchling <akuchlin(a)cnri.reston.va.us> writes: > On Thu, Feb 15, 2001 at 02:45:18PM +0000, Michael Hudson wrote: > > use to equivalent string method. > > > > * Python's release schedule * > > I think an extra blank line before the section headings would separate > the sections more clearly. > > > Skip Montanero raised some concerns about Python's accelerated > ^^^^^^^^^ Montanaro > > Beyond those two things, great work! I say post it. (Don't forget to > send copies to lwn(a)lwn.net and editors(a)linuxtoday.com.) Thanks! I meant to check Skip's name (duh! sorry!). Changes made. > Also, is it OK with you if I begin adding these summaries to the > archive at www.amk.ca/python/dev/, suitably credited? Yeah, sure. I was going to stick them on my pages, but it probably makes more sense to keep them where people already look for them. Do you want me to send you the html-ized version I've cobbled together? (and got to validate as xhtml 1.0 strict...). Cheers, M. -- 48. The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

1 0

Re: [Python-Dev] python-dev summaries?
by Michael Hudson 15 Feb '01

15 Feb '01

"Tim Peters" <tim.one(a)home.com> writes: > [Michael Hudson, graduates from bytecodes to ASCII art] > > ... > > If noone else is planning on doing a sumamry, I'll post a draft for > > comments sometime tomorrow. > > 1. If you solicit comments, it will be 3 months of debate before > you get to post the thing <0.8 wink>. Just Do It. Well, I'm not quite brave enough for that. Here's what I've written; spelling & grammar flames appreciated! You've got a couple of hours before I post it to all the other places... It is with some trepidation that I post: This is a summary of traffic on the python-dev mailing list between Feb 1 and Feb 14 2001. It is intended to inform the wider Python community of ongoing developments. To comment, just post to python-list(a)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 if you have an opinion. This is the first python-dev summary written by Michael Hudson. Previous summaries were written by Andrew Kuchling and can be found at: <http://www.amk.ca/python/dev/> New summaries will probably appear at: <http://starship.python.net/crew/mwh/summaries/> When I get round to it. Posting distribution (with apologies to mbm) Number of articles in summary: 498 80 | ]|[ | ]|[ | ]|[ | ]|[ | ]|[ ]|[ 60 | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ 40 | ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 20 | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 0 +-029-067-039-037-080-048-020-009-040-021-008-030-043-027 Thu 01| Sat 03| Mon 05| Wed 07| Fri 09| Sun 11| Tue 13| Fri 02 Sun 04 Tue 06 Thu 08 Sat 10 Mon 12 Wed 14 A fairly busy fortnight on python-dev, falling just short of five hundred articles. Much of this is making ready for the Python 2.1 release, but people's horizons are beginning to rise above the present. * Python 2.1a2 * Python 2.1a2 was released on Feb. 2. One of the more controversial changes was the disallowing of "from module import *" at anything other than module level; this restriction was weakened after some slightly heated discussion on comp.lang.python. <http://mail.python.org/pipermail/python-dev/2001-February/012815.html> It is possible that non-module-level "from module import *" will produce some kind of warning in Python 2.1 but this code has not yet been written. * Performance * Almost two weeks ago, we were talking about performance. Michael Hudson posted the results of an extended benchmarking session using Marc-Andre Lemburg's pybench suite: <http://mail.python.org/pipermail/python-dev/2001-January/012330.html> to which the conclusion was that python 2.1 will be marginally slower than python 2.0, but it's not worth shouting about. The use of Vladimir Marangoz's obmalloc patch in some of the benchmarks sparked a discussion about whether this patch should be incorporated into Python 2.1. There was support from many for adding it on an opt-in basis, since when nothing has happened... * Imports on case-insensitive file systems * There was quite some discussion about how to handle imports on a case-insensitive file system (eg. on Windows). I didn't follow the details, but Tim Peters is on the case (sorry), so I'm confident it will get sorted out. * Sets & iterators * The Sets discussion rumbled on, moving into areas of syntax. The syntax: for key:value in dict: was proposed. Discussion went round and round for a while and moved on to more general iteration constructs, prompting Ka-Ping Yee to write a PEP entitled "iterators": <http://python.sourceforge.net/peps/pep-0234.html> Please comment! Greg Wilson announced that BOFs for both sets and iterators have been arranged at the python9 conference in March: <http://mail.python.org/pipermail/python-dev/2001-February/012824.html> * Stackless Python in Korea * Christian Tismer gave a presentation on stackless python to over 700 Korean pythonistas: <http://mail.python.org/pipermail/python-dev/2001-February/012601.html> I think almost everyone was amazed and delighted to find that Python has such a fan base. Next stop, the world! * string methodizing the standard library * Eric Raymond clearly got bored one evening and marched through the standard library, converting almost all uses of the string module to use to equivalent string method. * Python's release schedule * Skip Montanero raised some concerns about Python's accelerated release schedule, and it was pointed out that the default Python for both debian unstable and Redhat 7.1 beta was still 1.5.2. Have *you* upgraded to Python 2.0? If not, why not? * Unit testing (again) * The question of replacing Python's hoary old regrtest-driven test suite with something more modern came up again. Andrew Kuchling enquired whether the issue was to be decided by voting or BDFL fiat: <http://mail.python.org/pipermail/python-dev/2001-February/012830.html> Guido obliged: <http://mail.python.org/pipermail/python-dev/2001-February/012831.html> There was then some discussion of what changes people would like to see made in the standard-Python-unit-testing-framework-elect (PyUnit) before they would be happy with it. Cheers, M. -- Or here's an even simpler indicator of how much C++ sucks: Print out the C++ Public Review Document. Have someone hold it about three feet above your head and then drop it. Thus you will be enlightened. -- Thant Tessman

2 1

[PEP 223] Change the Meaning of \x Escapes
by Tim Peters 15 Feb '01

15 Feb '01

An HTML version of the attached can be viewed at http://python.sourceforge.net/peps/pep-0223.html This will be adopted for 2.0 unless there's an uproar. Note that it *does* have potential for breaking existing code -- although no real-life instance of incompatibility has yet been reported. This is explained in detail in the PEP; check your code now. although-if-i-were-you-i-wouldn't-bother<0.5-wink>-ly y'rs - tim PEP: 223 Title: Change the Meaning of \x Escapes Version: $Revision: 1.4 $ Author: tpeters(a)beopen.com (Tim Peters) Status: Active Type: Standards Track Python-Version: 2.0 Created: 20-Aug-2000 Post-History: 23-Aug-2000 Abstract Change \x escapes, in both 8-bit and Unicode strings, to consume exactly the two hex digits following. The proposal views this as correcting an original design flaw, leading to clearer expression in all flavors of string, a cleaner Unicode story, better compatibility with Perl regular expressions, and with minimal risk to existing code. Syntax The syntax of \x escapes, in all flavors of non-raw strings, becomes \xhh where h is a hex digit (0-9, a-f, A-F). The exact syntax in 1.5.2 is not clearly specified in the Reference Manual; it says \xhh... implying "two or more" hex digits, but one-digit forms are also accepted by the 1.5.2 compiler, and a plain \x is "expanded" to itself (i.e., a backslash followed by the letter x). It's unclear whether the Reference Manual intended either of the 1-digit or 0-digit behaviors. Semantics In an 8-bit non-raw string, \xij expands to the character chr(int(ij, 16)) Note that this is the same as in 1.6 and before. In a Unicode string, \xij acts the same as \u00ij i.e. it expands to the obvious Latin-1 character from the initial segment of the Unicode space. An \x not followed by at least two hex digits is a compile-time error, specifically ValueError in 8-bit strings, and UnicodeError (a subclass of ValueError) in Unicode strings. Note that if an \x is followed by more than two hex digits, only the first two are "consumed". In 1.6 and before all but the *last* two were silently ignored. Example In 1.5.2: >>> "\x123465" # same as "\x65" 'e' >>> "\x65" 'e' >>> "\x1" '\001' >>> "\x\x" '\\x\\x' >>> In 2.0: >>> "\x123465" # \x12 -> \022, "3456" left alone '\0223456' >>> "\x65" 'e' >>> "\x1" [ValueError is raised] >>> "\x\x" [ValueError is raised] >>> History and Rationale \x escapes were introduced in C as a way to specify variable-width character encodings. Exactly which encodings those were, and how many hex digits they required, was left up to each implementation. The language simply stated that \x "consumed" *all* hex digits following, and left the meaning up to each implementation. So, in effect, \x in C is a standard hook to supply platform-defined behavior. Because Python explicitly aims at platform independence, the \x escape in Python (up to and including 1.6) has been treated the same way across all platforms: all *except* the last two hex digits were silently ignored. So the only actual use for \x escapes in Python was to specify a single byte using hex notation. Larry Wall appears to have realized that this was the only real use for \x escapes in a platform-independent language, as the proposed rule for Python 2.0 is in fact what Perl has done from the start (although you need to run in Perl -w mode to get warned about \x escapes with fewer than 2 hex digits following -- it's clearly more Pythonic to insist on 2 all the time). When Unicode strings were introduced to Python, \x was generalized so as to ignore all but the last *four* hex digits in Unicode strings. This caused a technical difficulty for the new regular expression engine: SRE tries very hard to allow mixing 8-bit and Unicode patterns and strings in intuitive ways, and it no longer had any way to guess what, for example, r"\x123456" should mean as a pattern: is it asking to match the 8-bit character \x56 or the Unicode character \u3456? There are hacky ways to guess, but it doesn't end there. The ISO C99 standard also introduces 8-digit \U12345678 escapes to cover the entire ISO 10646 character space, and it's also desired that Python 2 support that from the start. But then what are \x escapes supposed to mean? Do they ignore all but the last *eight* hex digits then? And if less than 8 following in a Unicode string, all but the last 4? And if less than 4, all but the last 2? This was getting messier by the minute, and the proposal cuts the Gordian knot by making \x simpler instead of more complicated. Note that the 4-digit generalization to \xijkl in Unicode strings was also redundant, because it meant exactly the same thing as \uijkl in Unicode strings. It's more Pythonic to have just one obvious way to specify a Unicode character via hex notation. Development and Discussion The proposal was worked out among Guido van Rossum, Fredrik Lundh and Tim Peters in email. It was subsequently explained and disussed on Python-Dev under subject "Go \x yourself", starting 2000-08-03. Response was overwhelmingly positive; no objections were raised. Backward Compatibility Changing the meaning of \x escapes does carry risk of breaking existing code, although no instances of incompabitility have yet been discovered. The risk is believed to be minimal. Tim Peters verified that, except for pieces of the standard test suite deliberately provoking end cases, there are no instances of \xabcdef... with fewer or more than 2 hex digits following, in either the Python CVS development tree, or in assorted Python packages sitting on his machine. It's unlikely there are any with fewer than 2, because the Reference Manual implied they weren't legal (although this is debatable!). If there are any with more than 2, Guido is ready to argue they were buggy anyway <0.9 wink>. Guido reported that the O'Reilly Python books *already* document that Python works the proposed way, likely due to their Perl editing heritage (as above, Perl worked (very close to) the proposed way from its start). Finn Bock reported that what JPython does with \x escapes is unpredictable today. This proposal gives a clear meaning that can be consistently and easily implemented across all Python implementations. Effects on Other Tools Believed to be none. The candidates for breakage would mostly be parsing tools, but the author knows of none that worry about the internal structure of Python strings beyond the approximation "when there's a backslash, swallow the next character". Tim Peters checked python-mode.el, the std tokenize.py and pyclbr.py, and the IDLE syntax coloring subsystem, and believes there's no need to change any of them. Tools like tabnanny.py and checkappend.py inherit their immunity from tokenize.py. Reference Implementation The code changes are so simple that a separate patch will not be produced. Fredrik Lundh is writing the code, is an expert in the area, and will simply check the changes in before 2.0b1 is released. BDFL Pronouncements Yes, ValueError, not SyntaxError. "Problems with literal interpretations traditionally raise 'runtime' exceptions rather than syntax errors." Copyright This document has been placed in the public domain.

9 16

troubling math bug under IRIX 6.5
by Flying Cougar Burnette 15 Feb '01

15 Feb '01

Hey Folks, One of these days I'll figure that SOurceForge stuff out so I can submit a real bug report, but this one is freaky enough that I thought I'd just send it right out... from the latest CVS (as of 9:30am pacific) I run 'make test' and get: ... PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l make: *** [test] Bus error (core dumped) a quick search around shows that just importing regrtest.py seg faults, and further simply importing random.py seg faults (which regrtest.py does). it all boils down to this line in random.py NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0) and the problem can be further reduced thusly: >>> import math >>> 4 * math.exp(-0.5) Bus error (core dumped) but it isn't the math.exp that's the problem, its multiplying the result times 4! (tommy@mace)/u0/tommy/pycvs/python/dist/src$ ./python Python 2.1a2 (#2, Feb 13 2001, 09:49:17) [C] on irix6 Type "copyright", "credits" or "license" for more information. >>> import math >>> math.exp(1) 2.7182818284590451 >>> math.exp(2) 7.3890560989306504 >>> math.exp(-1) 0.36787944117144233 >>> math.exp(-.5) 0.60653065971263342 >>> math.exp(-0.5) 0.60653065971263342 >>> 4 * math.exp(-0.5) Bus error (core dumped) is it just me? any guesses what might be the cause of this?

3 10

python-dev summaries?
by Michael Hudson 15 Feb '01

15 Feb '01

I notice that it's nearly a fortnight since AMK's last summary. I've started to put together a sumamry of the last two weeks, but I thought I'd ask first if anyone else was planning to do the same. I'd gladly concede the tediu^Wbragging rights to someone else, although I would like the chance get something out if the evening I spent writing code to do things like this: Number of articles in summary: 495 80 | ]|[ | ]|[ | ]|[ | ]|[ | ]|[ ]|[ 60 | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ 40 | ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 20 | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 0 +-029-067-039-037-080-048-020-009-040-021-008-030-043-024 Thu 01| Sat 03| Mon 05| Wed 07| Fri 09| Sun 11| Tue 13| Fri 02 Sun 04 Tue 06 Thu 08 Sat 10 Mon 12 Wed 14 If noone else is planning on doing a sumamry, I'll post a draft for comments sometime tomorrow. Cheers, M. -- I'm sorry, was my bias showing again? :-) -- William Tanksley, 13 May 2000

2 1