[Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules
steve at pearwood.info
Mon Jul 11 09:11:28 EDT 2016
On Mon, Jul 11, 2016 at 01:32:32PM +1000, Chris Angelico wrote:
> On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> > (1) How much extra effort are we going to *mandate* that core devs put
> > in to hide the differences between C and Python code, for the benefit of
> > a small minority that will notice them?
> The subject line is raising one specific difference: the use of a
> function in one version and a class in the other. I think it's not
> unreasonable to stipulate one specific incompatibility that mustn't be
Not so fast. Have you read the bug tracker issue that started this?
There are certain things, such as functools.partial() objects, which are
most naturally implemented as a closure (i.e. a function) in Python, and
as a class in C. Whether partial() happens to be a class or a function
is an implementation detail. There are advantages to being able to write
the simplest code that works, and prohibiting that mismatch means that
you cannot do that.
If a core developer wishes to extend the API of partial objects to
include such things as subclassing, isinstance tests, pickling etc, then
it is reasonable to insist that both the C and the Python implementation
both support the same API and both use a class. But at the moment I
don't think any of those things are promised or supported, except by
accident, so removing the discrepency between them is not a bug fix, but
adding new features.
The more I think about it, the more I feel that it is *unreasonable* to
mandate that devs must ensure that alternate implementations mirror each
others *unsupported and accidental features*. Mirror the supported API?
Absolutely! But not accidental features.
I think its worth reading the issue on the tracker:
This isn't an actual problem that occurred in real code, it's a
theoretical issue that Emanuel discovered, and by his own admission
feels that he was doing something dubious ("It may not be the best idea
to subclass something that is meant to be final" -- ya think?). Raymond
Hettinger makes some good points about the costs of feature creep needed
to support these accidental implementation features, and is against it.
But on the other hand, Serhiy also makes some good points about the
usefulness of pickling partial objects. So as far as this *specific*
issue goes, perhaps it is justified to make sure the Python
implementation supports pickling.
(Aside: why can't closures be pickled?)
But generalising this to all possibly mismatches between a C class
implementation and a Python function implementation doesn't necessarily
follow. Raymond's general point about simplicity versus feature creep
still stands, even if in this case adding pickling is useful.
 If I'm wrong about this, and these features are supported, then
Emanuel has found a hole in the functools test suite and a weakness in
our testing: it's too hard to ensure that *both* the Python and C code
More information about the Python-Dev