Raymond Hettinger, 18.04.2011 19:26: > On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote: >> >> * we usually target CPython version that's already frozen, which is >> pretty inconvinient to post this changes back. Example would be a >> socket module where it has changed enough in 3.x that 2.7 changes make >> no sense. > > Do you have any thoughts on the problem with the concrete C API > not working well with subclasses of builtin types? > > I'm thinking that the PEP should specifically ban the practice > of using the concrete api unless it is known for sure that > an object is an exact type match. Absolutely. > It is okay to write PyList_New() followed by PyList_SetItem() > but not okay to use PyList_SetItem() on a user supplied > argument that is known to be a subclass of list. A fast path > can be provided for an exact path, but there would also need > to a be a slower path that either converts the object to > an exact list or that uses PyObject_SetItem(). For what it's worth, Cython generates code that contains optimistic optimisations for common cases, such as iteration, x.append() calls, etc. When it finds such a pattern, it generates separate code paths for the most likely (builtin type) case and a slower fallback for the more unlikely case of a user provided type. So you get both speed and compatibility for free, just by writing idiomatic code like "for item in some_iterable". Stefan
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