Nick Coghlan ncogh...@gmail.com added the comment:
should is a wonderful word when it comes to external APIs.
We currently have a couple of problems:
1. The concrete APIs will fail noisily if given an instance of something that
isn't a list, but may fail *silently* if given a subclass that
Benjamin Peterson benja...@python.org added the comment:
2011/4/6 Nick Coghlan rep...@bugs.python.org:
Nick Coghlan ncogh...@gmail.com added the comment:
should is a wonderful word when it comes to external APIs.
We currently have a couple of problems:
1. The concrete APIs will fail
Antoine Pitrou pit...@free.fr added the comment:
Why not add fast paths to the generic functions if that's what you're
concerned about?
It's unexpected for the user of the functions and breaks years of
tradition. What if someone calls PyList_Append on a custom type that
doesn't do as they
Nick Coghlan ncogh...@gmail.com added the comment:
1. It's an external API. We *don't control* most of the potentially broken
code, so saying just fix the call sites effectively solves nothing and leaves
classes like OrderedDict at risk of subtle silent corruption whenever they are
passed to
Nick Coghlan ncogh...@gmail.com added the comment:
Having convinced myself that Raymond's original suggestion can't be implemented
safely, I have an alternative (arguably even more radical) proposal:
Deprecate the public concrete API functions that modify object state.
Put an underscore in
Antoine Pitrou pit...@free.fr added the comment:
1. It's an external API. We *don't control* most of the potentially
broken code, so saying just fix the call sites effectively solves
nothing and leaves classes like OrderedDict at risk of subtle silent
corruption whenever they are passed to a
Nick Coghlan ncogh...@gmail.com added the comment:
Changing the affected components. Antoine and Benjamin are right, this needs to
be handled as a documentation and education problem.
Raymond's suggestion can too easily trigger infinite recursion and mine would
block legitimate use cases in
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
One thing that could be done is to have an optional warning in the mutating
concrete C API functions that gets triggered whenever the input doesn't have an
exact type match. That will let people discover incorrect uses.
We
Nick Coghlan ncogh...@gmail.com added the comment:
I thought about a warning, but the problem is that a subclass using the
concrete API as part of its *implementation* of the associated slot or method
is actually perfectly correct usage.
I'm not sure this is enough to give up on the idea of
Nick Coghlan ncogh...@gmail.com added the comment:
I may have found another use case for this functionality. Currently, the Python
code in heapq.py accepts arbitrary sequences (that are sufficiently compatible
with the Sequence ABC), but the C code in _heapq only permits use of a concrete
Nick Coghlan ncogh...@gmail.com added the comment:
I added a few commments on Daniel's draft patch. However, I'm getting nervous
about the performance impact of all these extra pointer comparisons.
We should probably hold off on this until more of the macro benchmark suite
runs on Py3k so we
Benjamin Peterson benja...@python.org added the comment:
I find this extremely ugly. The correct way to handle this is to use the
generic methods themselves. Really, the type-specific names should only be used
when you have just created the type or done PyXXX_CheckExact() yourself on it.
Daniel Urban urban.dani...@gmail.com added the comment:
Here is a patch for list. It modifies the following C API functions:
PyList_SetItem
PyList_Insert
PyList_Append
PyList_SetSlice
PyList_Sort
PyList_Reverse
_PyList_Extend
It also includes tests (with ctypes).
I plan to do next the same
Antoine Pitrou pit...@free.fr added the comment:
Hmm, making PyList_* an abstract API doesn't make sense to me. These functions
do exactly what they say: they operate on concrete instances of list (they are
documented as part of the concrete API). With that reasoning, we should have
fallback
Changes by Andreas Stührk andy-pyt...@hammerhartes.de:
--
nosy: +Trundle
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
By the way, PyList_SetItem() already has an
abstract counterpart called PyObject_SetItem(),
so changing this one seems useless.
The problem isn't a lack of available abstract
functions. If some code uses PyObject_SetItem(),
Antoine Pitrou pit...@free.fr added the comment:
The problem isn't a lack of available abstract
functions.
Then what is it exactly?
You are arguing for PyList_SetItem() to have the same semantics as
PyObject_SetItem(), but what's the point of having two functions which
do exactly the same
Nick Coghlan ncogh...@gmail.com added the comment:
It's largely a backwards compatibility hack, but the concrete methods also have
an optimised fast path that the generic methods lack.
So (for example), PyList_SetItem would now mean this is *probably* a list, so
check for that and use the
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
I'm just pointing out a problem. Lots of existing code uses the concrete API
and that code can break subclasses of builtin types (possibly resulting in
segfaults).
I don't really care what is done about it. I'm just observing
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +durban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Python-bugs-list
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
title: Concrete object C API needs abstract path for subclasses of builtin
types - Concrete object C API needs abstract path for subclasses of builtin
types
___
Python tracker
New submission from Raymond Hettinger rhettin...@users.sourceforge.net:
Currently, the concrete object C API bypasses any methods defined on subclasses
of builtin types.
It has long been accepted that subclasses of builtin types need to override
many methods rather than just a few because
22 matches
Mail list logo
