On 29 April 2017 at 09:51, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > typing.NamedTuple was already mentioned in this discussion, I just would > like to add few comments: > > 1. I think that changing Python syntax to support declarative classes is not > a realistic option in nearby future. > In contrast, there is an existing syntax change - variable annotations - > that can be actively experimented with. > Variable annotations are designed to play well with metaclass machinery, for > example, they will respect > __prepare__ method, if it injects __annotations__ as a custom mapping, etc. > > 2. Possible strategy for declarative classes could be developing independent > *composable* mixins/traits: > > @comparable > @pickleable > class MyClass: > x: int > y: int > > or > > class MyClass(Comparable, Pickleable): > x: int > y: int > > The problem with the second approach is that it can lead to metaclass > conflicts. A possible solution will > be to provide a standard metaclass for mixins in stdlib.
Between __init_subclass__, __set_name__, __annotations__, and guaranteed order preservation for class namespaces, Python 3.6 has provided some pretty powerful tools for folks to experiment with new approaches to declarative class definitions. One point worth considering is that given standard library implementations of the explicit class decorator forms (e.g in the `types` module, or in the modules defining the relevant protocols), it should be relatively straightforward to create mixin classes that use __init_subclass__ to implicitly apply the explicit decorators. The same doesn't hold the other way around - given a mixin, it's tricky to convert that to a class decorator form. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
