Mailman 3 May 2005 - Python-Dev

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

May 11, 2005

Patch / Bug Summary ___________________ Patches : 332 open (+10) / 2834 closed ( +2) / 3166 total (+12) Bugs : 927 open ( +7) / 4959 closed ( +7) / 5886 total (+14) RFE : 186 open ( +0) / 157 closed ( +1) / 343 total ( +1) New / Reopened Patches ______________________ Feature enhancement for C socket module (2005-05-03) http://python.org/sf/1194378 opened by Heiko Wundram pydoc requires o.__nonzero__() = True (2005-05-03) http://python.org/sf/1194449 opened by Jay T Miller [AST] throw SyntaxError in "from x import y," (2005-05-03) http://python.org/sf/1194895 opened by logistix simple callback system for Py_FatalError (2005-05-05) http://python.org/sf/1195571 opened by m utku in IDLE, assume new text files are python source by default (2005-05-06) http://python.org/sf/1196895 opened by Jeff Shute smarter behaviour for home key in IDLE (2005-05-06) http://python.org/sf/1196903 opened by Jeff Shute change recall in IDLE shell to not overwrite current command (2005-05-06) http://python.org/sf/1196917 opened by Jeff Shute allow using normal indent width in shell in IDLE (2005-05-06) http://python.org/sf/1196946 opened by Jeff Shute _ssl.mak Makefile patch (Win32) (2005-05-07) http://python.org/sf/1197150 opened by Joachim Kessel Add proxies arg to urllib.urlretrieve (2005-05-07) http://python.org/sf/1197207 opened by John Dubery test_locale fix on modern linux (2005-05-07) http://python.org/sf/1197218 opened by Anthony Baxter Cygwin case-sensitive import patch (2005-05-07) http://python.org/sf/1197318 opened by Jason Tishler Patches Closed ______________ Minimal cleanup of run.py (2005-04-26) http://python.org/sf/1190163 closed by kbk Decimal interaction with __rop__ (2005-03-19) http://python.org/sf/1166602 closed by facundobatista New / Reopened Bugs ___________________ parsedate and Y2K (2005-05-02) http://python.org/sf/1194222 opened by Mark Nottingham Minor bug in urllib docs (2005-05-03) http://python.org/sf/1194249 opened by Georg Brandl Reading from a killed shell script with popen* under linux (2005-05-03) http://python.org/sf/1194328 opened by Vinz ImportError: No module named os (2005-05-03) CLOSED http://python.org/sf/1194497 opened by Will L G [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings (2005-05-04) http://python.org/sf/1195576 opened by logistix SystemError: error return without exception set (2005-05-05) http://python.org/sf/1195984 opened by Niraj Bajpai Error: ... ossaudiodev.c, line 48: Missing type specifier (2005-05-05) http://python.org/sf/1196154 opened by Will L G WeakValueDictionary.__init__ is backwards (2005-05-05) http://python.org/sf/1196315 opened by Pavel Pergamenshchik string.rstrip strips more than supposed to in some cases (2005-05-06) CLOSED http://python.org/sf/1196824 opened by Francois Payette trivial bug in error message text (2005-05-06) http://python.org/sf/1196980 opened by Jeff Shute % gives wrong results (2005-05-08) CLOSED http://python.org/sf/1197806 opened by Jonathan Installation path sent to configure (2005-05-09) http://python.org/sf/1197883 opened by Björn Lindqvist time module ignores timezone changes (2005-05-09) CLOSED http://python.org/sf/1198275 opened by David Lambert string.Template not flexible enough to subclass (regexes) (2005-05-09) http://python.org/sf/1198569 opened by Ian Bicking subprocess _active.remove(self) self not in list _active (2005-05-10) http://python.org/sf/1199282 opened by cheops Bugs Closed ___________ SimpleHTTPServer sends wrong c-length and locks up client (2005-04-26) http://python.org/sf/1190580 closed by alexanderweb ImportError: No module named os (2005-05-03) http://python.org/sf/1194497 closed by rhettinger Error in section 4.2 of Python Tutorial (2005-05-02) http://python.org/sf/1194209 closed by rhettinger Error in section 4.2 of Python Tutorial (2005-05-02) http://python.org/sf/1194209 closed by rhettinger string.rstrip strips more than supposed to in some cases (2005-05-06) http://python.org/sf/1196824 closed by goodger % gives wrong results (2005-05-08) http://python.org/sf/1197806 closed by mwh time module ignores timezone changes (2005-05-09) http://python.org/sf/1198275 closed by bcannon calendar.weekheader not found in __all__ (2005-05-02) http://python.org/sf/1193890 closed by rhettinger RFE Closed __________ logging module root logger name (2005-04-27) http://python.org/sf/1190689 closed by vsajip

