On 14Jun2009 16:42, Mark Seaborn 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 try/except at least closes
On 16Jun2009 02:18, MRAB 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, up to n bytes.
A
Cameron Simpson wrote:
On 16Jun2009 11:21, Greg Ewing 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 some c
On 16Jun2009 11:21, Greg Ewing 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 some circumstances.
Pro
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 pla
Paul Moore wrote:
> 2009/6/15 Terry Reedy :
>> 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 t
Benjamin Peterson wrote:
> 2009/6/15 Nick Coghlan :
>> 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)
There seem to be some issues with Subversion, so that's probably affecting hg.
2009/6/15 Paul Moore :
> I get the following:
>
>>hg version
> Mercurial Distributed SCM (version 1.2)
>
> Copyright (C) 2005-2008 Matt Mackall and others
> This is free software; see the source for copying conditions.
I get the following:
>hg version
Mercurial Distributed SCM (version 1.2)
Copyright (C) 2005-2008 Matt Mackall 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 http://code.py
2009/6/15 Terry Reedy :
> 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
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 t
2009/6/15 Raymond Hettinger :
> 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
> that is m
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
i
2009/6/15 Nick Coghlan :
> 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 setting a
Guido van Rossum wrote:
On Mon, Jun 15, 2009 at 9:10 AM, Michael Foord 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. T
On Mon, Jun 15, 2009 at 9:10 AM, Michael Foord 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 attempts to pro
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 ca
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 completel
On Sun, Jun 14, 2009 at 4:19 PM, 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 setting
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
Jean-Paul Calderone wrote:
On Tue, 09 Jun 2009 16:46:54 +0200, Kálmán Gergely
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 little less beating for my
s
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 setting a specific attribute (another ex
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
---
__
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 tha
> 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
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 j
> 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
27 matches
Mail list logo
