Reinhold Birkenfeld wrote:
Shane Hathaway wrote:
PEP 340 seems to punish people for avoiding the parentheses:
transaction = begin_transaction()
transaction:
db.execute('insert 3 into mytable')
transaction:
db.execute('insert 4 into mytable')
I expect that only '3' would be inserted in mytable.
Shane Holloway (IEEE) wrote:
> It might actually be workable in the transaction scenario, as well as
> others. I'm not sure if I love or hate the idea though.
Given that this is officially a violation of the iterator protocol. . . (check
the docs for well-behaved iterators)
> Another thing. I
Greg Ewing wrote:
> Shane Hathaway wrote:
>
>>For each block statement, it is necessary to create a *new* iterator,
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statements will need to call something, and thus
>>will have parentheses.
>
>
> N
Shane Holloway (IEEE) wrote:
> Another thing. In the specification of the Anonymous Block function, is
> there a reason that "itr = EXPR1" instead of "itr = iter(EXPR1)"? It
> seems to be a dis-symmetry with the 'for' loop specification.
Hmm... yeah. That's strange. In fact, if it gets chang
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses.
Not necessarily!
class Frob
I'm forced by my day job to temporarily withdraw from the discussion
about PEP 340 (I've used up my Python quota for the next several
weeks).
If agreement is reached in python-dev to suggest specific changes to
the PEP, please let me know via mail sent directly to me and not cc'ed
to python-dev. B
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might be enough
[ Reinhold Birkenfeld ]:
> Well, with it you could create suites with _any_ introducing
> identifier. Consider:
>
> with:
> (...)
>
> synchronized:
> (...)
>
> try:
> (...)
>
> transaction:
> (...)
>
>
> Do you understand my concern?
I definetely see your point. However,...
Reinhold Birkenfeld wrote:
> Shane Hathaway wrote:
>
>
>>For each block statement, it is necessary to create a *new* iterator,
>
>
> Right.
>
>
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statements will need to call something, and thus
>
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
Right.
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might
Reinhold Birkenfeld wrote:
> Noam Raphael wrote:
>
>>On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>>resource = opening("file.txt")
>>>resource:
>>>(...)
>>>
>>>The latter would have to be forbidden.
>>
>>Can you explain why it would have to be forbidden please?
>
>
> Well, with
Ka-Ping Yee wrote:
> Reinhold Birkenfeld wrote:
>> Well, with it you could create suites with _any_ introducing
>> identifier. Consider:
>>
>> with:
>> (...)
>>
>> synchronized:
>> (...)
>>
>> try:
>> (...)
>>
>> transaction:
>> (...)
>>
>> Do you understand my concern? It would be
Reinhold Birkenfeld wrote:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions in the new statement.
[...]
> resource = opening("file.txt")
> resource:
> (...)
>
> The latter would have to be forbidden.
Noam Raphael wrote:
> Can you explain why it would have to
Noam Raphael wrote:
> On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>
>> There is one problem with using no keyword: You cannot use arbitrary
>> expressions
>> in the new statement. Consider:
>>
>> resource = opening("file.txt")
>> block resource:
>> (...)
>>
>> resource = open
[ Senra ]:
> > [ Guido ]:
> > > 1. Decide on a keyword to use, if any.
> >
> > Shouldn't be the other way around ?
> > Decide to use *no* keyword, if that could be avoided.
[ Reinhold ]:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statem
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statement. Consider:
>
> resource = opening("file.txt")
> block resource:
> (...)
>
> resource = opening("file.txt")
> resource:
>
Rodrigo Dias Arruda Senra wrote:
> [ Guido ]:
> > 1. Decide on a keyword to use, if any.
>
> Shouldn't be the other way around ?
> Decide to use *no* keyword, if that could be avoided.
[...]
> Following the PEP and this thread, it seems to me that __no keyword__
> is less preferable than _
[ Guido ]:
> 1. Decide on a keyword to use, if any.
Shouldn't be the other way around ?
Decide to use *no* keyword, if that could be avoided.
In my large inexperience *no keyword* is much better (if feasible):
1) No name conflicts with previous code: block, blocktemplate, whatever
2)
Another loose end (which can partially explain why I still thought
__next__ took an exception ;)
In "Specification: Generator Exit Handling"::
"When __next__() is called with an argument that is not None, the
yield-expression that it resumes will return the value attribute
of the argu
[Guido]
> [Holger]
> > However, i would find it much clearer if *defining* blocktemplates
> > used a new keyword, like:
> >
> > blocktemplate opening(filename, mode="r"):
> > ...
> >
> > because this immediately tells me what the purpose and semantics
> > of the folowing definition is
[Holger]
> > 1. Decide on a keyword to use, if any.
>
> I just read the PEP340 basically the first time so bear with me.
Thanks for reviewing!
> First i note that introducing a keyword 'block' would break
> lots of programs, among it half of PyPy. Unlike many other
> keywords 'block' is a prett
Hi Guido,
On Mon, May 02, 2005 at 17:55 -0700, Guido van Rossum wrote:
> These are the loose ends on the PEP (apart from filling in some
> missing sections):
>
> 1. Decide on a keyword to use, if any.
I just read the PEP340 basically the first time so bear with me.
First i note that introduci
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Paul Svensson wrote:
>> On Tue, 3 May 2005, Nick Coghlan wrote:
>>
>>> I'd also suggest that the blocktemplate decorator accept any iterator,
>>> not just
>>> generators.
>>
>>
>> So you want decorators on classes now ?
>
> A decorator is just a funct
I've been away for a while and just read through the PEP 340 discussion
with growing amazement.
Pierre Barbier de Reuille wrote:
> As far as I understand it,
> iterator-for-blocks and iterator-for-loops are two different beasts.
Right!
> To try being as clear as possible, I would say the iterato
Pierre Barbier de Reuille wrote:
> Even if iterator-for-loops can be used within a block without damage,
> the use of iterator-for-block in a loop can lead to completely
> unpredictable result (and result really hard to find since they'll
> possibly involve race conditions or dead locks).
I had
Paul Svensson wrote:
> On Tue, 3 May 2005, Nick Coghlan wrote:
>
>> I'd also suggest that the blocktemplate decorator accept any iterator,
>> not just
>> generators.
>
>
> So you want decorators on classes now ?
A decorator is just a function - it doesn't *need* to be used with decorator
synt
Nick Coghlan a écrit :
>>3. I'm leaning against Phillip's proposal; IMO it adds more complexity
>>for very little benefit.
>
>
> See my response to Phillip. I think there could be an advantage to it if it
> means that "for l in synchronized(lock)" raises an immediate error instead of
> silentl
Guido van Rossum wrote:
> 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. ;-)
I quite like 'bl
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 a
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
[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
36 matches
Mail list logo
