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
18 matches
Mail list logo
