I think you would be very pleased with and interested in macropy.
Changing Python lambda syntax at runtime
11–20 of 25 posts
Re: Changing Python lambda syntax at runtime
#12Earlier quoted context omitted.
My understanding is that the python designers have intentionally made this sort of functionality challenging to use, under the assumption (which I agree with) that that sort of dynamic metaprogramming can result in code that can be very challenging or even nearly impossible to follow or understand. While lisp-y dynamism can let you do really cool things in very little code, it also lets you do completely incomprehens…
Agreed. Python has also pushed the mantra: "There should be one-- and preferably only one --obvious way to do it". Don't get me wrong, I love lisp, but it gives you the power to essentially create your own domain-specific language. A power that comes with both positive and negative side effects depending on the situation.
This is somewhat against the zen of python, but then again "Beautiful is better than ugly." :)
Re: Changing Python lambda syntax at runtime
#13I think you would be very pleased with and interested in macropy. https://github.com/lihaoyi/macropy
Yeah this is awesome. Using an AST is certainly much better than a regex for rewriting the code, and it looks like this has the usability thought out.
Thanks for the link.
Re: Changing Python lambda syntax at runtime
#14I wonder why an article like this is not in a blog or medium or in same place made for articles instead in a source code repo.
Was
Re: Changing Python lambda syntax at runtime
#15Python users are essentially discovering what Lispers have known all along - code is data. Once you fully comprehend that idea, you'll never be bothered by Lisp's odd syntax because of the freedom in expressibility it gives you. There are some fantastic Python hackers out there (some who know Lisp, others who don't) and this is a logical step in the progression of any developer. Eventually, they'll rediscover continu…
My understanding is that the python designers have intentionally made this sort of functionality challenging to use, under the assumption (which I agree with) that that sort of dynamic metaprogramming can result in code that can be very challenging or even nearly impossible to follow or understand. While lisp-y dynamism can let you do really cool things in very little code, it also lets you do completely incomprehens…
Agreed that it _can_ make code challenging to understand.
However, the engineer in me thinks that this is not a linguistic deficit, but rather illustrates poor judgement and taste on the part of the implementors. The litmus test of 'can this be expressed as a function?' will usually suffice for determining whether or not macros are being abused. Under this rule, debugging macros is no harder than debugging "normal" code.
Of course, people will disagree with me regarding poor taste, offering something that boils down to "if everyone using a tool is doing something poorly, then surely the tool is to blame." The problem is (1) that obviously isn't true as it boils down to a fundamental lack of skill and (2) in this case, there are numerous examples on the web of good use of macros that make code easier to understand. Tools themselves are casually inert and deserve no blame for the outcome of their uses as directed by the will of a separate entity, i.e. the programmer.
Judicious (read: professional) usage of macros will only ever make code easier to understand. If a macro is obfuscating meaning, then the macro has been used poorly. Luckily, a few books (LOL) have numerous examples of tastefully done macros. Lots of Clojure libraries have also shown what macros can do.
TL;DR: we're free to write good code, we're free to write bad code.
Re: Changing Python lambda syntax at runtime
#16Python users are essentially discovering what Lispers have known all along - code is data. Once you fully comprehend that idea, you'll never be bothered by Lisp's odd syntax because of the freedom in expressibility it gives you. There are some fantastic Python hackers out there (some who know Lisp, others who don't) and this is a logical step in the progression of any developer. Eventually, they'll rediscover continu…
I can't say I'm familiar with lisp, but I have had long conversations about it with a few friends who are enthusiastic about it's use. I thought of lisp after making this and thought it would be nice to build some python abstractions that can make this feel a little more usable. For the moment it does seem challenging, and I agree it will likely never be as simple as lisp.
Thanks for the reply!
This is really cool stuff, please post more if you decide to build some nice abstractions.
Nice work:)
Re: Changing Python lambda syntax at runtime
#17Python users are essentially discovering what Lispers have known all along - code is data. Once you fully comprehend that idea, you'll never be bothered by Lisp's odd syntax because of the freedom in expressibility it gives you. There are some fantastic Python hackers out there (some who know Lisp, others who don't) and this is a logical step in the progression of any developer. Eventually, they'll rediscover continu…
> But, as long as Python is not homoiconic, it will never be as simple to express these ideas as it is in Lisp
But it'll be way simpler to express literally every other day-to-day concept, whereas lisps will continue to be inexpressive, syntaxless, paren-soup.
Re: Changing Python lambda syntax at runtime
#18Python users are essentially discovering what Lispers have known all along - code is data. Once you fully comprehend that idea, you'll never be bothered by Lisp's odd syntax because of the freedom in expressibility it gives you. There are some fantastic Python hackers out there (some who know Lisp, others who don't) and this is a logical step in the progression of any developer. Eventually, they'll rediscover continu…
> But, as long as Python is not homoiconic, it will never be as simple to express these ideas as it is in Lisp But it'll be way simpler to express literally every other day-to-day concept, whereas lisps will continue to be inexpressive, syntaxless, paren-soup.
>But it'll be way simpler to express literally every other day-to-day concept, whereas lisps will continue to be inexpressive, syntaxless, paren-soup.
Of course not. You can literally implement any syntax in Lisp using macros.
Re: Changing Python lambda syntax at runtime
#19Earlier quoted context omitted.
Agreed. Python has also pushed the mantra: "There should be one-- and preferably only one --obvious way to do it". Don't get me wrong, I love lisp, but it gives you the power to essentially create your own domain-specific language. A power that comes with both positive and negative side effects depending on the situation.
This is somewhat against the zen of python, but then again "Beautiful is better than ugly." :)
It's a neat concept. I also agree that the lambda statement in Python is ugly, but actually using this in a Python project feels wrong.
Not that you couldn't call it a "transpiler" and consider it a new dialect of Python... Hey, the Javascript community gets away with it, why not Python?
Also, while I can't think of a normal use case, it is possible that someone intended to use (a, b, c) > (x, y, z) as a tuple comparison. ">>" or something might be safer.
Re: Changing Python lambda syntax at runtime
#20Python users are essentially discovering what Lispers have known all along - code is data. Once you fully comprehend that idea, you'll never be bothered by Lisp's odd syntax because of the freedom in expressibility it gives you. There are some fantastic Python hackers out there (some who know Lisp, others who don't) and this is a logical step in the progression of any developer. Eventually, they'll rediscover continu…
> Eventually, they'll rediscover continuations too.