Nick Coghlan [EMAIL PROTECTED] writes:
Ron Adam wrote:
3. The with documentation could possibly be grouped with or after
the try documentation as it may be easier to understand in that context.
I was looking for an appropriate place in the tutorial to put a couple of
usage examples -
M.-A. Lemburg [EMAIL PROTECTED] writes:
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
I, as a concrete example, want
M.-A. Lemburg wrote:
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
The other suggested uses (redirecting stdout,
Michael Hudson wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
I, as
On 7/15/05, Ron Adam [EMAIL PROTECTED] wrote:
[several new syntax proposals]
Please stop proposing new syntax. The PEP was accepted after quite
enough back-and-forth; there's no point opening this up yet again.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
On 7/15/05, Ron Adam [EMAIL PROTECTED] wrote:
[several new syntax proposals]
Please stop proposing new syntax. The PEP was accepted after quite
enough back-and-forth; there's no point opening this up yet again.
My apologies Guido.
Subtracting the inappropriate
Ron Adam wrote:
3. The with documentation could possibly be grouped with or after
the try documentation as it may be easier to understand in that context.
I was looking for an appropriate place in the tutorial to put a couple of
usage examples - a new subsection immediately after the
Nick Coghlan wrote:
M.-A. Lemburg wrote:
May I suggest that you use a different name than context for
this ?!
The term context is way to broad for the application scopes
that you have in mind here (like e.g. managing a resource
in a multi-threaded application).
It's actually the broadness
{MAL]
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
Substitute different for complicated.
'with' is not application
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:
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
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
Barry Warsaw [EMAIL PROTECTED] writes:
+1 on @contextmanager
On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:
__enter__(self):
__exit__(self, exc_type, exc_value, exc_traceback):
These names should be changed to __beginwith__ and __endwith__.
-1.
-0. My fingers are
+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 discussed and rejected. These names are clear, they
*do* match, and as Fred says the __*__ namespace
At 09:12 PM 7/6/2005 +1000, Nick Coghlan wrote:
Another example is the use of contexts to handle insertion of the
appropriate tags when generating HTML:
with html:
with body:
with h1:
print Some heading
with p:
print This is paragraph
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 discussed and rejected. These names are clear,
On 7/6/05, Nick Coghlan [EMAIL PROTECTED] wrote:
OK, here's some draft documentation using Phillip's context
terminology. I think it works very well.
I agree. +1 on this terminology, and for this explanation to be
included in the docs.
I also like the fact that it offers a neat 1-word name for
Nick writes sample documentation:
For example, the following context manager allows prompt closure of
any resource with a 'close' method (e.g. a generator or file):
@context
def closing(resource):
try:
yield resource
finally:
Paul Moore wrote:
On 7/6/05, Nick Coghlan [EMAIL PROTECTED] wrote:
OK, here's some draft documentation using Phillip's context
terminology. I think it works very well.
I agree. +1 on this terminology, and for this explanation to be
included in the docs.
I also like the fact that it
On 7/6/05, Michael Chermside [EMAIL PROTECTED] wrote:
Paul Moore writes:
I also like the fact that it offers a neat 1-word name for the
generator decorator, @context.
Well, ok... does anyone *else* agree? I too saw this and thought neat!
a simple one-word name!. But then I started
Paul Moore wrote:
On 7/6/05, Michael Chermside [EMAIL PROTECTED] wrote:
Paul Moore writes:
I also like the fact that it offers a neat 1-word name for the
generator decorator, @context.
Well, ok... does anyone *else* agree? I too saw this and thought neat!
a simple one-word name!. But
Well, I'm convinced. My votes go to context management protocol and
@contextmanager. Simple, descriptive and specific in meaning yet wide
enough to cover pretty much all the cases we care about.
I think we should state in the docs that the most common usage is to set
up a specific context and
[Nick Coghlan]
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 (such as
Fred L. Drake, Jr. wrote:
On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote:
These names should be changed to __beginwith__ and __endwith__. The
current names are too vague, not obviously paired with each other, not
obviously tied to the with-statement, and provide no hint about
+1 on @contextmanager
On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:
__enter__(self):
__exit__(self, exc_type, exc_value, exc_traceback):
These names should be changed to __beginwith__ and __endwith__.
-0. My fingers are too hardwired to writing endswith, as in the
28 matches
Mail list logo
