Guido van Rossum wrote:
>>Maybe generators are not the way to go, but could be
>>supported natively by providing a __block__ function, very similarly to
>>sequences providing an __iter__ function for for-loops?
>
> Sorry, I have no idea what you are proposing here.
I was suggesting that the featu
Paul Moore <[EMAIL PROTECTED]> writes:
> On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so
>> updating it with any of my ideas would be their call.
>
> I'm willing to consider an update - I don't know Michael's view.
Paul Moore wrote:
> On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> 2. Manual protocol implementations are _significantly_ easier to write
>
> Hmm, I've not tried so I'll have to take your word for this. But I
> don't imagine writing manual implementations much - one of the key
> features
On 5/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Seems to me it should be up to the block iterator whether
> a break statement gets caught or propagated, since it's
> up to the block iterator whether the construct behaves
> like a loop or not.
>
> This could be achieved by having a separate exce
On 5/5/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/5/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> > And does your proposal allow for "continue EXPR" as supported by PEP
> > 340? I can't see that it could, given that your proposal treats block
> > statements as not being loops.
>
> Read PEP
Delaney, Timothy C (Timothy) wrote:
> In this scenario (and I'm not saying I approve or disapprove) I think
> BreakIteration should inherit from StopIteration (thus retaining the
> existing PEP 340 semantics if uncaught)::
Not sure I understand. The point of my suggestion was
to *not* retain exis
Simon Percivall wrote:
> And this is not confusing in what way?
I don't think it's any less confusing than having a
construct in the first place which can either be a
loop or not. You need to know the semantics of the
block iterator in order to know whether it's a loop.
Once you know that, you kn
Seems to me it should be up to the block iterator whether
a break statement gets caught or propagated, since it's
up to the block iterator whether the construct behaves
like a loop or not.
This could be achieved by having a separate exception
for breaks, as originally proposed.
If the iterator pr
On 6 maj 2005, at 03.55, Greg Ewing wrote:
> Seems to me it should be up to the block iterator whether
> a break statement gets caught or propagated, since it's
> up to the block iterator whether the construct behaves
> like a loop or not.
And this is not confusing in what way? Making it depend
me
Greg Ewing wrote:
> Seems to me it should be up to the block iterator whether
> a break statement gets caught or propagated, since it's
> up to the block iterator whether the construct behaves
> like a loop or not.
>
> This could be achieved by having a separate exception
> for breaks, as origina
On 5/5/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> And does your proposal allow for "continue EXPR" as supported by PEP
> 340? I can't see that it could, given that your proposal treats block
> statements as not being loops.
Read PEP 340 again -- the "continue EXPR" syntax is orthogonal to the
dis
On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so
> updating it with any of my ideas would be their call.
I'm willing to consider an update - I don't know Michael's view. I
currently find myself in the odd situation of d
On Fri, 6 May 2005, Nick Coghlan wrote:
> Either way, my latest and greatest version of the non-looping block statement
> semantics can be found here:
> http://mail.python.org/pipermail/python-dev/2005-May/053400.html
My mind is not made up, but i did find this proposal pretty appealing.
I'd love
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Thu, 5 May 2005, Josiah Carlson wrote:
> > Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > > continue with 2
> >
> > There is something aboutthat I just don't like.
>
> Just to clarify: if by you mean "nesting level", did it appear
> that the 2 i
Eric Nieuwland wrote:
> This is linear. No looping whatsoever. And easily translated to a
> simple language construct and a protocol:
>
> class resource(object):
> def __init__(self,...):
> # store resource parameters
> def __acquire__(self):
> # whatever
Steven Bethard 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 mig
On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > Makes me wonder if we shouldn't just return to the __enter__() and
> > __exit__() names of PEP 310[1] where for a generator __enter__() is
> > just an alias for next(). We could even require Phillip J. Eby's
> > "blockg
Ronald Oussoren wrote:
> What's bothering me about the proposed semantics is that block
> statement behaves like a loop while most use cases do no looping
> whatsoever.
> Furthermore the it doesn't feel like loop either. In all three
> examples on this page I'd assume
> that the break would break
On 5-mei-2005, at 12:55, Nick Coghlan wrote:
> Alex Martelli wrote:
>
>> Looking for a file with a certain magicnumber in its 1st two
>> bytes...?
>>
>> for name in filenames:
>> opening(name) as f:
>> if f.read(2) == 0xFEB0: break
>>
>> This does seem to make real-life sense to m
Alex Martelli wrote:
> Looking for a file with a certain magicnumber in its 1st two bytes...?
>
> for name in filenames:
> opening(name) as f:
> if f.read(2) == 0xFEB0: break
>
> This does seem to make real-life sense to me...
Also consider the vast semantic differences between:
Steven Bethard wrote:
> Makes me wonder if we shouldn't just return to the __enter__() and
> __exit__() names of PEP 310[1] where for a generator __enter__() is
> just an alias for next(). We could even require Phillip J. Eby's
> "blockgenerator" decorator to rename next() to __enter__(), and add
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> On Wed, 4 May 2005, Shane Hathaway wrote:
> >
> > for name in filenames:
> > opening(name) as f:
> > if f.read(2) == 0xFEB0:
> > break for
>
> continue with 2
>
There is something aboutthat I just don't
On Thu, 5 May 2005, Delaney, Timothy C (Timothy) wrote:
> Aahz wrote:
> > My standard workaround is using exceptions, but I'm not sure how that
> > interacts with a block:
> >
> > try:
> > for name in filenames:
> > with opened(name) as f:
> > if f.read(2) ==
Aahz wrote:
> My standard workaround is using exceptions, but I'm not sure how that
> interacts with a block:
>
> try:
> for name in filenames:
> with opened(name) as f:
> if f.read(2) == 0xFEB0:
> raise Found
> except Found:
>
Aahz wrote:
> On Wed, May 04, 2005, Paul Moore wrote:
>>
>> Yes, that'd do. I can't say I think it would be common, but it's a
>> valid case. And the workaround is the usual messy flag variable:
>>
>> for name in filenames:
>> found = False
>> opening(name) as f:
>> if f.read(2) ==
On Wed, May 04, 2005, Paul Moore wrote:
>
> Yes, that'd do. I can't say I think it would be common, but it's a
> valid case. And the workaround is the usual messy flag variable:
>
> for name in filenames:
> found = False
> opening(name) as f:
> if f.read(2) == 0xFEB0: found = True
Ka-Ping Yee wrote:
> On Wed, 4 May 2005, Shane Hathaway wrote:
>>
>>for name in filenames:
>>opening(name) as f:
>>if f.read(2) == 0xFEB0:
>>break for
>
>
> This is very elegant.
Thanks.
> It works beautifully with "break", though at
> first that natural
[ Shane Hathaway ]:
> I'd like to suggest a small language enhancement that would fix this
> example. Allow the break and continue statements to use a keyword,
> either "for" or "while", to state that the code should break out of both
> the block statement and the innermost "for" or "while" statem
On Wed, 4 May 2005, Shane Hathaway wrote:
> I'd like to suggest a small language enhancement that would fix this
> example. Allow the break and continue statements to use a keyword,
> either "for" or "while", to state that the code should break out of both
> the block statement and the innermost "
Alex Martelli wrote:
> Looking for a file with a certain magicnumber in its 1st two bytes...?
>
> for name in filenames:
> opening(name) as f:
> if f.read(2) == 0xFEB0: break
>
> This does seem to make real-life sense to me...
I'd like to suggest a small language enhancement that w
Paul Moore wrote:
> On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>
>> On May 4, 2005, at 01:57, Paul Moore wrote:
>> >
>> > I can't think of a reasonable condition which wouldn't involve reading
>> > the file - which either involves an inner loop (and we already can't
>> > break out of two
On 5/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> With single-pass semantics, an iterator used in a block statement would have
> it's .next() method called exactly once, and it's __exit__ method called
> exactly
> once if the call to .next() does not raise StopIteration. And there's no need
>
On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On May 4, 2005, at 01:57, Paul Moore wrote:
> >
> > I can't think of a reasonable condition which wouldn't involve reading
> > the file - which either involves an inner loop (and we already can't
> > break out of two loops, so the third one i
On May 4, 2005, at 01:57, Paul Moore wrote:
> tried to construct a plausible example, I couldn't find a case which
> made real-life sense. For example, with Nicolas' original example:
>
> for name in filenames:
> opening(name) as f:
> if condition: break
>
> I can't think
Paul Moore wrote:
> Oh, and by the way - I prefer the keywordless form of the block
> statement (as used in my examples above). But it may exacerbate the
> issue with break unless we have a really strong name for these
> constructs
"may" exacerbate? Something of an understatement, unfortunately. '
On 5/3/05, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> We could avoid explaining to a newbie why the following code doesn't
> work if "opening" could be implemented in way that it works.
>
> for filename in filenames:
> block opening(filename) as file:
> if someReason: break
My initia
> FWIW, I expect most generators used in block-syntax to not be loops.
> What would imply to support these to pass "break" to parent loop at
> run-time?
I proposed this at some point during the discussion leading up to the
PEP and it was boohed away as too fragile (and I agree). You're just
going
Guido van Rossum wrote:
> [Skip Montanaro]
>>Guido> How many try/finally statements have you written inside a loop?
>>Guido> In my experience this is extrmely rare. I found no
>>Guido> occurrences in the standard library.
>
>>How'd we start talking about try/finally?
>
> Because i
Guido van Rossum wrote:
> [Skip Montanaro]
>> To the casual observer, this
>> looks like "break" should break out of the loop:
>>
>> while True:
>> block synchronized(v1):
>> ...
>> if v1.field:
>> break
>> time.sleep(1)
>
> Without 'block
[Skip Montanaro]
> >> Yeah, but "block synchronized(v1)" doesn't look like a loop. I think
> >> this might be a common stumbling block for people using this
> >> construct.
>
> Guido> How many try/finally statements have you written inside a loop?
> Guido> In my experience thi
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> [Skip Montanaro]
>> Yeah, but "block synchronized(v1)" doesn't look like a loop. I think
>> this might be a common stumbling block for people using this
>> construct.
Guido> How many try/finally statements h
[Skip Montanaro]
> Yeah, but "block synchronized(v1)" doesn't look like a loop. I think this
> might be a common stumbling block for people using this construct.
How many try/finally statements have you written inside a loop? In my
experience this is extrmely rare. I found no occurrences in t
Skip Montanaro a écrit :
> [...]
>
> Yeah, but "block synchronized(v1)" doesn't look like a loop. I think this
> might be a common stumbling block for people using this construct.
>
> Skip
>
Well, this can be a problem, because indeed the black-statement
introduce a new loop construct in Py
> "Pierre" == Pierre Barbier de Reuille <[EMAIL PROTECTED]> writes:
Pierre> Tom Rothamel a écrit :
>> I have a question/suggestion about PEP 340.
>>
>> As I read the PEP right now, the code:
>>
>> while True:
>> block synchronized(v1):
>> if v1.fie
Tom Rothamel a écrit :
> I have a question/suggestion about PEP 340.
>
> As I read the PEP right now, the code:
>
>
> while True:
>
> block synchronized(v1):
> if v1.field:
> break
>
> time.sleep(1)
>
>
> Will never break out of the enclosing while loop. This
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
break
time.sleep(1)
Will never break out of the enclosing while loop. This is because the
break breaks the while loop that the bl
46 matches
Mail list logo
