On 7/7/05, Walter Dörwald [EMAIL PROTECTED] wrote:
What is still unspecified (or at least not explicitely mentioned) in
the PEP is the lifetime of VAR in:
with EXPR as VAR:
BLOCK
It is specified well enough IMO -- you're supposed to take the
translation into basic
Guido van Rossum wrote:
On 7/7/05, Walter Dörwald [EMAIL PROTECTED] wrote:
What is still unspecified (or at least not explicitely mentioned) in
the PEP is the lifetime of VAR in:
with EXPR as VAR:
BLOCK
It is specified well enough IMO -- you're supposed to take the
Walter Dörwald [EMAIL PROTECTED] writes:
Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
+1 on @contextmanager
+1.
[__enter__, __exit__]
These names should be changed to __beginwith__ and __endwith__.
-1. The PEP has had an extensive review period and several
alternatives were
Michael Hudson wrote:
Walter Dörwald [EMAIL PROTECTED] writes:
[...]
I.e. will VAR still exist after the end of the block with its value
the return value of __enter__() or will it revert to the previous
value (if any)?
Eh, no. Where would you store the old value?
I don't know, where does:
Ron Adam [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
I even wonder if else-clauses on for/while were a good idea. (The one
on try is definitely a good idea since the use case is quite frequent
and only clumsily handled otherwise; the use cases for else on
for/while are less convincing
Thomas Heller:
OTOH, I once had a bug report from a py2exe user who complained that the
program didn't start when installed in a path with japanese characters
on it. I tried this out, the bug existed (and still exists), but I was
astonished how many programs behaved the same: On a PC with
Brett #. Gather important information
Brett Info such as Python version, operating system version, etc.;
Brett anything that might have influenced the code that lead to the
Brett bug.
I'd change this to something more explicit:
# Gather important information
[Christoph, please keep the python-dev list in the loop here, at least
until they get annoyed and decide we're off-topic. I think this is
crucial to the way they package and deliver Python]
Christoph Ludwig [EMAIL PROTECTED] writes:
On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams
[EMAIL PROTECTED] wrote:
... if Py3k ever happens, I'd hope that it would be the *one* Python
to use -- too many incompatibilities would probably mean *two*
Pythons fighting each other).
A caduceus to heal software problems?
http://www.pantheon.org/articles/c/caduceus.html
--Scott David
Michael Hudson wrote:
Ron Adam [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
I even wonder if else-clauses on for/while were a good idea. (The one
on try is definitely a good idea since the use case is quite frequent
and only clumsily handled otherwise; the use cases for else on
Thomas Lotze wrote:
Ron Adam [EMAIL PROTECTED] wrote:
3. In a while loop, it's a value test, where the else block gets
executed if the while condition evaluates as false, the while block
may or may not execute. You still need a flag to test for that.
You're effectively arguing for
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Phillip J. Eby wrote:
I suggest changing this to something like this:
class tag(object):
def __init__(self,name):
self.name = name
def __enter__(self):
print %s % name
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
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 module
In order to lower the barrier for reporting bugs, writing patches, and
handling CVS commits, I am writing up checklists for each and I will
put them up on python.org.
-0 on the checklists. I don't think existing barriers are high at
all. The entries may be variously regarded as codifying
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 a
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
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... if it
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
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
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 moment, if
Nick Coghlan wrote:
OK, here's some draft documentation using Phillip's context
terminology. I think it works very well.
With Statements and Context Management
A frequent need in programming is to ensure a particular action is
taken after a specific section of code has been executed
David Abrahams wrote:
Unless, of course, I'm missing something. So if I am missing
something, what is it?
You are missing something, and I can only repeat myself. Some systems
require main() to be compiled as C++, or else constructors may not work
(and perhaps other things fail as well). The
David Abrahams wrote:
When I looked into this problem I saw that configure in fact builds a test
executable that included an object file compiled with g++. If the link step
with gcc succeeds then LINKCC is set as above, otherwise CXX is
used. Obviously, on my system this test was successful so
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
David Abrahams wrote:
If there is some library with such objects that happens to get
wrapped and dynamically linked into a Python interpreter
Whoa there. How would that ever happen under ordinary circumstances?
Doesn't Python's makefile control what gets linked to Python?
Not entirely. By
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 available to
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
If there is some library with such objects that happens to get
wrapped and dynamically linked into a Python interpreter
Whoa there. How would that ever happen under ordinary circumstances?
Doesn't Python's makefile control
Raymond Hettinger [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In order to lower the barrier for reporting bugs, writing patches, and
handling CVS commits, I am writing up checklists for each and I will
put them up on python.org.
-0 on the checklists.
I am more enthusiastic
29 matches
Mail list logo
