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
> usa
> "Jim" == Jim Jewett <[EMAIL PROTECTED]> writes:
Jim> Nick Coghlan asked Marc-Andre Lemburg:
>> There's clearly something that bothers you about this though,
>> and I'd like to understand what it is. Does the term 'context'
>> carry additional, more specific, connotations for
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 th
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 inappropriat
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/)
__
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 tha
Nick Coghlan asked Marc-Andre Lemburg:
> There's clearly something that bothers you about this though, and I'd like to
> understand what it is. Does the term 'context' carry additional, more
> specific, connotations for you that I'm simply not taking into account?
To me, a context is much large
M.-A. Lemburg wrote:
> If you then start using terms in the documentation that cause
> wrong associations, you make life harder for new programmers.
I agree that every new construct and protocol makes life that much harder for
anyone learning Python, but the bit I'm having trouble grasping is why
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, log
Raymond Hettinger wrote:
> {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
"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,
{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 applica
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 ac
Terry Reedy wrote:
> Would this also work as a decorated generator?
> (If I have understood correctly, something like..)
>
> @contextmanager
> def tag(name)
>print "<%s>" % name
>yield None
>print "" % name
>
> If so, I suggest putting in both versions to make the correspo
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 of the term
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 e
"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):
>> pri
"Walter Dörwald" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>x = blist()
>x(1)
>with blist(x) as x:
>x(2)
>with blist(x) as x:
> x(3)
>x(4)
>x(5)
>This would create the list:
>[1, [2, [3], 4], 5]
>With the current version of PEP 343, we would either have to us
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
> def __exit__(self):
> print "" % name
>
>
Walter Dörwald <[EMAIL PROTECTED]> writes:
> 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.
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, w
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
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
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 basi
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. Thes
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 i
> > +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 __*__ namesp
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.
+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
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
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 what
> calls them. Remembe
[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 execute
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 re
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-
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 st
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 fac
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:
> r
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
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
closing a file or
39 matches
Mail list logo
