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

[Cliff Wells]

On Sun, 2008-09-14 at 20:26 -0700, Josiah Carlson wrote:
> 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.

I clearly read more into it than you intended.  My apologies.  

As for opinions on what Python should or shouldn't be, I'll stop having
opinions on it when you do (or probably sooner, since it won't matter to
me anyway).

> 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.

I didn't claim Breve proved anything.  I resort to it as an example
because it's handy for doing so (and because there are so few such
examples in Python).

> > 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.

If it did code generation, then it wouldn't be an internal DSL, it would
be an external DSL that happened to target the Python language (Cheetah)
or VM (Spitfire) as a runtime.  That's why I was so careful to mention
it several times.  

> > 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.  

I meant hypothetically ("could be argued").  In no way did I say that
someone here on this list had taken that stance (it hadn't even come
up).

> 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.

Yep, I didn't get it.  I'd assumed you were using __call__ (which would
seem a much simpler way to achieve the same thing).  Frankly this
example only cements my belief that this is overly complicated given the
problem to be solved.

> > 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.

Again I apologize.  But given how many times you did the exact same
thing to me here (and rather rudely at that) I think we can call it
even.

Anyway, I'm done.

Regards,
Cliff