(original) (raw)

On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan <ncoghlan@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

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com