Mailman 3 May 2005 - Python-Dev

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser May 18, 2005

May 18, 2005

Patch / Bug Summary ___________________ Patches : 339 open ( +7) / 2838 closed ( +4) / 3177 total (+11) Bugs : 938 open (+11) / 4962 closed ( +3) / 5900 total (+14) RFE : 187 open ( +1) / 157 closed ( +0) / 344 total ( +1) New / Reopened Patches ______________________ Restore GC support to set objects (2005-05-11) http://python.org/sf/1200018 opened by Barry A. Warsaw idlelib patch (2005-05-11) http://python.org/sf/1200038 opened by sowjanya Small optimization for PyDict_Merge() (2005-05-11) CLOSED http://python.org/sf/1200051 opened by Barry A. Warsaw buffer overflow in _cursesmodule.c (2005-05-11) http://python.org/sf/1200134 opened by Jan Michael Hülsbergen patch IDLE to allow running anonymous code in editor window (2005-05-13) http://python.org/sf/1201522 opened by Jeff Shute allow running multiple instances of IDLE (2005-05-13) http://python.org/sf/1201569 opened by Jeff Shute httplib mentions getreply instead of getresponse (2005-05-16) http://python.org/sf/1203094 opened by Robert Brewer workaround deprecated ostat structure in <sys/stat.h> (2005-05-17) http://python.org/sf/1203329 opened by J. J. Snitow Patch for [ 1163563 ] Sub threads execute in restricted mode (2005-05-17) http://python.org/sf/1203393 opened by anothermax Allow larger programs to be frozen under Win32 (2005-05-17) http://python.org/sf/1203650 opened by Gottfried Ganßauge Patches Closed ______________ Small optimization for PyDict_Merge() (2005-05-11) http://python.org/sf/1200051 closed by rhettinger better datetime support for xmlrpclib (2005-02-10) http://python.org/sf/1120353 closed by montanaro Add O_SHLOCK/O_EXLOCK to posix (2005-01-17) http://python.org/sf/1103951 closed by montanaro Fix _tryorder in webbrowser.py (2005-03-20) http://python.org/sf/1166780 closed by rodsenra New / Reopened Bugs ___________________ installation problem with python 2.4.1 on Win2k system (2005-05-11) http://python.org/sf/1199808 opened by mmkobayashi Python 2.4.1 Installer ended prematurely (2005-05-11) http://python.org/sf/1199947 opened by Wai Yip Tung time module ignores timezone changes (2005-05-09) CLOSED http://python.org/sf/1198275 reopened by bcannon Windows msi installer fails on virtual drives (2005-05-11) http://python.org/sf/1200287 opened by bartgrantham SyntaxError raised on win32 for correct files (2005-05-12) http://python.org/sf/1200686 opened by Federico Di Gregorio Wrong word on "raise" page (2005-05-13) CLOSED http://python.org/sf/1201438 opened by Erik Rose Problem with recursion in dict (crash with core dump) (2005-05-13) http://python.org/sf/1201456 opened by Vladimir Yu. Stepanov suspected cPickle memory leak (2005-05-13) http://python.org/sf/1201461 opened by Alan Glossary listing bug (2005-05-14) CLOSED http://python.org/sf/1201807 opened by George Yoshida mimetypes.py does not find mime.types on Mac OS X (2005-05-14) http://python.org/sf/1202018 opened by Stefan H. Holek Description of string.lstrip() needs improvement (2005-05-15) http://python.org/sf/1202395 opened by Roy Smith httplib docs mentioning HTTPConnection.getreply (2005-05-15) http://python.org/sf/1202475 opened by Georg Brandl RE parser too loose with {m,n} construct (2005-05-15) http://python.org/sf/1202493 opened by Skip Montanaro a bunch of infinite C recursions (2005-05-15) http://python.org/sf/1202533 opened by Armin Rigo Problem with abs function (2005-05-16) http://python.org/sf/1202946 opened by ric-b Bugs Closed ___________ time module ignores timezone changes (2005-05-09) http://python.org/sf/1198275 closed by bcannon SystemError: error return without exception set (2005-05-05) http://python.org/sf/1195984 closed by nbajpai Wrong word on "raise" page (2005-05-13) http://python.org/sf/1201438 closed by rhettinger Glossary listing bug (2005-05-14) http://python.org/sf/1201807 closed by rhettinger New / Reopened RFE __________________ enhancing os.chown functionality (2005-05-12) http://python.org/sf/1200804 opened by gyrof

