Michael Chermside wrote:
> Guido writes:
>> I find "AttributeError: __exit__" just as informative.
>
> Eric Nieuwland responds:
>> I see. Then why don't we unify *Error into Error?
>> Just read the message and know what it means.
>> And we could then drop the burden of exception classes and only u
Guido writes:
> I find "AttributeError: __exit__" just as informative.
Eric Nieuwland responds:
> I see. Then why don't we unify *Error into Error?
> Just read the message and know what it means.
> And we could then drop the burden of exception classes and only use the
> message.
> A sense of deja
Guido van Rossum wrote:
> [Eric "are all your pets called Eric?" Nieuwland]
Hmmm... Would it be reasonable to introduce a ProtocolError
exception?
>
> [Guido]
>>> And which perceived problem would that solve?
>
> [Eric]
>> It was meant to be a bit more informative about what is wrong.
>
On 10/25/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Maybe there's a design principle in there somewhere:
>
>Failed duck-typing -> AttributeError (or TypeError for complex checks)
>Failed instance or subtype check -> TypeError
Doesn't convince me.
If there are principles at work here (a
Guido van Rossum wrote:
> On 10/25/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Almost there - this is the only issue I have left on my list :)
> [,,,]
>>> Why are you so keen on TypeError? I find AttributeError totally
>>> appropriate. I don't see symmetry with for-loops as a valuable
>>> proper
[Eric "are all your pets called Eric?" Nieuwland]
> >> Hmmm... Would it be reasonable to introduce a ProtocolError exception?
[Guido]
> > And which perceived problem would that solve?
[Eric]
> It was meant to be a bit more informative about what is wrong.
>
> ProtocolError: lacks __enter__ or __e
Guido van Rossum wrote:
> On 10/25/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> Hmmm... Would it be reasonable to introduce a ProtocolError exception?
>
> And which perceived problem would that solve? The problem of Nick &
> Guido disagreeing in public?
;-)
No, that will go on in other field
On 10/25/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> Hmmm... Would it be reasonable to introduce a ProtocolError exception?
And which perceived problem would that solve? The problem of Nick &
Guido disagreeing in public?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Guido van Rossum wrote:
> It is true though that AttributeError is somewhat special. There are
> lots of places (perhaps too many?) where an operation is defined using
> something like "if the object has attribute __foo__, use it, otherwise
> use some other approach". Some operations explicitly ch
On 10/25/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Almost there - this is the only issue I have left on my list :)
[,,,]
> > Why are you so keen on TypeError? I find AttributeError totally
> > appropriate. I don't see symmetry with for-loops as a valuable
> > property here. AttributeError and T
Almost there - this is the only issue I have left on my list :)
Guido van Rossum wrote:
> On 10/24/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> However, those resolutions bring up the following issues:
>>
>>5 a. What exception is raised when EXPR does not have a __context__
>> method?
>>
On 10/24/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> That makes the resolutions for the posted issues:
>
> 1. The slot name "__context__" will be used instead of "__with__"
> 2. The builtin name "context" is currently offlimits due to its ambiguity
> 3a. generator-iterators do NOT hav
Guido van Rossum wrote:
> Right. That was my point. Nick's worried about undecorated __context__
> because he wants to endow generators with a different default
> __context__. I say no to both proposals and the worries cancel each
> other out. EIBTI.
Works for me.
That makes the resolutions for t
On 10/23/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually, you've just pointed out a new complication introduced by having
> __context__. The return value of __context__ is supposed to have an
> __enter__ and an __exit__. Is it a type error if it doesn't? How do we
> handle that, exactly
On 10/23/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually, you've just pointed out a new complication introduced by having
> __context__. The return value of __context__ is supposed to have an
> __enter__ and an __exit__. Is it a type error if it doesn't? How do we
> handle that, exactly
At 09:19 AM 10/23/2005 -0700, Guido van Rossum wrote:
>On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > However, I'm still concerned about the fact that the following class has a
> > context manager that doesn't actually work:
> >
> >class Broken(object):
> > def __context__(self):
On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However, I'm still concerned about the fact that the following class has a
> context manager that doesn't actually work:
>
>class Broken(object):
> def __context__(self):
> print "This never gets executed"
> yield
>
Guido van Rossum wrote:
> Here's another argument against automatically decorating __context__.
>
> What if I want to have a class with a __context__ method that returns
> a custom context manager that *doesn't* involve applying
> @contextmanager to a generator?
>
> While technically this is poss
Here's another argument against automatically decorating __context__.
What if I want to have a class with a __context__ method that returns
a custom context manager that *doesn't* involve applying
@contextmanager to a generator?
While technically this is possible with your proposal (since such a
On 10/22/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I'm still looking for more feedback on the issues raised in the last update of
> PEP 343. There hasn't been much direct feedback so far, but I've rephrased and
> suggested resolutions for the outstanding issues based on what feedback I have
> r
20 matches
Mail list logo
