Phillip J. Eby wrote:
Specifically, I propose that PEP 340 *not* allow the use of normal
iterators. Instead, the __next__ and __exit__ methods would be an
unrelated protocol. This would eliminate the need for a 'next()' builtin,
and avoid any confusion between today's iterators and a
Guido van Rossum wrote:
1. I still can't decide on keyword vs. no keyword, but if we're going
to have a keyword, I haven't seen a better proposal than block. So
it's either block or nothing. I'll sleep on this. Feel free to start
an all-out flame war on this in c.l.py. ;-)
I quite like
Nick Coghlan a écrit :
3. I'm leaning against Phillip's proposal; IMO it adds more complexity
for very little benefit.
See my response to Phillip. I think there could be an advantage to it if it
means that for l in synchronized(lock) raises an immediate error instead of
silently doing
Greetings,
Currently Py_FatalError only dumps the error to stderr and calls abort().
When doing quirky things with the interpreter, it's so annoying that process
just terminates. Are there any reason why we still dont have a simple
callback to hook Py_FatalError.
PS. If the answer is because
Pierre Barbier de Reuille wrote:
Even if iterator-for-loops can be used within a block without damage,
the use of iterator-for-block in a loop can lead to completely
unpredictable result (and result really hard to find since they'll
possibly involve race conditions or dead locks).
I had a
Nick Coghlan [EMAIL PROTECTED] writes:
Paul Svensson wrote:
On Tue, 3 May 2005, Nick Coghlan wrote:
I'd also suggest that the blocktemplate decorator accept any iterator,
not just
generators.
So you want decorators on classes now ?
A decorator is just a function - it doesn't *need*
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
break
time.sleep(1)
Will never break out of the enclosing while loop. This is because the
break breaks the while loop that the
Tom Rothamel a écrit :
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
break
time.sleep(1)
Will never break out of the enclosing while loop. This is because the
Pierre == Pierre Barbier de Reuille [EMAIL PROTECTED] writes:
Pierre Tom Rothamel a écrit :
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
I just made a first reading of the PEP and want to clarify my
understanding of how it fits with existing concepts.
Is it correct to say that continue parallel's its current meaning and
returns control upwards (?outwards) to the block iterator that called
it?
Likewise, is it correct that yield is
Skip Montanaro a écrit :
[...]
Yeah, but block synchronized(v1) doesn't look like a loop. I think this
might be a common stumbling block for people using this construct.
Skip
Well, this can be a problem, because indeed the black-statement
introduce a new loop construct in Python.
Hi,
Sounds like a useful requirement to have for new features in 2.x,
IMO. that is... demonstrated need.
If the feature implies that the app needs to be designed from the
ground up to *really* take advantage of the feature, then, maybe
leave it for Guido's sabbatical (e.g. Python
Currently Py_FatalError only dumps the error to stderr and calls abort().
When doing quirky things with the interpreter, it's so annoying that process
just terminates. Are there any reason why we still dont have a simple
callback to hook Py_FatalError.
PS. If the answer is because no one
m.u.k [EMAIL PROTECTED] wrote:
Currently Py_FatalError only dumps the error to stderr and calls abort().
When doing quirky things with the interpreter, it's so annoying that process
just terminates. Are there any reason why we still dont have a simple
callback to hook Py_FatalError.
PS.
[Raymond Hettinger]
I just made a first reading of the PEP and want to clarify my
understanding of how it fits with existing concepts.
Thanks! Now is about the right time -- all the loose ends are being
solidified (in my mind any way).
Is it correct to say that continue parallel's its current
[Skip Montanaro]
Yeah, but block synchronized(v1) doesn't look like a loop. I think this
might be a common stumbling block for people using this construct.
How many try/finally statements have you written inside a loop? In my
experience this is extrmely rare. I found no occurrences in the
At 09:53 AM 5/3/05 -0700, Guido van Rossum wrote:
I just came across another use case that is fairly common in the
standard library: redirecting sys.stdout. This is just a beauty (in
fact I'll add it to the PEP):
def saving_stdout(f):
Very nice; may I suggest 'redirecting_stdout' as the name
On Tue, May 03, 2005, Phillip J. Eby wrote:
At 09:53 AM 5/3/05 -0700, Guido van Rossum wrote:
I just came across another use case that is fairly common in the
standard library: redirecting sys.stdout. This is just a beauty (in
fact I'll add it to the PEP):
def saving_stdout(f):
Very nice;
Hi,
Guido van Rossum [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Your efforts would be better directed towards fixing the causes of the
fatal errors.
I see no need to hook Py_FatalError, but since it's open source, you
are of course free to patch your own copy if your urge is truly
On Tue, May 03, 2005 at 09:15:42AM -0700, Guido van Rossum wrote:
But tell me, what do you want the process to do instead of
terminating? Py_FatalError is used in situations where raising an
exception is impossible or would do more harm than good.
In an application which embeds Python, I want
Hi,
Josiah Carlson [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
In looking at the use of Py_FatalError in the Python Sources (it's a 10
meg tarball that is well worth the download), it looks as though its use
shows a Fatal error (hence the name). Things like Inconsistant
interned
[Raymond]
Likewise, is it correct that yield is anti-parallel to the current
meaning? Inside a generator, it returns control upwards to the
caller.
But inside a block-iterator, it pushes control downwards (?inwards)
to
the block it controls.
[Guido van Rossum]
I have a hard time
[Skip Montanaro]
Yeah, but block synchronized(v1) doesn't look like a loop. I think
this might be a common stumbling block for people using this
construct.
Guido How many try/finally statements have you written inside a loop?
Guido In my experience this is
m.u.k [EMAIL PROTECTED] wrote:
Hi,
Guido van Rossum [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Your efforts would be better directed towards fixing the causes of the
fatal errors.
I see no need to hook Py_FatalError, but since it's open source, you
are of course free
[Raymond Hettinger]
Likewise, is it correct that yield is anti-parallel to the current
meaning? Inside a generator, it returns control upwards to the caller.
But inside a block-iterator, it pushes control downwards (?inwards) to
the block it controls.
Guido:
I have a hard time visualizing
[Raymond Hettinger]
Likewise, is it correct that yield is anti-parallel to the current
meaning? Inside a generator, it returns control upwards to the caller.
But inside a block-iterator, it pushes control downwards (?inwards) to
the block it controls.
[Guido]
I have a hard time
Hi Guido,
On Mon, May 02, 2005 at 17:55 -0700, Guido van Rossum wrote:
These are the loose ends on the PEP (apart from filling in some
missing sections):
1. Decide on a keyword to use, if any.
I just read the PEP340 basically the first time so bear with me.
First i note that introducing
[Holger]
1. Decide on a keyword to use, if any.
I just read the PEP340 basically the first time so bear with me.
Thanks for reviewing!
First i note that introducing a keyword 'block' would break
lots of programs, among it half of PyPy. Unlike many other
keywords 'block' is a pretty
[Tim]
Because Queue does use condvars now instead of plain locks, I wouldn't
approve of any gimmick purporting to hide the acquire/release's in
put() or get(): that those are visible is necessary to seeing that
the _condvar_ protocol is being followed (must acquire() before
wait(); must be
m.u.k [EMAIL PROTECTED] wrote:
Josiah Carlson [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Offering any hook for Py_FatalError may not even be enough, as some of
those errors are caused by insufficient memory. What if a hook were
available, but it couldn't be called because
In contrast, the new use of yield differs in that the suspended
frame
transfers control from the encloser to the enclosed.
Why does your notion of who encloses whom suddenly reverse when you go
from a for-loop to a block-statement? This all feels very strange to
me.
After another reading
Guido How many try/finally statements have you written inside a loop?
Guido In my experience this is extrmely rare. I found no
Guido occurrences in the standard library.
[Skip again]
How'd we start talking about try/finally?
Because it provides by far the dominant use
At 05:30 PM 5/3/05 -0400, Raymond Hettinger wrote:
By comparision, g.throw() or g.close() are trivially simple approaches
to generator/iterator finalization.
That reminds me of something; in PEP 333 I proposed use of a 'close()'
attribute in anticipation of PEP 325, so that web applications
Guido van Rossum wrote:
[Skip Montanaro]
Guido How many try/finally statements have you written inside a loop?
Guido In my experience this is extrmely rare. I found no
Guido occurrences in the standard library.
How'd we start talking about try/finally?
Because it provides by
[Phillip]
That reminds me of something; in PEP 333 I proposed use of a 'close()'
attribute in anticipation of PEP 325, so that web applications implemented
as generators could take advantage of resource cleanup. Is there any
chance that as part of PEP 340, 'close()' could translate to the
I think that documentation is wrong; AFAIK Py_UNICODE has always been
allowed to be either 16 or 32 bits, and the source code goes through
great lengths to make sure that you get a link error if you try to
combine extensions built with different assumptions about its size.
On 5/3/05, Nicholas
Summary:
Resource Managers are a good idea.
First Class Suites may be a good idea.
Block Iterators try to split the difference. They're not as powerful
as First Class Suites, and not as straightforward as Resource
Managers. This particular middle ground didn't work out so well.
On 5/3/05,
Sorry Jim, but I just don't think you I were intended to be on the
same language design committee. Nothing you say seems to be making any
sense to me these days. Maybe someone else can channel you
effectively, but I'm not going to try to do a line-by-line response to
your email quoted below.
On
At 03:33 PM 5/3/05 -0700, Guido van Rossum wrote:
[Phillip]
That reminds me of something; in PEP 333 I proposed use of a 'close()'
attribute in anticipation of PEP 325, so that web applications implemented
as generators could take advantage of resource cleanup. Is there any
chance that as
At 07:27 PM 5/3/05 -0400, Phillip J. Eby wrote:
Modifying the spec is potentially more controversial, however; it'll have
to go past the Web-SIG, and I assume the first thing that'll be asked is,
Why aren't generators getting a close() method then?, so I figured I
should ask that question first.
Maybe if you drop support for the separate protocol alternative... :-)
I don't understand you. Are you suggesting a horse trade, or...?
Only tongue-in-cheek. :-)
I had never heard of that PEP. How much code is there in the field?
Maybe a dozen or so web applications and frameworks
On Tue, 2005-05-03 at 12:54 -0500, Jeff Epler wrote:
On Tue, May 03, 2005 at 09:15:42AM -0700, Guido van Rossum wrote:
But tell me, what do you want the process to do instead of
terminating? Py_FatalError is used in situations where raising an
exception is impossible or would do more harm
it's not infeasible to add a close() method to
generators as a shortcut for this:
def close(self):
try:
self.__exit__(StopIteration)
except StopIteration:
break
else:
# __exit__() didn't
raise RuntimeError(or
At 04:41 PM 5/3/05 -0700, Guido van Rossum wrote:
Given all that, it's not infeasible to add a close() method to
generators as a shortcut for this:
def close(self):
try:
self.__exit__(StopIteration)
except StopIteration:
break
else:
On 5/3/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:41 PM 5/3/05 -0700, Guido van Rossum wrote:
Given all that, it's not infeasible to add a close() method to
generators as a shortcut for this:
def close(self):
try:
self.__exit__(StopIteration)
Guido van Rossum wrote:
I'd like the block statement to be defined exclusively in terms of
__exit__() though.
This does actually suggest something to me (note - just a thought - no
real idea if it's got any merit).
Are there any use cases proposed for the block-statement (excluding the
I think that realization is important. It would be great to have a
section of the PEP that focuses on separability and matching
features to
benefits. Start with above observation that the proposed examples
can
be achieved with generators driving the block statement.
Good idea. I'm
At 05:17 PM 5/3/05 -0700, Guido van Rossum wrote:
(So do you want this feature now or not? Earlier you said it was no big deal.)
It *isn't* a big deal; but it'd still be nice, and I'd happily volunteer to
do the actual implementation of the 'close()' method myself, because it's
about the same
At 08:47 PM 5/3/05 -0400, Phillip J. Eby wrote:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/141934
Oops; that one's not really a valid example; the except StopIteration just
has a harmless pass, and it's not in a loop.
___
Python-Dev
Delaney, Timothy C (Timothy) wrote:
Guido van Rossum wrote:
I'd like the block statement to be defined exclusively in terms of
__exit__() though.
1. If an iterator declares __exit__, it cannot be used in a for-loop.
For-loops do not guarantee resource cleanup.
2. If an iterator
On May 3, 2005, at 6:44 PM, Guido van Rossum wrote:
I think that documentation is wrong; AFAIK Py_UNICODE has always been
allowed to be either 16 or 32 bits, and the source code goes through
great lengths to make sure that you get a link error if you try to
combine extensions built with
Gheorghe Milas wrote:
in template thread_safe(lock):
in template redirected_stdout(stream):
in template use_and_close_file(path) as file:
in template as_transaction():
in template auto_retry(times=3, failas=IOError):
-1. This is unpythonically verbose.
If I wanted to get lots of finger
52 matches
Mail list logo
