On 10/7/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
the whole concept might be perfectly fine on the this construct corre-
sponds to this code level, but if you immediately end up with things that
are not what they seem, and names that don't mean what the say, either
the design or the
On 10/9/05, Anders J. Munch [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Anders J. Munch wrote:
Note that __with__ and __enter__ could be combined into one with no
loss of functionality:
abc,VAR = (EXPR).__with__()
They can't be combined, because they're invoked on
Based on Jason's comments regarding decimal.Context, and to explicitly cover
the terminology agreed on during the documentation discussion back in July,
I'm proposing a number of changes to PEP 343. I'll be updating the checked in
PEP assuming there aren't any objections in the next week or so
Nick Coghlan wrote:
9. Here's a proposed native context manager for decimal.Context:
# This would be a new decimal.Context method
@contextmanager
def __with__(self):
wouldn't it be better if the ContextWrapper class (or some variation thereof)
could
be used as a
Fredrik Lundh wrote:
Nick Coghlan wrote:
9. Here's a proposed native context manager for decimal.Context:
# This would be a new decimal.Context method
@contextmanager
def __with__(self):
wouldn't it be better if the ContextWrapper class (or some variation
Nick Coghlan [EMAIL PROTECTED] writes:
What if we simply special-cased the __with__ slot in type(), such that if it
is populated with a generator object, that object is automatically wrapped
using the @contextmanager decorator? (Jason actually suggested this idea
previously)
nit
You don't
Nick Coghlan did a +1 job to write:
1. Amend the statement specification such that:
with EXPR as VAR:
BLOCK
is translated as:
abc = (EXPR).__with__()
exc = (None, None, None)
VAR = abc.__enter__()
try:
try:
Nick Coghlan wrote:
1. Amend the statement specification such that:
with EXPR as VAR:
BLOCK
is translated as:
abc = (EXPR).__with__()
exc = (None, None, None)
VAR = abc.__enter__()
try:
try:
BLOCK
Eric Nieuwland wrote:
What happens to
with 40*13+2 as X:
print X
It would fail with a TypeError because the relevant slot in the type object
was NULL - the TypeError checks aren't shown for simplicity's sake.
This behaviour isn't really any different from the existing PEP 343 -
Anders J. Munch wrote:
Note that __with__ and __enter__ could be combined into one with no
loss of functionality:
abc,VAR = (EXPR).__with__()
They can't be combined, because they're invoked on different objects. It would
be like trying to combine __iter__() and next() into the same
Michael Hudson wrote:
nit
You don't want to check if it's a generator, you want to check if it's
a function whose func_code has the relavent bit set.
/nit
Fair point :)
Seems a bit magical to me, but haven't thought about it hard.
Same here - I'm just starting to think that the alternative
Nick Coghlan wrote:
Eric Nieuwland wrote:
What happens to
with 40*13+2 as X:
print X
It would fail with a TypeError because the relevant slot in the type
object
was NULL - the TypeError checks aren't shown for simplicity's sake.
This behaviour isn't really any different
Nick Coghlan wrote:
That's not what the decorator is for - it's there to turn the generator used
to implement the __with__ method into a context manager, rather than saying
anything about decimal.Context as a whole.
possibly, but using a decorated __with__ method doesn't make much
sense if
Fredrik Lundh wrote:
Nick Coghlan wrote:
However, requiring a decorator to get a slot to work right looks pretty ugly
to me, too.
the whole concept might be perfectly fine on the this construct corre-
sponds to this code level, but if you immediately end up with things that
are not what
14 matches
Mail list logo
