Just a quick note. Nick convinced me that adding __with__ (without
losing __enter__ and __exit__!) is a good thing, especially for the
decimal context manager. He's got a complete proposal for PEP changes
which he'll post here. After a brief feedback period I'll approve his
changes and he'll check
On 10/4/05, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Right after I sent the preceding message I got a funny feeling I'm
> wasting everybody's time here. I apologize. Guido's original concern
> about speedy C implementation for locks stands. I don't see a good
> way around it.
OK. Our messag
On 10/4/05, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> This:
>
> with EXPR as VAR:
> BLOCK
>
> expands to this under PEP 342:
>
> _cm = contextmanager(EXPR)
> VAR = _cm.next()
> try:
> BLOCK
> except:
> try:
> _cm.throw(*sys.exc_info())
>
Right after I sent the preceding message I got a funny feeling I'm
wasting everybody's time here. I apologize. Guido's original concern
about speedy C implementation for locks stands. I don't see a good
way around it.
By the way, my expansion of 'with' using coroutines (in previous
message) was
The argument I am going to try to make is that Python coroutines need
a more usable API.
> Try to explain the semantics of the with statement without referring to the
> __enter__ and __exit__ methods, and then see if you still think they're
> superfluous ;)
>
> The @contextmanager generator decora
On 10/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I was planning on looking at your patch too, but I was waiting for an answer
> from Guido about the fate of the ast-branch for Python 2.5. Given that we have
> patches for PEP 342 and PEP 343 against the trunk, but ast-branch still isn't
> even
Jason Orendorff wrote:
> Phillip J. Eby writes:
>
>>You didn't offer any reasons why this would be useful and/or good.
>
>
> It makes it dramatically easier to write Python classes that correctly
> support 'with'. I don't see any simple way to do this under PEP 343;
> the only sane thing to do
Michael Hudson wrote:
> I think 'as big as new-style classes' is probably an exaggeration, but
> I'm glad my troll caught a few people :)
I was planning on looking at your patch too, but I was waiting for an answer
from Guido about the fate of the ast-branch for Python 2.5. Given that we have
pa
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 07:02 PM 10/3/2005 +0100, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > Since the PEP is accepted and has patches for both its implementation
>> and a
>> > good part of its documentation, a major change like this wou
At 05:15 PM 10/3/2005 -0400, Jason Orendorff wrote:
>Phillip J. Eby writes:
> > You didn't offer any reasons why this would be useful and/or good.
>
>It makes it dramatically easier to write Python classes that correctly
>support 'with'. I don't see any simple way to do this under PEP 343;
>the on
Phillip J. Eby writes:
> You didn't offer any reasons why this would be useful and/or good.
It makes it dramatically easier to write Python classes that correctly
support 'with'. I don't see any simple way to do this under PEP 343;
the only sane thing to do is write a separate @contextmanager
gen
At 07:02 PM 10/3/2005 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>
> > Since the PEP is accepted and has patches for both its implementation
> and a
> > good part of its documentation, a major change like this would certainly
> > need a better rationale.
>
>Though g
For the record, I very much want PEPs 342 and 343 implemented. I
haven't had the time to look at the patch and don't expect to find the
time any time soon, but it's not for lack of desire to see this
feature implemented.
I don't like Jason's __with__ proposal and even less like his idea to
drop __
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Since the PEP is accepted and has patches for both its implementation and a
> good part of its documentation, a major change like this would certainly
> need a better rationale.
Though given the amount of interest said patch has attracted (none at
At 12:37 PM 10/3/2005 -0400, Jason Orendorff wrote:
>I'm -1 on PEP 343. It seems ...complex. And even with all the
>complexity, I *still* won't be able to type
>
> with self.lock: ...
>
>which I submit is perfectly reasonable, clean, and clear.
Which is why it's proposed to add __enter__/__e
I'm -1 on PEP 343. It seems ...complex. And even with all the
complexity, I *still* won't be able to type
with self.lock: ...
which I submit is perfectly reasonable, clean, and clear. Instead I
have to type
with locking(self.lock): ...
where locking() is apparently either a new built
16 matches
Mail list logo
