[Jim Jewett]
> > 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.
[Greg Ewing]
> I'm incli
Apologies if this has been discovered and rejected already; I've had
to skip most of the discussions but this though won't leave my head...
So PEP 310 proposes this:
with VAR = EXPR:
BLOCK
translated to
VAR = EXPR\
if hasattr(VAR, "__enter__"):
VA
Jim Jewett wrote:
> 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.
Indeed. He *does* know whether he will want the iterator
again later
Jim Jewett wrote:
> 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.
I'm inclined to agree. Any
Nick Coghlan wrote:
> This bloats the generated byte code horribly, though - it is necessary to
> produce two complete copies of the for loop code, since we don't know at
> compile
> time which version (finalising or non-finalising) will be needed.
Unless I'm seriously mistaken, all the Python
Josiah Carlson wrote:
> 2. Standard for/while loops should not be finalized in a timely fashion,
> because testing for the proper methods would necessarily slow down large
> amounts of current Python, so should be left to the garbage collector.
I'm not convinced about that. If implemented properl
Ron Adam wrote:
> That's sort of why I'm against changing 'for', and for adding
> the new loop/block. I see it as a loop with a higher level of
> abstraction. A new tool to be used in new ways, but I want to keep my
> old dependable tools too.
But if there's too much overlap in functionality
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > I wasn't expressing my opinion, I was attempting to express as to where
> > the discussion went and concluded. I honestly can't remember having an
> > opinion on the subject, but I seem to have convinced Nick earlier that
> > they
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
M.-A. Lemburg wrote:
> I think we should remove the defaulting to whatever
> TCL uses and instead warn the user about a possible
> problem in case TCL is found and uses a Unicode
> width which is incompatible with Python's choice.
-1.
Regards,
Martin
__
M.-A. Lemburg wrote:
> On sre character classes: I don't think that these provide
> a good approach to XML lexical classes - custom functions
> or methods or maybe even a codec mapping the characters
> to their XML lexical class are much more efficient in
> practice.
That isn't my experience: func
Josiah Carlson wrote:
>> Ron Adam <[EMAIL PROTECTED]> wrote:
>>Yes, so just "do [VAR from] EXPR1:"
>
> Regardless of the 'finalization' syntax, I'm talking about the fact that
> including extra 'if EXPR' or 'while EXPR' is not going to be an option.
Yes, I meant for the syntax to be the shorte
Ron Adam <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Ron Adam <[EMAIL PROTECTED]> wrote:
> >
> >> There's also the possibility to use conditional looping based on the
> value returned from the generator.
> >>
> >> do VAR from EXPR if VAR==CONST:
> >>BLOCK
> >>
> >> Th
Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan 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
> >> exceptio
Josiah Carlson wrote:
> I wasn't expressing my opinion, I was attempting to express as to where
> the discussion went and concluded. I honestly can't remember having an
> opinion on the subject, but I seem to have convinced Nick earlier that
> they shouldn't loop, and he (re-)convinced me that in
Greg Ewing wrote:
> Ron Adam wrote:
>
>>There seems to be some confusion as to weather or
>>not 'for's will do finalizing. So I was trying to stress I think
>>regular 'for' loops should not finalize. They should probably give an
>>error if an object with an try-finally in them or an __exit__
Greg Ewing wrote:
> Ron Adam wrote:
>> There seems to be some confusion as to weather or
>> not 'for's will do finalizing. So I was trying to stress I think
>> regular 'for' loops should not finalize. They should probably give an
>> error if an object with an try-finally in them or an __exit__ met
Josiah Carlson wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>
>> There's also the possibility to use conditional looping based on the
value returned from the generator.
>>
>> do VAR from EXPR if VAR==CONST:
>>BLOCK
>>
>> This is a bit verbose, but it reads well. :-)
>
>
>
> Readin
[Python used to always default to UCS2-Unicode builds;
this was changed to default to whatever a possibly installed
TCL system is using - hiding the choice from the user
and in effect removing the notion of having a Python
Unicode default configuration]
Martin v. Löwis wrote:
> M.-A. Lemburg w
At 01:08 AM 5/9/2005 -0400, Michele Simionato wrote:
>On 5/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > In this case, the informally-discussed proposal is to add a mutable
> > __signature__ to functions, and have it be used by inspect.getargspec(), so
> > that decorators can copy __signature
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>Unicode has many code points that are meant only for composition
>>and don't have any standalone meaning, e.g. a combining acute
>>accent (U+0301), yet they are perfectly valid code points -
>>regardless of UCS-2 or UCS-4. It is easily possible to
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
>
Nick Coghlan 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'
Greg Ewing wrote:
> Ron Adam wrote:
>
>>There seems to be some confusion as to weather or
>>not 'for's will do finalizing. So I was trying to stress I think
>>regular 'for' loops should not finalize. They should probably give an
>>error if an object with an try-finally in them or an __exit__ m
Nick Coghlan wrote:
> "Loop on this iterator and finalise when done" would be written:
>
>for item in itr:
>process(item)
>finally:
>pass
This is approaching things from the wrong end. The user of
an iterator shouldn't need to know or care whether it
requires finalization
25 matches
Mail list logo
