[Python-Dev] PEP 487: Simpler customization of class creation
Eric Snow
ericsnowcurrently at gmail.com
Fri Jun 24 18:17:01 EDT 2016
More information about the Python-Dev mailing list
Fri Jun 24 18:17:01 EDT 2016
- Previous message (by thread): [Python-Dev] PEP 487: Simpler customization of class creation
- Next message (by thread): [Python-Dev] PEP 487: Simpler customization of class creation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] PEP 487: Simpler customization of class creation
- Next message (by thread): [Python-Dev] PEP 487: Simpler customization of class creation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list