Changing Python lambda syntax at runtime • Hacker News Board

Re: Changing Python lambda syntax at runtime

#21

Post by fake-name » Sun, Sep 11, 2016, 4:02 AM UTC

madmax96 wrote: post #15

fake-name wrote: post #4

Earlier 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 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" c…

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?

Re: Changing Python lambda syntax at runtime

#22

Post by cutler » Sun, Sep 11, 2016, 10:24 AM UTC

If you want Python without crippled lambdas just use Hy (http://hylang.org). Hy also liberates you from signigicant whitespace.

Re: Changing Python lambda syntax at runtime

#23

Post by bthornbury » Sun, Sep 11, 2016, 8:41 PM UTC

cutler wrote: post #22

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

Re: Changing Python lambda syntax at runtime

#24

Post by bthornbury » Sun, Sep 11, 2016, 8:46 PM UTC

wybiral wrote: post #19

bthornbury wrote: post #12

Earlier quoted context omitted.

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 compar…

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.

Re: Changing Python lambda syntax at runtime

#25

Post by bthornbury » Sun, Sep 11, 2016, 8:51 PM UTC

fake-name wrote: post #21

madmax96 wrote: post #15

Earlier quoted context omitted.

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" c…

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 h…

> 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.