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
17 matches
Mail list logo
