Guido van Rossum wrote: > > > > -1 > > > > > > While this looks cute, I think it would break a lot of introspection > > > code or other code which special cases Python functions for > > > some reason since type(int) would no longer return > > > types.BuiltinFunctionType. > > > > Looks like I'm alone with my uncertain feeling about this move... > > oh well. > > Well, I don't see how someone could be doing introspection on int and > be confused when it's not a function -- either you (think you) know > it's a function, so you use it as a function without introspecting it, > and that continues to work; or you're open to all possibilities, and > then you'll introspect it, and then you'll discover what it is. Ok, let's put it in another way: The point is that your are changing the type of very basic building parts in Python and that is likely to cause failure in places which will most likely be hard to find to fix. Becides we don't really gain anything from replacing builtin functions with classes (to the contrary: we lose some, since we can no longer use the function call optimizations for builtins and have to go through all the generic call mechanism code instead). Also, have you considered the effects this has on restricted execution mode ? What will happen if someone replaces the builtins with special versions which hide some security relevant objects, e.g. open() is a prominent candidate for this. Why not put the type objects into a separate module instead of reusing the builtins ? > > BTW, we should consider having more than one contructor for an > > object rather than trying to stuff all possible options and parameters > > into one overloaded super-constructor. I've done this in many of > > my mx extensions and have so far had great success with it (better > > programming error detection, better docs, more intuitive interfaces, > > etc.). In that sense, more than one way to do something will > > actually help clarify what the programmer really wanted. Just > > a thought... > > Yes, but the other ways are spelled as factory functions. Maybe, > *maybe* the other factory functions could be class-methods, but don't > hold your hopes high. No... why make things complicated when simple functions work just fine as factories. Multilpe constructors on a class would make subclassing a pain... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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