Just a little offtopic note to Jeff Bone: Jeff, every time I send a
message to Python-Dev, your Mail.app 2.0 sends me a nasty auto-reply
that I can't quote in public. Please stop. Since I can't seem to reach
you by email, I'm trying to reach you through this mailing list. The
note refers to
Edward C. Jones wrote:
The documentation should discuss portability.
This is the critical issue here. Discussing portability is not
enough; these features really ought to be either available on
a majority of the installations, or not available at all.
In particular, they would need to be
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) == 0xFEB0:
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. fromstring(s,
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
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 alone. Here are
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
except:
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
the
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. In
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:
try:
A
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):
# code
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 out
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
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
blockgenerator
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.
--
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 the
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
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 about action which level that I just don't like.
Just to clarify: if by level you mean nesting level, did it appear
that the 2
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.
while VAR1
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
any given
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
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
discussion
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 most
of
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 parameters
def
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
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
design,
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
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
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
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
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
34 matches
Mail list logo
