> > -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. > 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
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