[Python-ideas] Simpler Customization of Class Creation - PEP 487

Andrew Barnert abarnert at yahoo.com
Sat Feb 6 12:47:58 EST 2016


On Feb 6, 2016, at 03:02, Martin Teichmann <lkb.teichmann at gmail.com> wrote:
> 
> While Python 2 compatibility is not such a big deal anymore (this is
> 2016, and I figure 2015 really has been the
> year of Python 3), the problem is that this proposal is targetting
> authors of libraries, not just applications.
> Libraries are, for a good reason, very reluctant to drop backwards
> compatibility. So trying to convince them
> to do something which is not backwards portable won't fly. My idea is
> that libraries just use the PyPI
> implementation of this PEP, which will use the standard library
> implementation once it is existing.

OK, now this makes sense. The PyPI module does something like this:

    try:
        from types import Meta
    except ImportError:
        pass

So, in 2.7 or 3.5, this has no effect, and you get the Meta defined in the module, but if 3.6 or 3.7 adds types.Meta, people using the PyPI module get the stdlib type, so they get the benefits of a shared metaclass. And if 3.7 or 3.8 replaces type with your metaclass, and just has types.Meta = type, the PyPI module now gets the builtin if possible, the stdlib type as a fallback, and the PyPI type as a double-fallback.

Assuming that understanding was right, this does seem like the best solution to the problem--not perfect, but as good as anything could possibly be.

One thing on the six idea: if some libraries get the type from six and others from your module, they'll have incompatible metaclasses for no good reason (when used on 3.5 and earlier). It seems like if this is going to end up in six, it should be in six as soon as possible, and direct use of the separate library should be strongly discouraged. 



More information about the Python-ideas mailing list