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 'bl
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
> silentl
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 n
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* to be used with decorator
synt
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
I've been away for a while and just read through the PEP 340 discussion
with growing amazement.
Pierre Barbier de Reuille wrote:
> As far as I understand it,
> iterator-for-blocks and iterator-for-loops are two different beasts.
Right!
> To try being as clear as possible, I would say the iterato
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 funct
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 bl
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
> "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.fie
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"
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 Py
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 300
> 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
"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.
[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 cur
[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 t
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):
>
>
On May 3, 2005, at 12:53 PM, Guido van Rossum wrote:
> def saving_stdout(f):
> save_stdout = sys.stdout
> try:
> sys.stdout = f
> yield
> finally:
> sys.stdout = save_stdout
I hope you aren't going to be using that in any threaded program.
That's one really nic
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
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 wan
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
> intern
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> [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 h
[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 ti
[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 thi
"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
>
> [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]
> >
Hi,
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 there wasn't enough memory?
>
>
[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 vis
[Raymond]
It would be great if we could point to some code in the standard library
or in a major Python application that would be better (cleaner, faster,
or clearer) if re-written using blocks and block-iterators
[Guido]
>>> look more closely at Queue, and you'll find that the two
> [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
[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
...
[Jim Jewett]
>> qsize, empty, and full could be done with a lockself decorator.
>> Effectively, they *are* lockself decorators for the _xxx functions
>> that subclasses are told to override.
[Guido]
> Actually you're pointing out a bug in the Queue module: these *should*
> be using a try/fin
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 introduci
I'm not really in position to speak but since I only saw people trying to
come up with a keyword only using one word and without much success I would
venture to suggest the possibility of making a keyword out of two words.
Would there be a huge problem to use 2 words to make up a keyword?
like f
[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 prett
[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();
"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 calle
[Guido]
> [Holger]
> > However, i would find it much clearer if *defining* blocktemplates
> > used a new keyword, like:
> >
> > blocktemplate opening(filename, mode="r"):
> > ...
> >
> > because this immediately tells me what the purpose and semantics
> > of the folowing definition is
> > 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
Guido van Rossum wrote:
> [Skip Montanaro]
>> To the casual observer, this
>> looks like "break" should break out of the loop:
>>
>> while True:
>> block synchronized(v1):
>> ...
>> if v1.field:
>> break
>> time.sleep(1)
>
> Without 'block
> > 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 th
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 imp
[Guido]
> > Where do you see a learning curve for blocks?
[Raymond]
> Altering the meaning of a for-loop; introducing a new keyword; extending
> the semantics of "break" and "continue"; allowing try/finally inside a
> generator; introducing new control flow; adding new magic methods
> __next__ and
At 11:54 PM 5/3/05 +0200, BJörn Lindqvist wrote:
>It seems like the possibilities are endless. Maybe too endless?
>Because this new feature is so similar to anonymous functions, but is
>not quite anonymous functions, so why not introduce anonymous
>functions instead, that could make all the things
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 i
[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
The documentation for Py_UNICODE states the following:
"This type represents a 16-bit unsigned storage type which is used by
Python internally as basis for holding Unicode ordinals. On platforms
where wchar_t is available and also has 16-bits, Py_UNICODE is a
typedef alias for wchar_t to enha
> FWIW, I expect most generators used in block-syntax to not be loops.
> What would imply to support these to pass "break" to parent loop at
> run-time?
I proposed this at some point during the discussion leading up to the
PEP and it was boohed away as too fragile (and I agree). You're just
going
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 Bast
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, G
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
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 fir
> >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 framewo
Another loose end (which can partially explain why I still thought
__next__ took an exception ;)
In "Specification: Generator Exit Handling"::
"When __next__() is called with an argument that is not None, the
yield-expression that it resumes will return the value attribute
of the argu
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
> But there are several separable proposals in the PEP. Using "continue
> EXPR" which calls its.__next__(EXPR) which becomes the return value of
> a yield-expression is entirely orthogonal (and come to think of it the
> PEP needs a motivating example for this).
>
> And come to think of it, using a
> 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 Runtime
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
[Guido]
> > And come to think of it, using a generator to "drive" a block
> > statement is also separable; with just the definition of the block
> > statement from the PEP you could implement all the examples using a
> > class (similar to example 6, which is easily turned into a template).
[Raymon
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
for-l
> > 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
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 a
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-D
> >(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 amount of work as updating PEP 333 and
On Tue, 2005-05-03 at 13:39 -0700, Josiah Carlson wrote:
> If I'm wrong, I'd like to hear it, but I'm still waiting for your patch
> on sourceforge.
Well, if he lost/loses interest for whatever reason, I'd be willing to
provide.
Although, if m.u.k. is going to write it, please be sure to include
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 it
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 d
I really don't know. Effbot, MvL and/or MAL should know.
On 5/3/05, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
>
> 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 sourc
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
74 matches
Mail list logo
