On Sunday 11 October 2009 23:32:42 [email protected] wrote:
> On Sun, Oct 11, 2009 at 8:09 AM, Michael Sparks - [email protected] wrote:
> > No positive responses.
> >
> > Probably not worth the effort in to clean up and merge this in that
> > case.
>
> The intrawebs are slow don't you know. ;)
Also a good reason not to rush :-)
> > However, this looked like one step too far towards voodoo for Steve &
> > IIRC John agreed. In retrospect, I agree, though it could be a
> > convenient shortcut.
>
> <grin> Thanks for remembering. My brain is slow when coming back to a
> project I haven't worked with in 6 months. And decorators that take
> parameters tend to be so much harder for me to reacquaint myself with.
It was a good argument/rarionale. It's also an easy one to accept, so that's
why I accepted it :-)
> I do really like the ease of construction that you're shooting for
> with these decorators. I would probably use them too for very simple
> unix shell style transformation components.
As you might expect, I'm not 100% convinced at this stage. (If someone else is
though, they could always refine the code further) The difference though is 4
months ago I couldn't even see how to go about writing these decorators (well
the TransformGenComponent one at least).
> Most of the kamaelia
> components I've written have been more involved though.
Likewise. Not all, but many.
> I haven't
> personally yet needed a utility where I wanted to do some simple
> composition functions (tail, grep, print, etc) AND thought that I
> should use a concurrency system like kamaelia instead of a plain
> python script. I'm sure others have though.
I can see precisely where you're coming from with this. I'll often write a
shell script where a shell script will suffice, and if I need more, then I'l
write a python program. If it turns out to be useful, I'll probably
componentise that program.
This is potentially a halfway house. I'm not sure how useful a one at present.
> > In this case concept comes first, followed by an implementation. Point is
> > taken though :-) Suggestions for better names welcome. (As noted before)
>
> Anyway, I do like the ease of use.
That's useful to know.
> And I hate to be another person to
> harp on the names.
Well, I did ask for better names. :-)
> Honestly though, it's only easier for me if when I
> come back after 6 months, it's immediately obvious what's going on in
> the hidden decorator functionality. Comprehending what _my_ function
> did and holding in my head the code from somewhere else about what
> your decorator is doing is just too much for me dull brain. On the
> otherhand, if the name of the decorator is extremely clear, I don't
> have to lookup the decorator code as I just take it on faith that it
> does what it's name says. Some examples would be like:
> @run_in_transaction
> @retry_on_exception(max_tries=3)
> @wrap_with_context_manager
>
> So, that said, I'd personally +1 your sketch decorators if they could
> be given names that were not "what they are" but instead were "what
> they do". Perhaps:
> @TransformerGenComponent -> @kComponent_from_generator
> @blockingProducer -> @kComponent_from_blocking_generator
>
> I really prefer the explicit nature of telling me what's going on.
Interesting. I've often noticed a certain terseness in python code, sometimes
to the point of obscurity, whereas I tend to favour more descriptive names.
In this case I hadn't thought of the idea of describing the generators in
terms of "what they do", because the most common decorators I use are
@classmethod, @staticmethod - and similar - things that describe what the
thing is, rather than what it's doing. (Though the other canonical decorator
is "memoise", which of course is saying what it's doing)
Interesting thought.
> I can remember what "TransformerGenComponent" means no problem while I'm
> coding. When I come back to the project in April though, I'm going to
> have to lookup the docs for that on what it does and how it does it
> before I can even read what my code is doing with it.
Yep. That's my biggest concern with this sort of thing. Kamaelia is designed
after all with maintainers in mind rather than initial development (It's
harder to debug someone else's code than your own IMO). These two
aims can support each other, but equally can conflict.
In this case, my suspicion is that a decorator based component is a crutch -
something that helps someone get started. (Crutch in a good sense rather than
bad though)
Much like a WSGI systems can start off something like this:
def EnvironDumper(self, environ, start_response):
start_response('200 OK',[('Content-type','text/html')])
yield '<html><body><h1> WSGI Environment</h1><ul>'
for k in environ:
yield "<li><b> %s</b> : %s</li>" % (str(k), repr(environ[k]))
yield '</ul></body></html>'
But can soon have it's signature change to become more complex ala:
class JSON_Interceptor(object):
def __init__(self, application):
self.application = application
def __call__(self, environ, start_response):
if environ["cgi.args"].get("__json__"):
import sys
json = environ["cgi.args"]["__json__"]
environ["cgi.args"]["__json__"] = cjson.decode(json)
R = self.application(environ, start_response)
for line in R:
yield line
This doesn't negate the utility of supporting something smaller & simpler
though.
> > /me goes off to focus on something else :-)
> >
> :( I think there is potential usefulness here.
I don't think going off and focussing elsewhere for a while is a bad thing. If
no-one has time to feedback "immediately", this isn't a problem. As someone
has decided to say offlist: """Most of us are probably too busy to read
someone else's code. All of us (I hope) have something else we *could* be
doing instead of reading code. """
If that's the case, I'd rather wait for considered feedback, and put an idea
that's intened to assist new developers on hold, and focus on solving more
immediate concerns.
It's in my nature though to keep thinking in the background about an idea, so
defocussing can be a good idea. (you stop looking at the details, and look at
the problem more holistically IMO)
(Incidentally, I wouldn't always hold back like this, but in this case,
holding back until someone has the time and inclination to look struck me as
useful. Or else it's my best guess :-)
> If you get it to
> where you you're satisfied enough with the semantics to use these, I
> think it would be equally important to back port them in to the
> Kamaelia code tree wherever possible.
This is an interesting thought, and a good point. Indeed, asking "where does
this idea simplify existing code for a new maintainer" would be a very
interesting question. After all it should be a positive change rather than
negative or neutral.
That said, making code clearer would be a good reason.
> That way 1) people reading
> through the example code would get used to seeing them used and 2)
> real world usage would help validate their design usefulness.
Very good points.
> Hopefully late feedback is worth something. :)
Very much appreciated, thank you.
Regards,
Michael.
--
http://yeoldeclue.com/blog
http://twitter.com/kamaelian
http://www.kamaelia.org/Home
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"kamaelia" 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/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---
