> b=B() # error, A.__init__ expects an instanc of A
>
>why is this kind of type-checking enforced by the language?
[greg]
>Since type-class unification, there is no clear boundary <snip> If you were allowed to pass any object to any method, there would be a danger of crashing the interpreter.
I've always expected `AttributeError` if I call `A.somemethod(otherself)` AND otherself does not conform to the expectations of `A.somemethod`. I still find `error, A.somemethod expects an instance of A` *very* surprising.
`TypeError` is something I would expect if I broke the typing rules of the underlying implementation. By 'underlying implementation' I mean the interpreter AND any extension library that uses the interpreters foreign function provisions to provide extension types. IIUC greg is saying this is exactly what Talin's example does.
In the python tutorial 'self' is introduced like this: "the special thing about methods is that the object is passed as the first argument of the function". And ever since reading that I've always expected to be able to treat 'self' as just another parameter. Talins' first example illustrates that 'self' can not be treated this way.
If there was a way to allow `A.somemethod(otherself)` where `isinstance(otherself, A) is False`, as a language feature, then I would find my self reaching for things like PyProtocols less often. I'm not knocking PyProtocols, I just wish there was a middle ground available that didn't nobble future adoption (no pun intended) of PyProtocols et al.
Does resolving the can of worms that greg alludes to belong in the 'very difficult' or 'insufficient motivation & use' camp ?
I don't care too much about making life harder for extention authors. Software never so much resembeled the cavalry to me as when I first encountered Pyrex.
Robin
http://docs.python.org/tut/node11.html#SECTION0011340000000000000000
On 12/05/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
tomer filiba wrote:
> b=B() # error, A.__init__ expects an instanc of A
>
> why is this kind of type-checking enforced by the language?
Since type-class unification, there is no clear boundary
between built-in and user-defined classes. Any class can
potentially add C-level data to its instances and have
methods implemented in C that operate on it. If you were
allowed to pass any object to any method, there would
be a danger of crashing the interpreter.
> what this code does is basically changing the __mro__ of the object. had
> __mro__ been mutable, it would all be simpler.
Being able to change the mro after class creation would
lead to similar problems.
--
Greg
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: http://mail.python.org/mailman/options/python-3000/robinbryce%40gmail.com
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
