Part of the justification for the new with-statement syntax was
that nested() doesn't have a way to finalize the constructors
if one of them fails.
I think the problem was a little bit more subtle: nested() gets passed
managers, so their __init__()s should all have run when the first
context
Hagen Fürstenau wrote:
I actually almost asked for that to be changed to a
PendingDeprecationWarning when it was first added - Benjamin, do you
mind if I downgrade this warning to a pending one post rc2?
I'm not sure what that would buy us. For the use case I mentioned it
would be just as
Unlike a full DeprecationWarning, a PendingDeprecationWarning is ignored
by default. You have to switch them on explicitly via code or a command
line switch in order to see them.
Sorry, I should have made myself more familiar with the warnings
mechanism before writing. In that case I'm fine
Raymond Hettinger wrote:
I suggest a PEP for 2.7 and 3.2 for building-out the
with-statement to support tuples of context managers
(perhaps modeled after the syntax for except-statements
which allows either individual exceptions or tuples of
exceptions). The reason I suggest a PEP is that
Mark Seaborn wrote:
[3]
http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html
Very cool!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
Jean-Paul Calderone wrote:
On Tue, 09 Jun 2009 16:46:54 +0200, Kálmán Gergely
kalman.gerg...@duodecad.hu wrote:
Hello, my name is Greg.
I've just started using python after many years of C programming, and
I'm also new to the list. I wanted to clarify this
first, so that maybe I will get a
Kálmán Gergely wrote:
Since I am not a python core developer the patch might still be in a
pretty outdated state. I'd like someone to look it over
and direct me to some documentation (the ones I've found so far were
pretty sketchy), for it to be acceptable for inclusion.
The sanity of the
On Sun, Jun 14, 2009 at 4:19 PM, Guido van Rossumgu...@python.org wrote:
In general, CPython isn't always consistent in raising AttributeError
and TypeError when it comes to such policy issues: there are various
places that raise TypeError in typeobject.c (and probably elsewhere)
that simply
Guido wrote:
I should add that this policy is also forced somewhat by the existence
of the multiple interpreters in one address space feature, which is
used e.g. by mod_python. This feature attempts to provide isolation
between interpreters to the point that each one can have a completely
Dino Viehland wrote:
Guido wrote:
I should add that this policy is also forced somewhat by the existence
of the multiple interpreters in one address space feature, which is
used e.g. by mod_python. This feature attempts to provide isolation
between interpreters to the point that each one can
On Mon, Jun 15, 2009 at 9:10 AM, Michael Foordfuzzy...@voidspace.org.uk wrote:
Dino Viehland wrote:
Guido wrote:
I should add that this policy is also forced somewhat by the existence
of the multiple interpreters in one address space feature, which is
used e.g. by mod_python. This feature
Guido van Rossum wrote:
On Mon, Jun 15, 2009 at 9:10 AM, Michael Foordfuzzy...@voidspace.org.uk wrote:
Dino Viehland wrote:
Guido wrote:
I should add that this policy is also forced somewhat by the existence
of the multiple interpreters in one address space feature, which is
2009/6/15 Nick Coghlan ncogh...@gmail.com:
Guido van Rossum wrote:
In general, CPython isn't always consistent in raising AttributeError
and TypeError when it comes to such policy issues: there are various
places that raise TypeError in typeobject.c (and probably elsewhere)
that simply forbid
I don't consider changing a DeprecationWarning to a
PendingDeprecationWarning resurrecting its target.
Seems like resurrection to me. Pending warnings are hidden
by default, so someone has to go look for it (and no one does this).
The problem with the nested() construct is not so much that
it
2009/6/15 Raymond Hettinger pyt...@rcn.com:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
Right now, the current example just shows the hazardous pattern
Raymond Hettinger wrote:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
It could even suggest that it only be used for this, since it may
disappear, and
2009/6/15 Terry Reedy tjre...@udel.edu:
Raymond Hettinger wrote:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
It could even suggest that it only be
I get the following:
hg version
Mercurial Distributed SCM (version 1.2)
Copyright (C) 2005-2008 Matt Mackall m...@selenic.com and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
hg clone
There seem to be some issues with Subversion, so that's probably affecting hg.
2009/6/15 Paul Moore p.f.mo...@gmail.com:
I get the following:
hg version
Mercurial Distributed SCM (version 1.2)
Copyright (C) 2005-2008 Matt Mackall m...@selenic.com and others
This is free software; see the
Benjamin Peterson wrote:
2009/6/15 Nick Coghlan ncogh...@gmail.com:
Guido van Rossum wrote:
In general, CPython isn't always consistent in raising AttributeError
and TypeError when it comes to such policy issues: there are various
places that raise TypeError in typeobject.c (and probably
Paul Moore wrote:
2009/6/15 Terry Reedy tjre...@udel.edu:
Raymond Hettinger wrote:
P.S. If you switch to PendingDeprecationWarning, the example
in the docs should probably be switched to show the one valid
use case (passing in a prepackaged nest of context managers).
It could even suggest
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams? I find
it's better to steer well clear of buffered I/O objects
when doing non-blocking stuff, because they don't
On 16Jun2009 11:21, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams?
Sure, in C, python and perl quite happily. In
Cameron Simpson wrote:
On 16Jun2009 11:21, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams?
Sure, in C, python and
On 16Jun2009 02:18, MRAB pyt...@mrabarnett.plus.com wrote:
My itch is that peek() _feels_ like it should be look into the buffer
but actually can block and/or change the buffer.
Can block, but not if you don't want it too. You might just want to see
what, if anything, is currently available,
On 14Jun2009 16:42, Mark Seaborn m...@mythic-beasts.com wrote:
| I use a convenience function like this, so that GC takes care of the FDs:
|
| def make_pipe():
| read_fd, write_fd = os.pipe()
| return os.fdopen(read_fd, r), os.fdopen(write_fd, w)
Not guarrenteed to be timely. The
26 matches
Mail list logo
