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

[Josiah Carlson]

On Sun, Sep 14, 2008 at 1:47 PM, Cliff Wells <cliff at develix.com> wrote:
> On Sun, 2008-09-14 at 13:02 -0700, Cliff Wells wrote:
>> On Sun, 2008-09-14 at 12:36 -0700, Josiah Carlson wrote:
>>
>> > Agreed.  For all of the semantic and syntactic gymnastics and
>> > discussion about how statements -> expressions would make Python a
>> > better language, all I can conclude from the above is "I'm glad Python
>> > doesn't do that."

> Using Breve as an example again: by your reasoning, the mere existence
> of Breve should be reason enough not to support OO in Python (or at the
> very least, magic methods).

Let me make it clear what I was expressing, because you have no idea.
I have personal opinions on what I like and dislike.  It became clear
to me early on that we disagree on language aesthetics.  All I was
expressing was that I'm glad that Python didn't look like what you
were writing.  If you've got a problem with my expressing of that,
that's fine, you already decided to move onto a different language.
But don't claim to know what I was saying or implying about Python as
a language and what it should or should not support.

The fact is, Breve is implemented using OO in Python.  Could it have
been done using a functional approach?  Sure, but then you would have
had to use multi-calling semantics, closures (which is OO in
disguise), or code copy/pasting.  Breve is not proof that Python
should or should not do something, and to claim otherwise (or believe
someone is claiming otherwise) is silly.

> Breve more or less a functional DSL that barely resembles Python but
> actually *is* Python (in fact, I've seen someone assert that Breve
> templates could not possibly be actual Python code).  Even you were
> initially convinced that I was doing code-generation.  Breve abuses

I knew that Breve was Python, but I thought it was doing something
smart by also doing transparent code generation (because there was
discussion about the "speed" of Breve) a'la Cheetah/Spitfire, because
I believed that you had worked more on the language than you actually
had.  I was wrong.  But that doesn't make Breve a good example of a
DSL, it makes it just another internal DSL using Python.  As you say
yourself, there are many.

> classes and magic methods (albeit in an entirely legal way) to create
> the illusion of a declarative DSL.  Clearly I think this ability is a
> good thing, but it could also be argued that what I've done is
> inscrutable and this type of code should not be allowed in Python.

Whom has it been argued by?  I think the only argument is against
adding syntax to make Python purely functional.  Using Python syntax
and semantics to write interesting features is part of what makes
Python great.  I've created SQL code generators using __getattr__ and
the comparison operators plus __and__ and __or__ for where clauses.
And you know what?  They looked a million times better than embedding
SQL in the code or using stored procedures.  None of them would be
possible without __magic__ methods.

> In fact, your own example of mimicking a dispatch "table" with a class
> is arguably object abuse.  Personally I don't think it's a bad solution
> (especially in the absence of a better way), but you've basically mapped
> what is logically a functional problem onto an object.  My point is that

You didn't even understand my example.  I wasn't mapping it into an
object, I was using the underlying class creation semantics
(specifically metaclasses) to generate a dispatch dictionary.  I'll be
more clear this time.

def dispatcher(name, bases, dict):
    import __builtin__
    dispatch = {}
    for name, fcn in dict.iteritems():
        if callable(name):
            if '_' in name:
                typnam, value in name.split('_')[:2]
                typ = getattr(__builtin__, typnam, None)
                if not typ:
                    continue
                dispatch[typ(value)] = fcn
            else:
                dispatch[name] = fcn
    return dispatch

If you set the __metaclass__ of a class to the above function, you
don't get a class, you get a dictionary.  A dispatch dictionary in
particular.  One that works with arbitrary types (the above only works
for builtin types or those that have been inserted into the builtin
module).  This method shouldn't be new to anyone.  I've been doing it
since before metaclasses (using functions and locals() instead,
because I liked the look better), and I've seen it used in various
codebases.  You can do similar things to build properties (I have),
and any one of a number of other really useful things.


> just because something *can* be abused, it isn't reason to throw the
> baby out with the proverbial bath water.   The more general a tool is,
> the more able it is to be used incorrectly (as anyone who's pried a lid
> off a can of paint with a screwdriver can attest).

Ahh, but the example that I was complaining about *wasn't supposed to
be an abuse*, it was supposed to be an example of "how can we make
this really simple Python code work with an expression-only version of
Python?"  That the *simple* Python became so complicated and ugly in
the translation to a non-existing expression-only version of Python is
unfortunate.  But again, I'm glad Python doesn't look like that.

Again, don't try to tell me what my reasoning is, I was expressing an
opinion on aesthetics.

 - Josiah