1 0

Re: [Python-Dev] The decorator module
by Michele Simionato May 10, 2005

May 10, 2005

On 5/6/05, Jim Jewett <jimjjewett(a)gmail.com> wrote: > Thank you; this is very good. > > I added a link to it from http://www.python.org/moin/PythonDecoratorLibrary; > please also consider adding a version number and publishing via PyPI. Yes, this was in my plans. For the moment, however, this is just version 0.1, I want to wait a bit before releasing an official release. > Incidentally, would the resulting functions be a bit faster if you compiled > the lambda instead of repeatedly eval ing it, or does the eval overhead still > apply? > > -jJ > Honestly, I don't care, since "eval" happens only once at decoration time. There is no "eval" overhead at calling time, so I do not expect to have problems. I am waiting for volunteers to perform profiling and performance analysis ;) Michele Simionato

4 8

PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
by Jim Jewett May 10, 2005

May 10, 2005

Nick Coghlan <ncoghlan at gmail.com> wrote: > Josiah Carlson wrote: >> This has the benefit that an arbitrary block of code can be named, >> and a named TerminateBlock used to exit it. >> ... I suspect any such implementation is going to need to use >> exceptions for the guts of the flow control, even if that use isn't >> visible to the programmer. > Not necessarily. If I were implementing such a thing; any time > arbitrary break/continues (to a loop that isn't the deepest) were used > in nested loops, I would increment a counter any time a loop was entered, > and decrement the counter any time a loop was exited. ... When named blocks are used in Lisp, they often cross function boundaries. Given that, the number of intervening loops could change depending on external variables. Since you would have to pop frames anyhow, Exceptions are the right way to do it. If you limited the named-block gotos to within a single function/method, then the loop counter would work (and you could limit obfuscation). Unfortunately, you would lose most of the power of named blocks, while still paying the full ugliness price. You would also encourage people to inline things that ought to be separate functions. In case it isn't clear, I think named loops would be a mistake. I wanted them when I first started, but ... at the moment, I can't think of any usage that wasn't an ugly speed hack, which is at least more explicit with the "raise Found" idiom. -jJ

4 3

PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
by Jim Jewett May 10, 2005

May 10, 2005

Nick Coghlan wrote: > "Loop on this iterator and finalise when done" would be written: > for item in itr: > process(item) > finally: > pass Greg Ewing wrote: > This is approaching things from the wrong end. The user of > an iterator shouldn't need to know or care whether it > requires finalization -- it should Just Work, whatever > context it is used in. If you're saying "lists don't need it, but openfiles do", then I agree; it shouldn't matter what type of iterator you have. If you're talking specific object instances, then the user is the only one (outside of the Garbage Collection system) who has a chance of knowing whether the rest of the iterator will be needed later. When iterating over lines in a file, and breaking out at a sentinel, the compiler can't know whether you're done, or just leaving the "real" lines to another piece of code. Of course, that still raises the "Why are we encouraging bugs?" issue. If there are no remaining references, then garbage collection is the answer, and maybe we just need to make it more aggressive. If there are remaining references, then maybe the user is wrong about being done. -jJ

