Changing Python lambda syntax at runtime(github.com)
github.com
Changing Python lambda syntax at runtime
https://github.com/brthornbury/lambdazen/blob/master/HowItWorks.md
4 comments
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.
Thanks for the link.
If you want Python without crippled lambdas just use Hy (http://hylang.org). Hy also liberates you from signigicant whitespace.
Wow, that's a pretty neat project, going to take a deeper look
Python 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 continuations too. But, as long as Python is not homoiconic, it will never be as simple to express these ideas as it is in Lisp.
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 continuations too. But, as long as Python is not homoiconic, it will never be as simple to express these ideas as it is in Lisp.
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 incomprehensible things in very little code. Python has intentionally chosen to disallow the first to prevent the second.
While lisp-y dynamism can let you do really cool things in very little code, it also lets you do completely incomprehensible things in very little code. Python has intentionally chosen to disallow the first to prevent the second.
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.
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.
Which honestly if you want a block-style Lisp, basically you're asking for Ruby. And the differences between Ruby and Python IMO aren't that big.
Edit: Heh, just realized there is another article on the front page arguing this.
Edit: Heh, just realized there is another article on the front page arguing this.
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.
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.
I agree in it's current state it's more of a novelty than something intended for serious use. (Imagine debugging someone else's code with source rewriting 0_0) Especially with the discrepancy you pointed out with tuple comparison.
I think that it could get to a state where if the debugging was figured out, and the abstractions/usability became nicer that it could be have some serious use though. Mostly the intention with this was to get something working, that can be iterated on if it makes sense.
I think that it could get to a state where if the debugging was figured out, and the abstractions/usability became nicer that it could be have some serious use though. Mostly the intention with this was to get something working, that can be iterated on if it makes sense.
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.
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.
Sure you're "free" to write bad code, but the language can either assist or make it harder. Python is designed with the express purpose of making writing horrible code at lest a little bit harder to do.
I did not (and do not) claim that there are not cases where macros can result in more readable code. However, I don't think you can dispute that, on the whole, macros lead to generally less readable code.
The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?
I did not (and do not) claim that there are not cases where macros can result in more readable code. However, I don't think you can dispute that, on the whole, macros lead to generally less readable code.
The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?
> Python is designed with the express purpose of making writing horrible code at lest a little bit harder to do.
This will of course depend on your definition of "horrible code" but in general I don't agree with this. From the standpoint of horrible code being non-readable there exists many constructs in python that don't lend themselves to readable code despite being very useful and expressive. Not that an experienced practitioner cannot invent patterns to make these constructs as readable as possible (list comprehensions are top of mind here).
I think the key here is for the practitioner to invent the patterns that make constructs like macros usable. In the right contexts, they're incredibly powerful and can increase the productivity of an individual, and when used right even a whole team.
> The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?
I would counter that it's likely not a feature for beginners, rather than being a bad feature.
This will of course depend on your definition of "horrible code" but in general I don't agree with this. From the standpoint of horrible code being non-readable there exists many constructs in python that don't lend themselves to readable code despite being very useful and expressive. Not that an experienced practitioner cannot invent patterns to make these constructs as readable as possible (list comprehensions are top of mind here).
I think the key here is for the practitioner to invent the patterns that make constructs like macros usable. In the right contexts, they're incredibly powerful and can increase the productivity of an individual, and when used right even a whole team.
> The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?
I would counter that it's likely not a feature for beginners, rather than being a bad feature.
I breathe python but have a passing knowledge of Lisp (CL specifically). The one thing I've found is true is the deep extensibility of lisp means every dev is capable of rolling their own thing, thus, just the way things are done in lisp varies from hacker to hacker. Python on the other hand enshrines the idea of having "one way to do it" as part of its values. This is what makes Python pretty uniform across most devs from what I've seen. That seems opposite to the CL way in value and in practice.
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.
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:)
This is really cool stuff, please post more if you decide to build some nice abstractions.
Nice work:)
> Eventually, they'll rediscover continuations too.
Done https://github.com/yawaramin/lambdak
Done https://github.com/yawaramin/lambdak
> 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.
>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.
Of course not. You can literally implement any syntax in Lisp using macros.
I 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.
Why do you believe a blog is any more suitable than a GitHub repository? If anything I probably prefer the GH repo since it's less likely to be click bait designed to drive views to some guys blog for the purpose of self promotion BS.
Github seemed like an easy place to put the markdown.
I didn't see a real benefit to sticking it somewhere else, why do you think that is more desirable?
I didn't see a real benefit to sticking it somewhere else, why do you think that is more desirable?
Was
https://github.com/lihaoyi/macropy