4 ms·

My understanding is that the python designers have intentionally made this sort of functionality challenging to use, under the assumption (which I agree with) t

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.

wybiral 10y ago
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.
- meddlepal 10y ago
  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.
- bthornbury 10y ago
  This is somewhat against the zen of python, but then again "Beautiful is better than ugly." :)
  - wybiral 10y ago
    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.
    - bthornbury 10y ago
      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.
madmax96 10y ago
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.
- fake-name 10y ago
  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?
  - bthornbury 10y ago
    > 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.

wybiral 10y ago

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.

meddlepal 10y ago
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.
bthornbury 10y ago
This is somewhat against the zen of python, but then again "Beautiful is better than ugly." :)
- wybiral 10y ago
  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.
  - bthornbury 10y ago
    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.

madmax96 10y ago

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.

fake-name 10y ago
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?
- bthornbury 10y ago
  > 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.