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
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
received, and my own thoughts over the last week of so.
Fo
21 matches
Mail list logo
