I can't make time for this right now, but the more I think about it,
the more I believe the worry about asynchronous exceptions is mostly
irrational. Despite your "proof" that it *can* be implemented I really
don't want to see anything like that implemented -- I doubt that
you've covered all the ca
Hi
If you are a parent, an educator or a programmer having kids this is
for you! After 4 years of work, my new book "Squeak: Learn
programming with Robots" will be out soon.
http://smallwiki.unibe.ch/botsinc/
http://www.amazon.com/exec/obidos/tg/detail/-/1590594916/
qid=1117218524/sr=1-1/ref=sr_
Nick Coghlan <[EMAIL PROTECTED]> writes:
> It also considers the possibility of using with statements in an RAII
> style by acquiring the resource in __init__ or __new__ rather than
> __enter__.
While you can probably do this (after all, most of the time
__new__/__init__ and __enter__ will be ca
Dear Mr. Ducasse,
The PyDev mailing list, bidirectionally gatewayed to
gmane.comp.python.devel, which you apparently used as the insertion point,
is a specialized list for discussion and development of the next Python
version and occasionally beyond. Even most posts to comp.lang.python (==
gm
Post-EuroPython 2005 PyPy Sprint 1st - 7th July 2005
==
The next PyPy sprint is scheduled right after EuroPython 2005
in Gothenborg, Sweden. Its main focus is translation to
lower level backends but there are also other possible topics.
We'll
I'm horsing around with recognizing switch-like if statements like:
if x == 1:
print 1
elif x == 2:
print 2
else:
print "unknown"
in the compiler and generating O(1) code. "x" can be any expression, but
must be precisely the same in each elif clause, the comp
Guido van Rossum wrote:
> So (a) would have my preference.
Mine, too.
> the PEP would have to be amended to state that
> VAR must be a single variable or a list of variables IN PARENTHESES.
+1
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbu
Guido van Rossum wrote:
> I can't make time for this right now, but the more I think about it,
> the more I believe the worry about asynchronous exceptions is mostly
> irrational. Despite your "proof" that it *can* be implemented I really
> don't want to see anything like that implemented -- I doub
More than case-statement semantics or PEP343, I wish for a dowhile
statement.
The most straight-forward way is to put the conditional expression at
the beginning of the block with the understanding that a dowhile keyword
will evaluate the condition only after the block runs:
dowhile :
Michael Hudson wrote:
> While you can probably do this (after all, most of the time
> __new__/__init__ and __enter__ will be called in rapid succession) I
> really think the RAII meme doesn't apply to Python; you generally want
> a resource to be acquired for a period of definite extent, and object
> I'm horsing around with recognizing switch-like if statements like:
>
> if x == 1:
> print 1
> elif x == 2:
> print 2
> else:
> print "unknown"
>
> in the compiler and generating O(1) code. "x" can be any expression,
but
> must be precisely the same in each
Raymond Hettinger wrote:
> More than case-statement semantics or PEP343, I wish for a dowhile
> statement.
>
> The most straight-forward way is to put the conditional expression at
> the beginning of the block with the understanding that a dowhile keyword
> will evaluate the condition only after t
[Nick]
> As I just added to the Wiki, dropping the issue completely works for
> me. I'm also far from convinced I'd covered all the corner cases
> (besides, blocking KeyboardInterrupt for an arbitrary amount of time
> made me uncomfortable).
OK.
> You'd mostly convinced me that RAII was rare in P
On 6/12/05, Skip Montanaro <[EMAIL PROTECTED]> wrote:
>
> I'm horsing around with recognizing switch-like if statements like:
>
> if x == 1:
> print 1
> elif x == 2:
> print 2
> else:
> print "unknown"
>
> in the compiler and generating O(1) code. "x" can be
On Jun 12, 2005, at 10:20 PM, Raymond Hettinger wrote:
> I think it unwise to allow x to be any expression. Besides altering
> existing semantics, it leads to code redundancy and to a fragile
> construct (where the slightest alteration of any of the expressions
> triggers a silent reversion to O(n
On 6/12/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
> > More than case-statement semantics or PEP343, I wish for a dowhile
> > statement.
> >
> > The most straight-forward way is to put the conditional expression at
> > the beginning of the block with the understanding th
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Raymond Hettinger wrote:
> > More than case-statement semantics or PEP343, I wish for a dowhile
> > statement.
> >
> > The most straight-forward way is to put the conditional expression at
> > the beginning of the block with the understanding that a do
At 09:01 PM 6/12/2005 -0700, Guido van Rossum wrote:
>If we have to do this, PEP 315 has my +0.
>
>It is Pythonically minimal and the motivation rings true: I've often
>written code like this in the past:
>
> line = f.readline()
> while line:
>
> line = f.readline()
>
>But
> By the way, whatever happened to "and while"?
That is making something hard and weird out of something simple.
There were no shortage of odd suggestions to force the condition line
to appear lower in the block than the starting line. All of them
smelled of rotten eggs -- they just don't fit th
19 matches
Mail list logo
