Terry Reedy wrote:
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>The main outcome of the PEP 343 terminology discussion was some proposed
>>documentation I put on the Sourceforge patch tracker ([1]).
>
> Is this a proposal for the Language Reference manual?
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The main outcome of the PEP 343 terminology discussion was some proposed
> documentation I put on the Sourceforge patch tracker ([1]).
Is this a proposal for the Language Reference manual?
> [1] http://www.python.org/s
FWIW, I've updated PEP 343 to use @contextmanager and class
ContextWrapper. Please proofread.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
Skip Montanaro wrote:
> After seeing so many messages about "with" statements my eyes began to glaze
> over, so I stopped following that thread. Then I saw mention of "context
> manager" with no reference to any PEPs or to the with statement to provide
> context.
The main outcome of the PEP 343 t
I wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
>
> This achieves two things: it makes them available to those who ne
On 7/8/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager. A user can do it to themselves now,
> true, but by putting a context manager fo
>> Ummm... What's a "context manager"?
Michael> Something that goes
Michael> with ... as var:
Michael> ^ here
Michael> If you have a better name, feel free to suggest it, but please
Michael> catch up on python-dev first (it's been discussed to
Michael> unconsc
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Ummm... What's a "context manager"?
Something that goes
with ... as var:
^ here
If you have a better name, feel free to suggest it, but please catch
up on python-dev first (it's been discussed to unconsciousness, if not
quite death, in the las
Michael Chermside wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
>
> This achieves two things: it makes them availabl
Ummm... What's a "context manager"?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Raymond Hettinger wrote:
>> > I compiled a list of some possible new context managers that could
> be
>> > added to the stdlib. Introducing a new feature should IMO also show
>> > usage of it in the distribution itself. That wasn't done with
>> > decorators (a decorators module is compiled at the m
James Y Knight writes:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager.
Barry Warsaw responds:
> Thinking about the types of code I write over and over again, I think I
> disagree
> > I compiled a list of some possible new context managers that could
be
> > added to the stdlib. Introducing a new feature should IMO also show
> > usage of it in the distribution itself. That wasn't done with
> > decorators (a decorators module is compiled at the moment, if I'm
> right),
> > but
Phillip J. Eby wrote:
> At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>>with sys.trace
>
> Note that it's currently not possible to inspect the trace/profile hooks
> from Python code, only from C, so that might be, um, interesting to implement.
That was beyond my short view... i
On Fri, 2005-07-08 at 16:24, Reinhold Birkenfeld wrote:
> I compiled a list of some possible new context managers that could be
> added to the stdlib.
I agree with Brett and Phillip that a few well-chosen context managers
would make sense in the stdlib both for convenience and for example
purpose
On Jul 8, 2005, at 4:46 PM, Brett Cannon wrote:
> I think having basic context managers in a stdlib module that we know
> for a fact that will be handy is a good idea. We should keep the list
> short and poignant, but we should have something for people to work
> off of. The ones I like below for
At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>with sys.trace
Note that it's currently not possible to inspect the trace/profile hooks
from Python code, only from C, so that might be, um, interesting to implement.
>* pprint: with pprint.printer (used for print)
Interesting; I'm
On 7/8/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I compiled a list of some possible new context managers that could be
> added to the stdlib. Introducing a new feature should IMO also show
> usage of it in the distribution itself. That wasn't done with
> decorators (a decorators
Hi,
I compiled a list of some possible new context managers that could be
added to the stdlib. Introducing a new feature should IMO also show
usage of it in the distribution itself. That wasn't done with
decorators (a decorators module is compiled at the moment, if I'm right),
but with context man
19 matches
Mail list logo
