[Python-ideas] Statements vs Expressions... why?

Adam Olsen rhamph at gmail.com
Wed Sep 10 23:57:46 CEST 2008


On Wed, Sep 10, 2008 at 3:18 PM, Cliff Wells <cliff at develix.com> wrote:
> Further, I feel that this limitation forces programmers into using hacks
> and magic or overly spread-out code, which itself leads to readability
> concerns.  Having used Python for around a decade, I'm quite aware of
> the fact that you can happily write tons and tons of nice code with
> Python in its current state.  However, because of the direction of my
> work (developing a internal DSL in Python) I've suddenly become aware of
> this glass ceiling.  I'd bumped into it before back when I was doing a
> lot of GUI development, but blamed it on lambda rather than realizing
> that it wasn't lambda so much as what I am bringing up now.

Python is not intended for DSLs.  Really, don't do it.  Python is for
python code.  If you want another language, write your own parser.  I
hear lisp is simple to parse, and has no annoying statements to hold
you back!

Seriously though, there is an advantage to basing so much on
statements rather than expressions.  We're specialized for one
statement per line, which is the most common case, and it allowed us
to have extraneous semicolons, braces, or whatever.  Readability
benefits, style consistency benefits.

Now there are some use cases that suffer here, including the one you
just gave: defining a dispatch dict with the functions inline.  The
best I could do is define the dict first, then stick a decorator on
each function to register them.  That's still ugly though.  A creative
solution is needed, but none come to mind.

An example where this has happened before is the with-statement, which
is spectacularly successful IMO.  Now, you may notice it could have
been done in a library rather than core syntax if generic anonymous
blocks were allowed — so what?  The library is still part of the
language!  It's still something that has to be learned.  And the
syntax would be substantially uglier using a generic mechanism, rather
than the specialized with-statement syntax.


-- 
Adam Olsen, aka Rhamphoryncus



More information about the Python-ideas mailing list