![](https://secure.gravatar.com/avatar/337fb6df3cf57f5b7f47e573f1558cfa.jpg?s=120&d=mm&r=g)
I think in any case Type is a bad name, since we now have typing.Type (and it is completely different) I could imagine a lot of confusion. -- Ivan On 25 June 2016 at 00:17, Eric Snow <ericsnowcurrently@gmail.com> wrote:
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