Sergey Drannikov (guest) 05 Jul 2015 13:47
Nim?
Where are Python macros? / Discussion
Forum
» Hidden / Per page discussions
» Where are Python macros?
This is the discussion related to the wiki page Where are Python macros?.
Sergey Drannikov (guest) 05 Jul 2015 13:47
Good to know. I've heard good things about Nim. I should have a look… but there's still Haskell and Rust on my todo list :(
What would you even use macros for in Python? You can already define functions and classes anywhere, and do pretty much anything you want. C needs them because the language is so restrictive, but I can't think of anything similar in Python.
Specifically, I wanted to generate a group of functions, all with the same prototype, without having to repeat same list of arguments each time.
You can generate functions like that dynamically in Ruby. I have helper functions generated dynamically in: https://github.com/twohlix/database_cached_attribute/blob/master/lib/database_cached_attribute.rb#L62
so when I call
database_cached_attribute :bollocks
database_cached_attribute :silliness
my class ends up with nice to have functions like
invalidate_silliness, only_silliness_changed?, cache_silliness
invalide_bollocks, only_bollocks_changed?, cache_bollocks
etc…
You can do that sort of thing in Python too; it's all dynamic in the end. Even if you were willing to put up with the nastiness though, there could be other drawbacks. For example, if you use mypy to do typechecking, you can't typecheck the functions you're generating at runtime. But if macros had been part of the language, mypy could learn how to expand them.
I'll have to agree with the GP. In Python you simply load the module, insert your functions types and whatever there, and rewrite the name at the global scope.
That is, Python macros are written in Python (and sometimes they are even useful). It also supports goto and multiple inheritance.
I'd argue that Lisp is plenty of inspiration for people to not run away from macros. It's just that we already have a good set of macro oriented languages, so people aren't rushing to replace it.
Python has many great facilities for macros. At the lowest level code can be generated dynamically and integrated in to the running program via eval and exec.
In the std lib namedtuple which builds a class from a textual template and then calls exec to compile it. You can see the generated code by passing verbose=True in the construction function.
At at much higher level macropy gives you full syntactic macros like you would get in a Scheme or Lisp.
If that isn't enough, there is Hy language which is a full Lisp hosted on Python. Full Python semantics with Lisp syntax, including macros.
Perl hasn't got a "standard" preprocessor because it has got a better tool: filters.
A filter is a Perl module which reads the initial source code and produces the Perl code passed to the final Perl interpreter.
This allows everyone to create its own new syntax or DSL in Perl.
See: perldoc Filter::Simple , perldoc Filter::Util::Call
A big problem with languages that allow macros is that they make it very hard to write static analysis tools for them. Having macros also means that the syntax of the language isn't fixed, just look at all the trouble the C preprocessor can cause (#define BEGIN {) or how godawful (La)TeX is. There are real reasons why people have turned away from macros.
/forum/t-1269209/where-are-python-macros#post-
