[Python-Dev] Should we do away with unbound methods in Py3k?
Nick Coghlan
ncoghlan at gmail.com
Thu Nov 22 12:27:03 CET 2007
More information about the Python-Dev mailing list
Thu Nov 22 12:27:03 CET 2007
- Previous message: [Python-Dev] Should we do away with unbound methods in Py3k?
- Next message: [Python-Dev] A crash during interpreter cleanup when using PyGILState APIs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum wrote: > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case), so that explicit super calls (via the unbound method) > may go a little faster. Also, it would make it easier to fix this > issue: http://bugs.python.org/issue1109 Assuming the proposal is simply to change function.__get__ to return self when the second argument is None, then +1. The method descriptors for types written in C should continue to return a wrapper which performs the typecheck, as C method implementations tend to assume that the self argument is guaranteed to be of the correct type. Having to perform that check manually would be rather tedious. This does introduce a new discrepancy between types implemented in C and Python classes, but I suspect that the underlying difference in memory layout restrictions is always going to leak through in at least a few places. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
- Previous message: [Python-Dev] Should we do away with unbound methods in Py3k?
- Next message: [Python-Dev] A crash during interpreter cleanup when using PyGILState APIs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list