[Python-3000] State of the object system

[Josiah Carlson]

Kay Schluehr <kay.schluehr at gmx.net> wrote:
> Terry Reedy schrieb:
> >>Unfortunately, for implementation reasons you can't modify most
> >>built-in (and some user-defined) classes in this fashion:
> >>    
> >Being able to add Python-coded functions as methods of compiled C-coded 
> >types/classes (builting or otherwise) would require some wrapping machinery 
> >that would slow down normal usage.
> >  
> >
> Getting rid of C-coded types is certainly an interesting requirement as 
> well. I hope PyPythonistas may agree :)
> 
> Honestly, I don't understand how a pointer on an implicit/interpreter 
> level Trait that stores user defined methods for builtins would slow 
> execution down. You would need wrappers only if you permit 
> replacing/deleting pre-defined methods and I don't see reasons to be 
> permissive here.

Personally, I don't have much of an issue using utility modules to
perform operations like 'isprime()' and 'iseven()' as you pointed out in
another post.  Maybe it's my non-OOP background coming in and saying
"not everything needs to be a method" and "duck typing allows me to use
this for more than just type X".

Ultimately the question comes down to: why should anyone be able to
attach arbitrary metadata to builtin types?  While such metadata (which
could include functions) could be useful, it doesn't seem particularly
"Pythonic".


As long as it wouldn't noticeably degrade the performance of base types,
I wouldn't see a problem with making base types return the proper
subclass from which the methods were being called.  That is, if I have
declared myInt to be a subclass of int, and I perform an operation on
myInt (like perhaps adding), that int would automatically create a myInt
type on return (for all methods for which this would make sense).


 - Josiah