Guido van Rossum wrote:
> Oops. Read the most recent version of the PEP again. __next__()
> doesn't take an exception argument, it only takes a value. Maybe this
> removes your concern?
Actually, I misinterpreted it, assuming that the value passed in was an
exception instance because the previous
Patch / Bug Summary
___
Patches : 322 open ( +6) / 2832 closed ( +1) / 3154 total ( +7)
Bugs: 920 open (+12) / 4952 closed (+11) / 5872 total (+23)
RFE : 186 open ( +8) / 156 closed ( +3) / 342 total (+11)
New / Reopened Patches
__
Info Asso
[Delaney, Timothy]
> What I meant is that there are no examples of how to
> actually implement the correct semantics for a normal iterator. Doing it
> right is non-trivial, especially with the __next__ and __exit__
> interaction (see below).
Depends on what you mean by right. Ignoring the argument
Guido van Rossum wrote:
> [Delaney, Timothy]
>> PEP 340 does not address "normal" iterators very well, but a
>> properly-constructed iterator will behave correctly.
>
> This is by design.
Yep - I agree.
>> The PEP though is very generator-focussed.
>
> Disagree. The PEP describes most everythi
[Delaney, Timothy]
> PEP 340 does not address "normal" iterators very well, but a
> properly-constructed iterator will behave correctly.
This is by design.
> The PEP though is very generator-focussed.
Disagree. The PEP describes most everything (e.g. the block statement
semantics) in terms of it
Phillip J. Eby wrote:
> Specifically, I propose that PEP 340 *not* allow the use of "normal"
> iterators. Instead, the __next__ and __exit__ methods would be an
> unrelated protocol. This would eliminate the need for a 'next()'
> builtin,
> and avoid any confusion between today's iterators and
At 09:39 PM 5/2/05 -0400, Phillip J. Eby wrote:
>attempt to recap here, and then step to allow discussion. If there's no
Argh. That was supposed to be, "step aside to allow discussion".
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
At 05:55 PM 5/2/05 -0700, Guido van Rossum wrote:
>3. I'm leaning against Phillip's proposal; IMO it adds more complexity
>for very little benefit.
Little benefit, I'll agree with, even though there are EIBTI and TOOWTDI
benefits as well as Errors Should Never Pass Silently. But the only added
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
Walter Dörwald wrote:
> [...]
> def blist(list):
> def enter(parent=None):
Of course this was meant to be:
class blist(list):
der enter(self, parent=None):
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Reading PEP 340, it seems to me that blocks could be used for generating
nested data structures:
def blist(list):
def enter(parent=None):
if parent:
parent.append(self)
yield self
x = blist()
block x.enter() as x:
x.append(1
[Guido, prsenting a use case]
> > block locking(myLock, timeout=30):
> > ...code executed with lock held...
> > else:
> > ...code executed if lock not acquired...
[Anders Munch]
> A file-closing block function has the same need, as does any block
> function that manages a resource,
On 4/29/05, Reinhold Birkenfeld wrote:
> Date: Sat, 30 Apr 2005 00:53:12 +0200
> From: Reinhold Birkenfeld <[EMAIL PROTECTED]>
> Subject: [Python-Dev] Re: PEP 340 - possible new name for
>block-statement
> To: python-dev@python.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/pla
On Mon, 02 May 2005 07:46:31 -0600, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>Anders J. Munch wrote:
>> in opening('file1') as f1:
>> ...
>> in opening('file2') as f2:
>> ...
>> except IOError:
>> print "file1 not available, I'll try again later"
>>
>> I
Anders> How do I tell try/except that I really only meant to trap
Anders> opening('file1'), but opening 'file2' is not supposed to fail so
Anders> I want any exception from that propagated? Better if I could
Anders> write:
Anders> in opening('file1') as f1:
Anders>
Anders J. Munch wrote:
> in opening('file1') as f1:
> ...
> in opening('file2') as f2:
> ...
> except IOError:
> print "file1 not available, I'll try again later"
>
> I rather like this version, because it is patently clear what should
> happen if there
Hi Rijish-
The python-dev list is for developers *of* python, not for people
developing *with* python. I'd recommend you post this on the
python-list, but I see you already have. You'll find they can be very
helpful, if you show that you've done some research, and ask a specific
question. A sub
GvR wrote:
> [Nick Coghlan]
> > Option 2: mimic if semantics
> >An 'else' clause on a block statement behaves vaguely like the else
clause on
> > an if statement - the clause is executed only if the first suite is
never
> > entered, but no exception occurs (i.e. StopIteration is raised by the
f
hello all
I am a member of a team dedicated to make a client server database application and our main concern is the speed with which the system performs. we are very new to python. but after reading a lot of documents and consulting some experts we decided to work it out using PYTHON. we plan
19 matches
Mail list logo