2 1

Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
by Nick Coghlan May 9, 2005

May 9, 2005

Raymond Hettinger wrote: > [Nick Coghlan] > >>The number of good use cases for a looping block statement currently >>stands at >>exactly 1 (auto_retry). Every other use case suggested (locking, > > opening, > >>suppressing, etc) involves factoring out try statement boiler plate > > that > >>is far >>easier to comprehend with a single pass user defined statement. > > > I would like to offer up one additional use case, eliminating redundant > code in a do-while construct: > > > def do_while(cond_func): > yield > while cond_func(): > yield > > block do_while(lambda: a>b): > <sequence of actions affecting a and b> Nice example, but it doesn't need to intercept exceptions the way auto_retry does. Accordingly, a 'for' loop which makes [VAR in] optional would do the job just fine: for do_while(lambda: a>b): <do it> Even today, the following works: def do_while(cond_func): yield None while cond_func(): yield None for _ in do_while(lambda: a>b): <do it> Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

1 0

Re: [Python-Dev] Proposed alternative to __next__ and __exit__
by Oren Tirosh May 7, 2005

May 7, 2005

I suggest using a variation on the consumer interface, as described by Fredrik Lundh at http://effbot.org/zone/consumer.htm : .next() -- stays .next() .__next__(arg) -- becomes .feed(arg) .__exit__(StopIteration, ...) -- becomes .close() .__exit__(..,..,..) -- becomes .feed(exc_info=(..,..,..)) Extensions to effbot's original consumer interface: 1. The .feed() method may return a value 2. Some way to raise an exception other than StopIteration inside the generator/consumer function. The use of a keyword argument to .feed is just an example. I'm looking for other suggestions on this one. No new builtins. No backward-compatibility methods and wrappers. Yes, it would have been nicer if .next() had been called __next__() in the first place. But at this stage I feel that the cost of "fixing" it far outweighs any perceived benefit. so much for "uncontroversial" parts! :-) Oren On 5/6/05, Guido van Rossum <gvanrossum(a)gmail.com> wrote: > [Steven Bethard] > > So, just to make sure, if we had another PEP that contained from PEP 340[1]: > > * Specification: the __next__() Method > > * Specification: the next() Built-in Function > > * Specification: a Change to the 'for' Loop > > * Specification: the Extended 'continue' Statement > > * the yield-expression part of Specification: Generator Exit Handling > > would that cover all the pieces you're concerned about? > > > > I'd be willing to break these off into a separate PEP if people think > > it's a good idea. I've seen very few complaints about any of these > > pieces of the proposal. If possible, I'd like to see these things > > approved now, so that the discussion could focus more directly on the > > block-statement issues. > > I don't think it's necessary to separate this out into a separate PEP; > that just seems busy-work. I agree these parts are orthogonal and > uncontroversial; a counter-PEP can suffice by stating that it's not > countering those items nor repeating them. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/oren.tirosh%40gmail.com >

1 0

Breaking off Enhanced Iterators PEP from PEP 340
by Jim Jewett May 6, 2005

May 6, 2005

Enhanced Iterators: ... > When the *initial* call to __next__() receives an argument > that is not None, TypeError is raised; this is likely caused > by some logic error. This made sense when the (Block) Iterators were Resources, and the first __next__() was just to trigger the setup. It makes less sense for general iterators. It is true that the first call in a generic for-loop couldn't pass a value (as it isn't continued), but I don't see anything wrong with explicit calls to __next__. Example: An agent which responds to the environment; the agent can execute multi-stage plans, or change its mind part way through. action = scheduler.__next__(current_sensory_input) -jJ

2 1

Re: [Python-Dev] PEP 340 - For loop cleanup, and feature separation
by Phillip J. Eby May 6, 2005

May 6, 2005