1 0

Re: [Python-Dev] Example for PEP 343
by Delaney, Timothy C (Timothy) May 18, 2005

May 18, 2005

Bob Ippolito wrote: >> One more thought: Rather than just saving the precision, it is >> likely wiser, safer, and more general to just save and restore the >> whole context and let the wrapped block only work with a copy. >> >> oldcontext = decimal.getcontext() >> newcontext = oldcontext.copy() >> newcontext.prec += 2 >> yield None >> decimal.setcontext(oldcontext) >> >> This approach defends against various kinds of unruly behavior by the >> yield target. > > I think you're missing a decimal.setcontext(newcontext) before the > yield.. Seems to me this should be in the standard library ;) Tim Delaney

1 0

Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
by Phillip J. Eby May 18, 2005

May 18, 2005

At 06:56 PM 5/16/2005 +1000, Nick Coghlan wrote: >Anyway, I think it's stable enough now that I can submit it to be put up on >www.python.org (I'll notify the PEP editors directly once I fix a couple of >errors in the current version - like the missing 'raise' in the statement >semantics. . .). If you have developer checkin privileges, it's best to get a PEP number sooner rather than later, if the PEP shows any signs of viability at all. Once you're in the PEP infrastructure people can subscribe to get notified when you change it, read the revision history, and so on. Anyway, I took a look at it, and I mostly like it. There appears to be an error in "Deterministic generator finalisation" (maybe you already know this): the _inject_exception() should be called with exc_info, not TerminateIteration, and it should swallow StopIteration instead of TerminateIteration. IOW, I think it should look like this: def __exit__(self, *exc_info): try: self._inject_exception(*exc_info) except StopIteration: pass Hm. Oh wait, I just realized - you don't mean this at all. You're describing a use of generators as non-templates. Ugh. I think that might lead to confusion about the semantics of 'with' and generators. I'll have to think about it some more, but my second impression after a little bit of thought is that if you're going to do this, then you should be allowed to use 'with' with any object, using the object as VAR if there's no __enter__. My reasoning here is that it then makes it possible for you to use arbitrary objects for 'with' without needing to know their implementation details. It should be harmless to use 'with' on objects that don't need it. This insight may actually be true regardless of what generators do or don't do; the point is that if you change from using a generator to a built-in iterator type, you shouldn't have to change every place you were using the 'with' blocks to work again. A further part of this insight: perhaps the 'with' block translation should include a 'del VAR' in its finally block, not to mention the equivalent of 'del stmt_enter,stmt_exit'. In other words, the binding of VAR should not escape the 'with' block. This would mean that for existing types that use __del__ for cleanup (e.g. files and sockets), then 'with open("file") as f' would automatically ensure closing under CPython (but other implementations would be allowed to wait for GC). In other words, I'm saying that this: with some_expr() as foo: # etc. should also be short for this (in the case where some_expr() has no __enter__ or __exit__ methods): foo = some_expr() try: # etc. finally: del foo And that could be a useful thing for many existing object types, without even updating them for PEP 34[0-9]. :) It wouldn't be *as* useful for non-CPython implementations, but presumably by the time those implementations catch up, more code will be out there with __enter__/__exit__ methods. Also, by allowing a default __enter__ to exist (that returns self), many objects need only implement an __exit__. (For example, I don't see a point to closed file objects raising an error when used in a 'with' block; if you're actually using the file you'll already get an error when you use its other methods, and if you're not actually using it, there's no point to the error, since close() is idempotent.) So, at the C API level, I'm thinking something like Py_EnterResource(ob), that returns ob if ob has no tp_resource_enter slot defined, otherwise it returns the result of calling the method. Similarly, some sort of Py_ExitResource() that guarantees an error return after invoking the tp_resource_exit slot (if any). Finally, note that this extension now makes 'with' seem more like 'with' in other languages, because it is now just a scoped variable definition, with hooks for the object being scoped to be notified about entry and exit from scope. It does mean that people encountering 'with some_expr()' (without an "as") may wonder about whether names inside the scope are somehow relative to 'some_expr', but it will probably become clear from context, especially via appropriate names. For example 'with self.__locked' might provide that extra bit of clarity beyond 'with self.__lock'.

4 9

Example for PEP 343
by Michael Chermside May 17, 2005

May 17, 2005

In PEP 343 Guido writes: > 8. Another use for this feature is the Decimal context. It's left > as an exercise for the reader. (Mail it to me if you'd like to > see it here.) Here are two such examples. Pick your favorite for the PEP. PS: Writing this helped convince me that allowing the use of generators instead of classes with the "do_template" decorator is quite nice in practice, even though it gets confusing (for beginners anyhow) if you start to think about it too much. -- Michael Chermside # ===== SAMPLE #1: increasing precision during a sub-calculation ===== import decimal @do_template def with_extra_precision(places=2): "Performs nested computation with extra digits of precision." decimal.getcontext().prec += 2 yield None decimal.getcontext().prec -= 2 # == SAMPLE USE of #1 == # (Sample taken from the Python Library Reference) def sin(x): "Return the sine of x as measured in radians." do with_extra_precision(): i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1 while s != lasts: lasts = s i += 2 fact *= i * (i-1) num *= x * x sign *= -1 s += num / fact * sign return +s # ===== SAMPLE #2: insisting on exact calculations only ===== import decimal @do_template def assert_exact(): "Raises exception if nested computation is not exact." ctx = decimal.getcontext() was_inexact = ctx.traps[decimal.Inexact] ctx.traps[decimal.Inexact] = True yield None ctx.traps[decimal.Inexact] = was_inexact # == SAMPLE USE of #2 == # Lemma 2 ensures us that each fraction will divide evenly do assert_exact(): total = decimal.Decimal(0) for n, d in zip(numerators, denominators): total += n / d

