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) ==
"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
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
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
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
___
"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
"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
>
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
> > 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
>
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
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:
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
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
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
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:
>>
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
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("
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.
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
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
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
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
>
>
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
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.
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
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
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
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
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
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
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
>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.
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
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():
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
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
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 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
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: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, 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
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
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
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 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
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
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
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, +---
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
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
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
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
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
53 matches
Mail list logo
