Looks like a fun project on its own, with a lot of syntax tree hackery going on, but I see no real (pragmatic) use since many of the AST hacks and use cases presented are in my opinion completely unwarranted and can already be solved by the existing machinery (perhaps with quite heavy use of the metaclasses).
As an example, instead of hacking the AST via macros:
@case
Point(x, y): pass
one could just do a (this example implies, of course, that there is a CaseClassMeta somewhere attached to CaseClass):
class Point(CaseClass):
fields = 'x', 'y'
Not only this is nicer, you retain full control of the MRO on the metaclass level and can adjust its behaviour as needed and when needed.
Enums, complex enums and class body nesting examples -- can also be solved via metaclasses quite easily.
Quick lambdas example -- is somewhat close to "whatever" Python library, this is probably the one case which cannot be reproduced as is without AST hacks.
Yes, the use of macros is not always justified in the examples, because Python is quite expressive already.
However, the ability to have macros is orthogonal with the feature set of the language. What is interesting is the ability to inspect and modify a Python AST.
Of course, meta-programming is a way to integrate otherwise absent features of a language as-if they were built-in.
Python is sufficiently dynamic that most things can be done using existing facilities, like reflection and metaobjects (the @case example, as you mention).
But there is a difference between using those facilites at runtime and producing some code at macro-expansion time (this might be relevant for Cython, for example).
You can, for example, define a domain-specific language that is directly translated as Python, and not interpreted like an API-based representation would. You can even apply custom type checking for that DSL.
Or, you could analyze an existing python source code and produce a translation in another language without having to reimplement a parser (see the Python-to-Javascript example, or Common-Lisp's Parenscript).
And one could use complex, or quaternions to represent points in order to not have to reinvent the wheels of rotation/translation/computing area/projections/polar to cartesian ...
I think the class point is the proof OOP is not able to give a real use case for itself other than reimplementing the wheel poorly.
OOP has proven to be confusing the youngs and lazy. It makes people confused about abstraction and the concrete world (map and territory).
It is pedantic, and inefficient.
EDIT: But the code of this guy is still amazing, even if totally pushing in wrong directions sometimes: memoization is the worst caching strategy possible. On the other hand the PEG parser is brilliant, like most of the code.
As an example, instead of hacking the AST via macros:
one could just do a (this example implies, of course, that there is a CaseClassMeta somewhere attached to CaseClass): Not only this is nicer, you retain full control of the MRO on the metaclass level and can adjust its behaviour as needed and when needed.Enums, complex enums and class body nesting examples -- can also be solved via metaclasses quite easily.
Quick lambdas example -- is somewhat close to "whatever" Python library, this is probably the one case which cannot be reproduced as is without AST hacks.