On Sun, Sep 14, 2008 at 1:47 PM, Cliff Wells cliff@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