1 0

RFC: rewrite fileinput module to use itertools.
by David M. Wilson May 16, 2005

May 16, 2005

Hi there, Before charging on ahead with this small task, I was wondering if anyone would have any objections to such an upgrade. It seems to me that itertools.chain() could come in handy there, at least. My only objection to the current implementation is that it doesn't reflect the current Python "best practice" for what it does, and it could be really simply made into a live demo of the itertools module. David.

2 1

Tidier Exceptions
by Ka-Ping Yee May 16, 2005

May 16, 2005

It occurred to me as i was messing around with handling and re-raising exceptions that tossing around these (type, value, traceback) triples is irritating and error-prone. How about just passing around a single value? All we'd have to do is put the traceback in value.traceback. Implementation: - "raise Class" and "raise Class, string" automatically set the .traceback attribute on the new instance of Class. - "raise instance" automatically sets the .traceback attribute on the instance unless it already has one. The behaviour of "except" and "sys.exc_*" could remain unchanged. "raise t, v, tb" would eventually be deprecated in favour of "raise v". -- ?!ng

7 16

Re: [Python-Dev] PEP 343 - Abstract Block Redux
by Delaney, Timothy C (Timothy) May 16, 2005

May 16, 2005

Steven Bethard wrote: > If I've misunderstood, and there are other situations when > "needs_finish" is required, it'd be nice to see some more examples. The other cases are where you want to do something in response to an exception, but not otherwise:: def gen(): try: yield except: print 'Got exception:', sys.exc_info() raise Personally, I think they're rare enough that you could use a decorator in those cases, but still have:: def gen(): try: yield finally: pass automatically make the generator conform to the do/with protocol. Tim Delaney

