[Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
Greg Ewing
greg.ewing at canterbury.ac.nz
Fri Jun 6 04:17:20 CEST 2014
More information about the Python-Dev mailing list
Fri Jun 6 04:17:20 CEST 2014
- Previous message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Next message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nathaniel Smith wrote: > I.e., BIN_ADD could do > > if (Py_REFCNT(left) == 1) > result = PyNumber_InPlaceAdd(left, right); > else > result = PyNumber_Add(left, right) > > Upside: all packages automagically benefit! > > Potential downsides to consider: > - Subtle but real and user-visible change in Python semantics. That would be a real worry. Even if such cases were rare, they'd be damnably difficult to debug when they did occur. I think for safety's sake this should only be done if the type concerned opts in somehow, perhaps by a tp_flag indicating that the type is eligible for temporary elision. -- Greg
- Previous message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Next message: [Python-Dev] [numpy wishlist] Interpreter support for temporary elision in third-party classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list