Jason Orendorff wrote:
> On 10/12/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>Strictly speaking this fits in with the existing confusion of "generator
>>factory" and "generator":
>>
>>Py> def g():
>>... yield None
>>...
>>Py> type(g)
>>
>>Py> type(g())
>>
>>
>>Most people would call "g" a
Greg Ewing wrote:
> Jason Orendorff wrote:
>
>
>>A contextmanager is a function that returns a new context manager.
>>
>>Okay, that last bit is weird.
>
>
> If the name of the decorator is to be 'contextmanager', it
> really needs to say something like
>
>The contextmanager decorator t
Jason Orendorff wrote:
> A contextmanager is a function that returns a new context manager.
>
> Okay, that last bit is weird.
If the name of the decorator is to be 'contextmanager', it
really needs to say something like
The contextmanager decorator turns a generator into a
function th
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 de
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, bec
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 different objects.
>
Sure they can. The comb
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
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
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
Michael Hudson wrote:
>
> 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.
>
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 is
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 sa
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 34
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
>
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 <[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)
You don
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 som
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
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 (
18 matches
Mail list logo
