[Python-ideas] Statements vs Expressions... why?
cliff at develix.com
Wed Sep 10 20:43:00 CEST 2008
Something that has started to annoy me in the last couple of years is
the fact that most Python control statements cannot be used as
expressions. I feel this is a pretty deep limitation and personally I
don't feel it's well-justified.
As I understand it, the reason for the distinction mostly has to do with
the premise "flat is better than nested", which I can understand, but I
don't think carries enough weight anymore.
Specifically, I'd like to see things like "if" statements, "for" loops,
etc, become expressions. This would not preclude them from being used
as if they were statements (an expression can stand alone on a line of
Python code), but would add a lot of expressiveness to the language as
well as make Python more viable for creating DSLs.
Additionally, removing statements from Python would also allow the
language to be simplified. No need for a ternary "if" operator with
different semantics than a normal "if" statement, "for" loops would be
brought closer to generators in functionality, and the perceived
limitations of lambda would disappear, amongst other things. We'd gain
a lot of features found in languages like Lisp and Ruby as a side-effect
(i.e. anonymous code blocks).
Overall it seems this design decision is specifically geared toward
forcing programmers into an imperative style in order to enforce program
readability. In Python 1.5, this made a bit of sense, but as Python has
"matured" (or in my view, gotten over-complicated) this makes much less
sense. Many parts of Python's extensive syntax are explicit workarounds
to this design decision. So on the one hand we have the perceived
danger that programmers will write nested code and on the other we have
an ever-expanding syntax. I'd take the former any day.
I've not delved into the internals of the Python interpreter to check,
but I suspect that converting most statements to expressions would not
be very difficult (changing the grammar definition and generated
bytecode a small amount in most cases).
Any thoughts on this? I'm sure it's been brought up before, but I
haven't found any definitive discussions on why this rather arbitrary
design decision continues to hold in the face of a general migration
away from imperative languages (especially when it seems it could be
changed without much backwards-compatibility issues).
More information about the Python-ideas