[Python-ideas] Statements vs Expressions... why?
cliff at develix.com
Thu Sep 11 06:34:51 CEST 2008
On Wed, 2008-09-10 at 18:30 -0700, Josiah Carlson wrote:
> On Wed, Sep 10, 2008 at 6:14 PM, Cliff Wells <cliff at develix.com> wrote:
> > On Wed, 2008-09-10 at 17:16 -0600, Adam Olsen wrote:
> >> They're the use-case you need to justify
> >> against the substantial changes you propose.
> > I guess I don't see it as substantial to people who don't wish to use it
> > (although it's quite substantial to people who do). Overall, I think
> > this is why I feel the change doesn't require a huge amount of
> > justification: you aren't *forced* to use it, but if you need it, it's
> > huge. It doesn't impose any significant stylistic change on people who
> > prefer the imperative style, but it opens vast doors for people wishing
> > to approach problems from a functional path.
> Once language syntax is added to, changed, etc., it's very difficult
> to remove those additions, changes, etc., even when the feature is
> rarely used, ugly, and generally a bad idea (see back-quotes `x` for
> repr(x) ). This may not seem like a big deal to you, because you want
> this feature, but for the rest of us who have little (arguably no) use
> for the feature, adding semantics to syntax, or adding syntax =
> additional mental overhead;
Again I assert the opposite: that Python is currently forced to explain
the arbitrary distinction that currently exists and that a significant
amount of extra syntax and language features exist to work around that
distinction. People may not clamor for the change but there's quite a
few newcomers to Python who must have the distinction explained to them.
> never mind the additional sections in the
> tutorial where we have to explain why this *particular* special case
> of a DSL was special enough to break the rules of explicit is better
> than implicit (why should a multi-line if statement implicitly return
> something in one place but not in another?)
I respect your work and knowledge of Python, but that's insufficient to
get me to respect a straw-man argument. I've not suggested that Python
add anything for any particular situation. I'm suggesting a change that
would make it more logically consistent, expressive, and help reduce the
language and syntax clutter it's been accruing at a steady pace. The
fact that it also helps in a rather broad range of problems is ancillary
and my particular use case was presented as an example, not as *the*
problem to be solved.
Also, I don't know where you got the idea that I suggest any expression
should return a value sometimes but not others. I'm suggesting they
*always* return values, but that you don't always need to worry about
them unless you plan to use the value in another expression. Kind of
how functions already work in Python.
> I know, "it's just one little change". I've made the argument myself.
> But that doesn't mean that my idea was a good idea (it wasn't), nor
> does it mean that your current idea is (I think everyone in this
> thread except you would agree that it's a bad idea).
Sure. Because everyone who might have agreed with me has already
migrated to Ruby or started a new language (Logix, Boo, et al). I just
happen to be lazy enough to entertain the thin hope that Python could be
fixed so I don't have to learn a new language or programming
> Before continuing on in defending your proposal here, I suggest you
> try comp.lang.python . If you can't get a dozen people to agree that
> it's a good idea, or if (like here) the only replies are negative (or
> even if the majority of them are), then I would suggest you drop it.
Actually I avoided c.l.py because I saw this list suggested as the
appropriate place for new or controversial ideas (and the list name
seemed to suggest the same).
The fact that lambda was so bitterly defended against GvR's strong
desire to remove it should be hint enough that a significant number of
Pythonistas are interested in functional and expression-oriented
In any case, I actually got the response I expected and ultimately I
expect the discussion here was probably far more enlightened than I
would expect on c.l.py.
It seems most Pythoneers work in particular domains where this isn't an
issue, are satisfied with the workarounds, or simply are unable to see
there's a vast world of elegant solutions beyond what imperative
languages can describe. Unfortunately this only confirms my (rather
reluctant) expectation that I'll be forced to move to a more expressive
language to satisfy my programming itches.
In any case, thanks for the feedback.
More information about the Python-ideas