Guido van Rossum wrote:
> On 11/28/05, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
>> I think we need to fix the proposed semantics so that they access the slots
>> via the type, rather than directly through the instance. Otherwise the slots
>> for the with statement will behave strangely when compared to the slots for
>> other magic methods.
>
> Maybe it's because I'm just an old fart, but I can't make myself care
> about this. The code is broken. You get an error message. It even has
> the correct exception (TypeError). In this particular case the error
> message isn't that great -- well, the same is true in many other cases
> (like whenever the invocation is a method call from Python code).
I'm not particularly worried about the error message - as you say, it even has
the right type. Or at least one of the two right types ;)
> That most built-in operations produce a different error message
> doesn't mean we have to make *all* built-in operations use the same
> approach. I fail to see the value of the consistency you're calling
> for.
The bit that more concerns me is the behavioural discrepancy that comes from
having a piece of syntax that looks in the instance dictionary. No other
Python syntax is affected by the instance attributes - if the object doesn't
have the right type, you're out of luck.
Sticking an __iter__ method on an instance doesn't turn an object into an
iterator, but with the current semantics, doing the same thing with
__context__ *will* give you a manageable context.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4