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
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 would certainly
need
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
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 is write
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
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 decorator
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)
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())
except:
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 messages
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
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__/__exit__
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
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 given the
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
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 only
15 matches
Mail list logo