1 0

PEP 340 keyword: after
by "Martin v. Löwis" May 15, 2005

May 15, 2005

I haven't followed the PEP 340 discussion in detail, but as the PEP doesn't list keywords that have been considered and rejected, I'd like to propose my own: use "after" instead of "block": after opening("/etc/passwd") as f: for line in f: print line.rstrip() after locking(myLock): # code that needs to hold the lock Regards, Martin

7 7

Re: [Python-Dev] PEP 343 - Abstract Block Redux
by Delaney, Timothy C (Timothy) May 15, 2005

May 15, 2005

Shane Hathaway wrote: > PEP 340 is very nice, but it became less appealing to me when I saw > what it would do to "break" and "continue" statements. Absolutely. I really liked PEP 340, but two things stood out to me as being flawed: 1. Looping - it took a while for me to realise this was bugging me - the unintuitive behaviour of break and continue clarified it for me. 2. Not re-raising exceptions automatically. I actually proposed at one point that any exception should be re-raised at the end of the iterator finalisation unless another exception was raised (not StopIteration, etc). I still continue to support this. It also deals with the control-flow issue (being hidden). PEP 3XX has some other nice things. I have two opposing views on for-loops supporting finalisation of iterators though: 1. for-loops should support finalisation. However, in that case every iterator should be finalisable by default, and you should have to go out of your way to prevent it (or prevent forced exhaustion of the iterator). I think there's zero chance of this proposal being accepted ;) 2. for-loops should not support finalisation at all, and if you want finalisation semantics you need to enclose the for-loop in a do/with statement. I think the most important thing is that the semantics must be absolutely clear to someone looking at the code for the first time, without knowing the particulars of the statement being used. To me that suggests that the following 3 factors are the most important: 1. Non-looping semantics. Looping semantics require me to think more about the actual behaviour in the presence of break/continue. 2. An exception raised in the body of the statement must be propagated outside of the statement. I'm willing to accept another exception being raised in its place, but in that case I think it would be a good idea to chain the exceptions in some way. In any case, if the body of the statement terminates abnormally, it should not be possible for the statement to change that abnormal exit. 3. There should be a single statement (other than try...finally) that has finalisation semantics i.e. for-loop doesn't. Tim Delaney

1 0

Loading compiled modules under MSYS/MingGW?
by Steve Castellotti May 15, 2005

May 15, 2005

Hey all- Simple question. I'm working on getting Python support enabled for the Gimp under Win32. I've set up and successfully compiled the Gimp under a MSYS/MinGW enviroment, using both python.org Python 2.3 and ActivePython 2.3 (I need to stick to 2.3 due to support issues with the packaging software I'm using) Both versions of Python give me the same problem when I try to load the "gimpfu" module (used for accessing Gimp functions from within Python programs) Sample Script: import sys sys.path.insert(1, '/local/lib/gimp/2.0/python/') import gimpfu print "cool" Execution: $ ./test Traceback (most recent call last): File "./test", line 7, in ? import gimpfu File "E:\msys\1.0\local\lib\gimp\2.0\python\gimpfu.py", line 65, in ? import gimp ImportError: No module named gimp Directory listing: $ ls /local/lib/gimp/2.0/python/ gimpenums.py gimpmodule.a gimpprocbrowsermodule.a gimpui.py gimpfu.py gimpmodule.la gimpprocbrowsermodule.la pygimp-logo.png gimpfu.pyc gimpplugin.py gimpshelf.py ...Python is finding gimpfu.py, but doesn't see "gimpmodule.[a,la]" .. this directory listing is similar to what you would find under a linux compilation, except linux also creates a "gimpmodule.so" library file. Am I missing something obvious? Is this a question better suited to MinGW/MSYS mailing lists, or perhaps the Gimp list? If so, what's the right kind of question(s) I need to be asking? It seems to me that the compile is going through just fine, but somethings not getting built correctly and Python can't see that module. Cheers in advance, Steve Castellotti

2 1