Kay Schluehr <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
