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 <ericsnowcurren...@gmail.com> wrote: > On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan <ncogh...@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 >
_______________________________________________ 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/archive%40mail-archive.com