At 01:58 PM 5/6/2005 +1000, Delaney, Timothy C (Timothy) wrote: >Personally, I'm of the opinion that we should make a significant break >(no pun intended ;) and have for-loops attempt to ensure that iterators >are exhausted. This is simply not backward compatible with existing, perfectly valid and sensible code. Therefore, this can't happen till Py3K. The only way I could see to allow this is if: 1. Calling __iter__ on the target of the for loop returns the same object 2. The for loop owns the only reference to that iterator. However, #2 is problematic for non-CPython implementations, and in any case the whole thing seems terribly fragile. So how about this: calling __exit__(StopIteration) on a generator that doesn't have any active blocks could simply *not* exhaust the iterator. This would ensure that any iterator whose purpose is just iteration (i.e. all generators written to date) still behave in a resumable fashion. Ugh. It's still fragile, though, as adding a block to an iterator will then make it behave differently. It seems likely to provoke subtle errors, arguing again in favor of a complete separation between iteration and block protocols.

2 1

PEP 340 -- loose ends
by Guido van Rossum May 6, 2005

May 6, 2005

These are the loose ends on the PEP (apart from filling in some missing sections): 1. Decide on a keyword to use, if any. 2. Decide on the else clause. 3. Decide on Phillip Eby's proposal to have a different API for blocks, so you would have to use a @decorator to turn a generator into something usable in a block. Here are my strawman decisions, to the extent that I'm clear on them: 1. I still can't decide on keyword vs. no keyword, but if we're going to have a keyword, I haven't seen a better proposal than block. So it's either block or nothing. I'll sleep on this. Feel free to start an all-out flame war on this in c.l.py. ;-) 2. No else clause; the use case is really weak and there are too many possible semantics. It's not clear whether to generalize from for/else, or if/else, or what else. 3. I'm leaning against Phillip's proposal; IMO it adds more complexity for very little benefit. Unless there's more discussion on any of these, I'll probably finish up the PEP and post it to c.l.py in a few days. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

15 32

PEP 340 - Remaining issues
by Paul Moore May 6, 2005

May 6, 2005

On 5/5/05, Steven Bethard <steven.bethard(a)gmail.com> wrote: > I wonder if it would be possible to update PEP 310 with your ideas, > or perhaps start a new PEP? I'd like to see a competitor for PEP 340 that > addresses some of the issues that came up, e.g. that the block-statement > doesn't look like a loop, so break and continue might look like they break > out of an enclosing loop. In an attempt to bring things back under control, can I summarise what I believe are the outstanding issues? 1. Choice (or not) of a keyword. I honestly believe that there will never be a consensus on this, and we'd be better deferring the decision to Guido's judgement. 2. Separate protocol or not? I'm not entirely sure I have a view on this, but it feels related to the looping question below. I do like being able to write these things as generators, and I don't mind needing a decorator (although I, personally, don't feel a compelling *need* for one). 3. Looping blocks, and the break issue. I see a consensus forming here that blocks should *not* loop. No-one has come up with a strong case for looping blocks, except the auto_retry example, and Nick (I think it was Nick Coghlan, sorry if my memory is wrong) demonstrated how to build this case from a for loop and a non-looping block. Given that Guido has stated that he is willing to accept a consensus decision on changes to the PEP, can I suggest that rather than writing a competitor, someone (who understands the technicalities better than me) simply propose a modification to PEP 340 that does not loop[1]. I think the separate protocol issue is subtler - maybe it's just a case of renaming some methods and specifying a decorator, but I really don't understand the issues at this depth. I apologise if this post (1) misrepresents anyone's view, or (2) hinders things rather than helping. But I feel that we are pretty close to a solution here, and I fear that more competing PEPs will simply muddy the waters. Paul. [1] My simplistic view is that you may be able to get away with changing the specification of the anonymous blok statement's expansion just to remove the "while True". There's some fixup needed to avoid the one "break" in the expansion, and probably a lot of little details that make this far harder than I'm assuming - but maybe that's the starting point...

5 5