Re: [Python-Dev] Re: anonymous blocks

On 4/24/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:12 PM 4/24/05 -0600, Steven Bethard wrote: > >I guess it would be helpful to see example where the looping > >with-block is useful. > > Automatically retry an operation a set number of times before hard failure: > > with auto_retr

Re: [Python-Dev] Re: anonymous blocks

At 09:12 PM 4/24/05 -0600, Steven Bethard wrote: I guess it would be helpful to see example where the looping with-block is useful. Automatically retry an operation a set number of times before hard failure: with auto_retry(times=3): do_something_that_might_fail() Process each row of a

Re: [Python-Dev] Re: anonymous blocks

On Apr 24, 2005, at 11:57 PM, Phillip J. Eby wrote: At 11:39 PM 4/24/05 -0400, Bob Ippolito wrote: On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote: At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: So a block could return a value to the generator using a return statement; the generator can catc

Re: [Python-Dev] Re: anonymous blocks

At 11:39 PM 4/24/05 -0400, Bob Ippolito wrote: On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote: At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: So a block could return a value to the generator using a return statement; the generator can catch this by catching ReturnFlow. (Syntactic sugar coul

Re: [Python-Dev] Re: anonymous blocks

On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote: At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: So a block could return a value to the generator using a return statement; the generator can catch this by catching ReturnFlow. (Syntactic sugar could be "VAR = yield ..." like in Ruby.) [uncontro

Re: [Python-Dev] Re: anonymous blocks

At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: So a block could return a value to the generator using a return statement; the generator can catch this by catching ReturnFlow. (Syntactic sugar could be "VAR = yield ..." like in Ruby.) [uncontrolled drooling, followed by much rejoicing] If this w

Re: [Python-Dev] Re: anonymous blocks

Guido van Rossum wrote: [snip illustration of how generators (and other iterators) can be modified to be used in with-blocks] > the most common use case should not be an alternate looping syntax > (even though it *is* technically a loop) but a more general "macro > statement expansion" I'm sure I

[Python-Dev] zipfile still has 2GB boundary bug

The "2GB bug" that was supposed to be fixed in was not actually fixed. The zipinfo offsets in the structures are still signed longs, so the fix allows you to write one file that extends past the 2G boundary, but if any extend past that point you are screwed. I ha

Re: [Python-Dev] Re: anonymous blocks

Guido van Rossum wrote: [SNIP] > Now let me propose a strawman for the translation of the latter into > existing semantics. Let's take the generic case: > > with VAR = EXPR: > BODY > > This would translate to the following code: [SNIP] > > it = EXPR > err = None > while T

[Python-Dev] site enhancements (request for review)

A few weeks ago I put together a patch to site.py for Python 2.5 that solves three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can ha

Re: [Python-Dev] Re: anonymous blocks

Guido van Rossum wrote: but for backwards compatibility with the existing argument-less next() API I'm introducing a new iterator API next_ex() which takes an exception argument. If that argument is None, it should behave just like next(). Otherwise, if the iterator is a generator, this will Migh

[Python-Dev] Re: anonymous blocks

After reading a lot of contributions (though perhaps not all -- this thread seems to bifurcate every time someone has a new idea :-) I'm back to liking yield for the PEP 310 use case. I think maybe it was Doug Landauer's post mentioning Beta, plus scanning some more examples of using yield in Ruby.

Re: [Python-Dev] PEP 310 and exceptions

Toby Dickenson wrote: On Sunday 24 April 2005 07:42, Nick Coghlan wrote: Shane Hathaway wrote: While we're on the subject of block handler method names, do the method names need four underscores? 'enter' and 'exit' look better than '__enter__' and '__exit__'. I quite like .acquire() and .releas

Re: [Python-Dev] Re: __except__ use cases

Hi Nick, On Sun, Apr 24, 2005 at 12:40 +1000, Nick Coghlan wrote: > Seeing this example has convinced me of something. PEP 310 should use the > 'with' keyword, and 'expression block' syntax should be used to denote the > 'default object' semantics proposed for Python 3K. For example: While tha

Re: [Python-Dev] Proper place to put extra args for building

OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way you wanted. I also wasn't sure of compatibility for Distutils (first time touching it); checked PEP 291 but Distutils wasn't listed. I went ahead and u

Re: [Python-Dev] PEP 310 and exceptions

Toby Dickenson <[EMAIL PROTECTED]> wrote: > > On Sunday 24 April 2005 07:42, Nick Coghlan wrote: > > Shane Hathaway wrote: > > > > While we're on the subject of block handler method names, do the method > > > names need four underscores? 'enter' and 'exit' look better than > > > '__enter__' and

Re: [Python-Dev] PEP 310 and exceptions

On Sunday 24 April 2005 07:42, Nick Coghlan wrote: > Shane Hathaway wrote: > > While we're on the subject of block handler method names, do the method > > names need four underscores? 'enter' and 'exit' look better than > > '__enter__' and '__exit__'. I quite like .acquire() and .release(). T

Re: [Python-Dev] Re: __except__ use cases

On Sun, 24 Apr 2005, Nick Coghlan wrote: [...] > Seeing this example has convinced me of something. PEP 310 should use the > 'with' > keyword, and 'expression block' syntax should be used to denote the 'default > object' semantics proposed for Python 3K. For example: > > class Key2AttributeErro

Re: [Python-Dev] Error checking in init functions

Hi Thomas, On Fri, Apr 22, 2005 at 04:57:26PM +0200, Thomas Heller wrote: > PyMODINIT_FUNC > PyInit_zlib(void) > { > m = Py_InitModule4("zlib", zlib_methods, > zlib_module_documentation, > (PyObject*)NULL,PYTHON_API_VERSION); I've seen a lot of code l