RetroSearch Browse

Fri Jun 24 18:17:01 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-June/145408.html

On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Honestly though, I'm not sure this additional user-visible complexity
> is worth it - "The default type metaclass has this new behaviour" is a
> lot easier to document and explain than "We added a new opt-in
> alternate metaclass that you can use if you want, and in the next
> version that will just become an alias for the builtin types again".
> We'd also end up being stuck with types.Type and types.Object as
> aliases for the type and object builtins forever (with the associated
> "How does 'class name:' or 'class name(object)' differ from 'class
> name(types.Object)'?" question and "It doesn't, unless you're using
> Python 3.6" answer for folks learning the language for the first
> time).
>
> If we decide __init_subclass__ and __set_owner__ are good ideas, let's
> just implement them, with a backport available on PyPI for folks that
> want to use them on earlier versions, including in Python 2/3
> compatible code.

+1

Could you clarify the value of the staged approach over jumping
straight to changing builtins.type?

-eric

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-June/145408.html below:

[Python-Dev] PEP 487: Simpler customization of class creation