On Thu, 28 Apr 2005, Greg Ewing wrote:
> If such an explanation can't be found, I strongly suspect
> that this doesn't correspond to a cohesive enough concept
> to be made into a built-in language feature. If you can't
> give a short, understandable explanation of it, then it's
> probably a bad ide
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> You mean like this?
if x > 0:
...normal case...
elif y > 0:
abnormal case...
else:
...edge case...
The salient example! If it's no accident that those conditions are
mutually exclusi
Greg Ewing wrote:
Guido van Rossum wrote:
And surely you exaggerate. How about this then:
The with-statement is similar to the for-loop. Until you've
learned about the differences in detail, the only time you should
write a with-statement is when the documentation for the function
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
I'd like to reconsider a thunk implementation. It
would be a lot s
Guido van Rossum wrote:
PEP 310 forms the basis for a block construct that I _do_ like. The question
then becomes whether or not generators can be used to write useful PEP 310 style
block managers (I think they can, in a style very similar to that of the looping
block construct from PEP 340).
I've
On 4/28/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> however, the iterable object is notified whenever a 'continue',
> 'break', or 'return' statement is executed inside the block-statement.
This should read:
however, the iterable object is notified whenever a 'continue',
'break' or 'return' st
> Exaggeration in defense of elegance is no vice.
Maybe not, but it still sounds like BS to me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
Greg Ewing wrote:
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
I'd like to reconsider a thunk implementation. I
On 4/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > And surely you exaggerate. How about this then:
> >
> > The with-statement is similar to the for-loop. Until you've
> > learned about the differences in detail, the only time you should
> > write a with-st
I have been having a few more discussions around about this, and I'm starting
to think that this is a bug.
My take is that, when I call Py_Finalize, the python thread should be shut down
gracefully, closing the file and everything.
Maybe I'm missing a call to something (?PyEval_FinalizeThreads
Brett C. wrote:
Guido van Rossum wrote:
Yet another alternative would be for the default behaviour to be to raise
Exceptions, and continue with anything else, and have the third argument be
"raise_exc=True" and set it to False to pass an exception in without raising it.
You've lost me there. If yo
On 4/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Neil Schemenauer wrote:
>
> > The translation of a block-statement could become:
> >
> > itr = EXPR1
> > arg = None
> > while True:
> > try:
> > VAR1 = next(itr, arg)
> > except Stop
On 4/28/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> Guido> You mean like this?
>
> if x > 0:
> ...normal case...
> elif y > 0:
> abnormal case...
> else:
> ...edge case...
>
> T
Hello,
I know this is a n00b question, so I apologize ahead of time.
I've been taking a look at they python interpreter, trying to
understand how it works on the compiled byte-codes. Looking
through the sources of the 2.4.1 stable version, it looks like
Python/ceval.c is the module that does the
Based on Guido's opinion that caller and callee should both be
marked, I have used keywords 'include' and 'chunk'. I therefore
call them "Chunks" and "Includers".
Examples are based on
(1) The common case of a simple resource manager. e.g.
http://mail.python.org/pipermail/python-dev/2005-April
Brett C. wrote:
I'm surprisingly close to agreeing with you, actually. I've worked out
that it isn't the looping that I object to, it's the inability to get
out of the loop without exhausting the entire iterator.
'break' isn't' enough for you as laid out by the proposal? The raising of
StopIterat
Greg Ewing <[EMAIL PROTECTED]> writes:
> Are there any objective reasons to prefer a generator
> implementation over a thunk implementation?
I, too, would like to see an answer to this question.
I'd like to see an answer in the PEP, too.
Cheers,
mwh
--
All obscurity will buy you is time eno
[Greg Ewing]
> Elegant as the idea behind PEP 340 is, I can't shake
> the feeling that it's an abuse of generators. It seems
> to go to a lot of trouble and complication so you
> can write a generator and pretend it's a function
> taking a block argument.
Maybe. You're not the first one saying thi
[Greg Ewing]
> I think perhaps I'm not expressing myself very well.
> What I'm after is a high-level explanation that actually
> tells people something useful, and *doesn't* cop out by
> just saying "you're not experienced enough to understand
> this yet".
>
> If such an explanation can't be found
How about, instead of trying to emphasize how different a
block-statement is from a for-loop, we emphasize their similarity?
A regular old loop over a sequence or iterable is written as:
for VAR in EXPR:
BLOCK
A variation on this with somewhat different semantics swaps the keywords:
On Thu, Apr 28, 2005 at 05:47:18PM -0400, Jing Su wrote:
> Is there work to change python into a direct-threaded or even JIT'ed
> interpreter?
People have experimented with making the ceval loop use direct
threading. If I recall correctly, the resulting speedup was not
significant. I suspect th
On Thu, Apr 28, 2005 at 03:55:03PM -0700, Guido van Rossum wrote:
> A variation on this with somewhat different semantics swaps the keywords:
>
> in EXPR for VAR:
> BLOCK
Looks weird to my eyes.
On a related note, I was thinking about the extra cleanup 'block'
provides. If the 'file
Guido van Rossum wrote:
A variation on this with somewhat different semantics swaps the keywords:
in EXPR for VAR:
BLOCK
If you don't need the variable, you can leave the "for VAR" part out:
in EXPR:
BLOCK
Too cute? :-)
I don't think it reads well. I would prefer something
> However, it looks like a switched interpreter. I just
> find this surprising because python seems to run pretty fast, and a switched
> interpreter is usually painfully slow.
This just proves how worthless a generalization that is.
--
--Guido van Rossum (home page: http://www.python.org/~guido
Guido van Rossum wrote:
> I don't know. What exactly is the audience supposed to be of this
> high-level statement? It would be pretty darn impossible to explain
> even the for-statement to people who are new to programming, let alone
> generators. And yet explaining the block-statement *must* invo
Guido van Rossum wrote:
The main advantage of thunks that I can see is that you can save the
thunk for later, like a callback for a button widget (the thunk then
becomes a closure).
Or pass it on to another function. This is something we
haven't considered -- what if one resource-acquision-
generat
Nick Coghlan wrote:
With an appropriate utility block manager
I've just thought of another potential name for them:
Block Utilization and Management Function (BUMF) :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of N
Guido van Rossum wrote:
Even without a block-statement, these two changes make yield look a
lot like invoking a thunk -- but it's more efficient, since calling
yield doesn't create a frame.
I like PEP 340 a lot, probably as much or more than any thunk ideas I've
seen. But I want to defend thunks
Neil Schemenauer wrote:
A variation on this with somewhat different semantics swaps the keywords:
in EXPR for VAR:
BLOCK
Looks weird to my eyes.
Probably makes perfect sense if you're Dutch, though. :-)
--
Greg Ewing, Computer Science Dept, +--+
Univers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
| How about, instead of trying to emphasize how different a
| block-statement is from a for-loop, we emphasize their similarity?
|
| A regular old loop over a sequence or iterable is written as:
|
| for VAR in EXPR:
|
Guido van Rossum wrote:
I don't know. What exactly is the audience supposed to be of this
high-level statement? It would be pretty darn impossible to explain
even the for-statement to people who are new to programming, let alone
generators.
If the use of block-statements becomes common for certain
Steven Bethard wrote:
"""
A block-statement is much like a for-loop, and is also used to iterate
over the elements of an iterable object.
No, no, no. Similarity to a for-loop is the *last* thing
we want to emphasise, because the intended use is very
different from the intended use of a for-loop. Th
(BTW, I'm trying to update the PEP with a discussion of thunks.)
[Guido]
> > The main advantage of thunks that I can see is that you can save the
> > thunk for later, like a callback for a button widget (the thunk then
> > becomes a closure).
[Greg]
> Or pass it on to another function. This is so
Shane Hathaway wrote:
"Block statements provide a mechanism for encapsulating patterns of
structure. Code inside the block statement runs under the control of an
object called a block iterator. Simple block iterators execute code
before and after the code inside the block statement. Block iterat
> If the use of block-statements becomes common for certain
> tasks such as opening files, it seems to me that people are
> going to encounter their use around about the same time
> they encounter for-statements. We need *something* to
> tell these people to enable them to understand the code
> the
> Far too close to the "for" loop, IMHO. I read that, I'd have to remind
> myself every time, "now, which one is it that can receive values passed
> back in: for ... in, or in ... for?"
Whoa! Read the PEP closely. Passing a value back to the iterator
(using "continue EXPR") is supported both in th
[Nicolas Fleury]
> I would prefer something that would be
> understandable for a newbie's eyes, even if it fits more with common
> usage than with the real semantics behind it. For example a Boost-like
> keyword like:
>
> scoped EXPR as VAR:
> BLOCK
Definitely not. In too many languages, a
37 matches
Mail list logo
