Greg Ewing wrote:
> I'm still bothered by the idea of for-loops not participating
> in the new generator finalization protocol.
I agree - that's always been nagging at me too.
The problem with it is that then you either:
1. Have a guarantee that an iterator will be exhausted when the for loop
e
I'm still bothered by the idea of for-loops not participating
in the new generator finalization protocol.
It's all very well to say that iterators designed for block
statements shouldn't be used in for-loops, but there may
be more subtle cases to consider, such as
def file_frobulations(filenam
Nick Coghlan wrote:
> What does a try statement with neither an except clause nor a finally clause
> mean?
I guess it would mean the same as
if 1:
...
Not particularly useful, but maybe it's not worth complexifying
the grammar just for the sake of disallowing it.
Also, some people mig
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
Nick Coghlan wrote:
> Something relatively nonsensical, but usefully mnemonic
> (like 'stmt') may be a good way to go.
How about 'do'?
do opening(filename) as f:
...
do locking(obj):
...
do carefully(): # :-)
...
--
Greg Ewing, Computer Science Dept, +---
Fredrik Lundh wrote:
> the current
> proposal stems from the observation that "for-loop plus generators" in
> today's Python does in fact provide a block implementation that solves
> many use cases in an elegant way.
>
> PEP 340 builds on this, sorts out a couple of weak points in the current
> d
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
Eric Nieuwland wrote:
> Ron Adam wrote:
>
>> 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 paramete
Nicholas Bastin wrote:
>
> On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
>> On a related note, it would be help if the documentation provided a
>> little more background on unicode encoding. Specifically, that UCS-2 is
>> not the same as UTF-16, even though they're both two bytes wide and mos
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 May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
> Martin v. Löwis wrote:
>> Nicholas Bastin wrote:
>>
>>> "This type represents the storage type which is used by Python
>>> internally as the basis for holding Unicode ordinals. Extension
>>> module
>>> developers should make no assumptions abo
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 May 4, 2005, at 6:03 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> "This type represents the storage type which is used by Python
>> internally as the basis for holding Unicode ordinals. Extension
>> module
>> developers should make no assumptions about the size of this type on
>> a
Gustavo Niemeyer wrote:
> Greetings,
>
>
>>Reasoning: The block statement resembles a "while" block in some ways in
>>that it is a conditional block that may be executed only once, or
>>possibly not at all (or many times). And the word "while" is also
>>descriptive of how a block is used.
>>
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
Greetings,
> Reasoning: The block statement resembles a "while" block in some ways in
> that it is a conditional block that may be executed only once, or
> possibly not at all (or many times). And the word "while" is also
> descriptive of how a block is used.
>
> while VAR1 from EXPR1():
On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The discussion on the meaning of break when nesting a PEP 340 block statement
> inside a for loop has given me some real reasons to prefer PEP 310's single
> pass
> semantics for user defined statements (more on that at the end). The
> suggesti
>I do hava a problem with python and it is that it raise an outofmemory
> >(i comment lines in Py.java to avoid system.exit, to debug),
Questions about using current Python belong on the Python list or
comp.lang.python. Python-dev is for discussions about developing future
versions.
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
Paul Moore wrote:
> 1. Choice (or not) of a keyword. I honestly believe that there will
> never be a consensus on this, and we'd be better deferring the
> decision to Guido's judgement.
The keyword-less approach is less confusing when the block statement is not a
loop, as that eliminates the supr
I expect there's an obvious reason why this hasn't been suggested
already that I'm not currently thinking of, but here it is anyway. :-)
How about an *extended while* syntax as a block keyword alternative?
Reasoning: The block statement resembles a "while" block in some ways in
that it is a
Hi All,
I do hava a problem with python
and it is that it raise an outofmemory (i comment lines in Py.java to avoid
system.exit, to debug),
i try to debug this issue with jprobe and realize
that i get the exception even although the java heap is not in the limit, i
book
64- 256M and
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, Steven Bethard <[EMAIL PROTECTED]> 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 lo
Chris Ryland <[EMAIL PROTECTED]> writes:
> In this case, "while" is the better time-related prefix, whether
Indeed.
while_execution_is_lexically_in_the_next_block lock(theLock):
...
Anyone? .
Cheers,
mwh
--
Every day I send overnight packages filled with rabid weasels to
people who u
Eric Nieuwland wrote:
> Wouldn't it be easier to change it to:
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)*
> ['else' ':' suite] ['finally' ':' suite] )
> ?
What does a try statement with neither an except clause nor a finally clause
mean?
Cheers,
Nick.
Rodrigo Dias Arruda Senra gpr.com.br> writes:
> The code pattern that will 'wrap' the block might
> not always make sense with the chosen keyword, if
> that keyword is not semantically neutral.
> (not time-related, not function-related, etc).
>
> Notice that is _no keyword_ is chosen, nothi
Reinhold Birkenfeld wrote:
> Changes to the grammar
>
> The grammar for the try statement, which is currently
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] | 'try' ':' suite 'finally' ':'
> suite)
>
> would have to become
>
>
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
The discussion on the meaning of break when nesting a PEP 340 block statement
inside a for loop has given me some real reasons to prefer PEP 310's single
pass
semantics for user defined statements (more on that at the end). The suggestion
below is my latest attempt at combining the ideas of the
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
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.
On Thu, 05 May 2005 14:58:02 +0200
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I haven't followed the PEP 340 discussion in detail,
> but as the PEP doesn't list keywords that have been
> considered and rejected, I'd like to propose my own:
> use "after" instead of "block":
>
> after opening("
I haven't followed the PEP 340 discussion in detail,
but as the PEP doesn't list keywords that have been
considered and rejected, I'd like to propose my own:
use "after" instead of "block":
after opening("/etc/passwd") as f:
for line in f:
print line.rstrip()
after locking(myLock):
# cod
Michael Hudson wrote:
> "Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:
>
>
>>And per the PEP, I think the explaining that::
>>
>> try:
>> A
>> except:
>> B
>> else:
>> C
>> finally:
>> D
>>
>>is *exactly* equivalent to::
>>
>> try:
>>
Delaney, Timothy C (Timothy) wrote:
> Nick Coghlan wrote:
> I think if we are going to emphasise the difference, a decorator does
> not go far enough. To use a decorator, this *must* be valid syntax::
>
> def gen():
> try:
> yield
> finally:
> print 'Don
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
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
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
> > Ultimately, some of these will likely end-up in the library. For
the
> > time being, I think it best that these get posted and evolve either
as
> > Wiki entries or as ASPN entries. The best practices and proven
winners
> > have yet to emerge. Solidifying first attempts is likely not a good
>
Gustavo J. A. M. Carneiro wrote:
> In that case,
>
> block VAR1 in EXPR1:
> BLOCK1
>
> And now I see how using 'for' statements (perhaps slightly changed)
> turned up in the discussion.
you're moving through this discussion exactly backwards; the current
proposal stems from the
"Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:
> And per the PEP, I think the explaining that::
>
> try:
> A
> except:
> B
> else:
> C
> finally:
> D
>
> is *exactly* equivalent to::
>
> try:
> try:
> A
>
"Edward C. Jones" <[EMAIL PROTECTED]> writes:
> Recently I needed some information about the floating point numbers on
> my machine. So I wrote a tiny C99 program with the line
>
> printf("%a\n", DBL_EPSILON);
>
> The answer was "0x1p-52".
>
> A search of comp.lang.python shows that I was not alo
Josiah Carlson <[EMAIL PROTECTED]> wrote:
unsigned
vv
> For 64 bit signed integers:
> struct.pack("Q",...)
> struct.unpack("Q",...)
My fingers were typing too fast (I do much work with unsigned 64 bit
integers, but not much with unsigned ones).
- Josiah
___
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
Here's April Part Two. If anyone can take their eyes of the anonymous block
threads for a moment and give this a once-over, that would be great! Please
send any corrections or suggestions to Tim (tlesher at gmail.com), Steve
(steven.bethard at gmail.com) and/or me, rather than cluttering the list
"Edward C. Jones" <[EMAIL PROTECTED]> wrote:
> 3. Add full "tostring" and "fromstring" capabilities for Python numeric
> types. "tostring(x)" would return a string containing the binary
> representation of x. For example, if x is a Python float, "tostring(x)"
> would have eight characters. "fr
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) ==
53 matches
Mail list logo
