On 28 April 2017 at 21:55, Tin Tvrtković <tinches...@gmail.com> wrote: > Third example: I work at a mobile games company. The backends are Python, > the games are written in other languages. The backends and the games share > data structures - requests, responses, the save game, game data. I want to > have a single source of truth for these structures, so I want to generate > classes/structs in other languages from the backend Python classes.
Some additional metaclass based prior art for declarative class definitions: - Django ORM models - SQL Alchemy ORM models - JSL template definitions (http://jsl.readthedocs.io/en/latest/tutorial.html) (I'm sure there's also plenty of prior art in Zope and Plone, but I'm not personally all that familiar with either of those) > All of these examples require declarative classes to do properly. Other > approaches are, I suppose, possible in some cases - like inspecting __init__ > and whatnot. But I claim the underlying issue is that we should be declaring > classes differently, both to enable these new, high-level use cases and > because declarative classes are much more readable and contain less > boilerplate than what we have now, and this is (for me) Python is about. Exactly. I don't think we should change anything about the basic semantics of class or method definitions (since they're part of what makes it possible to reason about Python as an inherently procedural language), but I *do* think we should be considering the kinds of helpers we can provide as class decorators to take the boilerplate and tedium out of defining well-behaved classes. 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/
