On 23/04/2006, at 14:58, Jeff Watkins wrote:

On 22 Apr, 2006, at 3:54 pm, jvanasco wrote:

The reason is that TurboGears is so Pythonic, probably too much so.

Frankly, this is exactly why I've stopped following core development. There seems to be a current of thinking around generic functions and pythonic-magic that just confuses me. Everyone sounds off about how generic functions make things incredibly powerful and flexible, yet none of the adherents seem to recognise that it make the code absolutely impenetrable.

Well, actually generic pythons aren't that pythonic AFAIK... I believe it's one of the many things Python borrowed from Lisp (http://tinyurl.com/jus6f)

I recently spent a half hour trying to understand the NEW expose operator before simply giving up. I'm loathe to speak ill of my fellow contributors (and I have no idea who's been working on this), but it simply wasn't important enough for me to understand it.                                                     

I'd ALWAYS rather type a little more and understand what's going on than type less and hope the magic happens.        

I don't see how generic functions can save you typing. It's quite the opposite really:

Non-generic function approach:

def do_something(obj):
if instance(obj, basestring):
do_something_with_string(obj)
if instance(obj, int):
do_something_with_int(obj)
else:
do_something_default(obj)

Generic-function approach:

@generic()
def do_something(obj):
"""Does something fancy with obj"""

@do_something.when("isinstance(obj, basestring)")
def do_something_with_string(obj)
....

@do_something.when("isinstance(obj, int)")
def do_something_with_int(obj)
....

@do_something.when(default)
def do_something_default(obj)
....

As you can see, the generic function approach makes you write even more. However, the biggest benefit, as I see it, is that these rules can be defined anywhere (read: external modules), which basically aids in manteinability because you don't need to touch the original module where the function is defined when you need to tweak it's behavior. Oh, I should also mention that there's a much smarter algorithm than me taking care of balancing the decision tree on the fly so it remains as efficient as possible.

Also I should note that you don't *need* to undersand how they work in order to *use* them. What can be easier to explain to users than: "To get the JSON representation of A do jsonify(A)"? Of course, to actually define new rules you have to study them a bit, but come on, I'm not that smart and I can make use of them given my limited experience.

You too make good use of this when you define rules in soprovider.py to jsonify TG_User, etc. How would you have liked to hack on a long list of "elifs" inside an external egg (TurboJSON) making sure it's always up to date, doesn't introduce dead branches and doesn't conflict with previous rules? Not to mention that "extenders" of your identity classes can write more specific rules, just below their subclasses, to jsonify them in a different manner...

I must admit that my first contact with generic functions has been through TG. And my first impression was the same: WTF!? But after studying them better, playing with them and losing some hair, I'm starting to *love* them and finding use cases for them in most of my code (I suspect I'm probably overexcited though, and maybe *abusing* them, like I was a kid with a new toy ;)

The bottom line is that I'm not a good judge here, I'm now biased and blinded by they're beauty, sorry but I cannot agree with you here... ;) The importance generic functions are getting in TG is a plus for me...

Alberto 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---

Reply via email to