On Tuesday 30 June 2009 22:16:41 John Eikenberry wrote:
> What is wrong with simply importing the most common things in
> Kamaelia/__init__.py so they'd be available to import off the top level
> package? Why all the autoload() magic in the original? It was the latter
> that I was mainly disagreeing with, not the simplified importing.
I realised that the issue was with the magic, rather than the overall effect.
With regard to putting the most common things in Kamaelia/__init__.py, you
*could* do that, but I think you can only do that properly in certain
restricted usecases.
Then you end up with a static list, and actually risk making things more
confusing because you end up wondering why some things are there, but not
this other thing.
For example, if I give you a choice of 10 appetisers, 10 main courses, and 10
desserts, I can guarantee that some things will be more popular than most,
but I can also guarantee that many people will choose outliers from the norm
for at least one of those courses. A pipeline with 3 components is the same.
So how do you choose what's most popular? You can't realistically.
However, if the alternative is considered just too whacky to even think of
accepting, then this maxim seems appropriate: "In the face of ambiguity,
refuse the temptation to guess."
On Tuesday 30 June 2009 21:38:30 Gloria W wrote:
> > Essentially I'm wondering how to best implement the equivalent of
> > $PATH for KamaeliaComponents.
> >
>
> I think this is perfectly satisfied by virtualenv, which generates a
> setup.pth file.
> This path file can be checked in and used as part of a project.
>
> easy_install modifies the setup.pth file in /your/python/site-packages,
> while virtualenv creates local setup.pth files which can extend the
> global file.
>
> A "make install" command could roll it out into a "work" directory where
> Kamaelia tests are placed.
>
> This isn't considered magic, because it is a well-known and used
> convention for isolated test environments.
I _think_ you're mis-interpretting what I mean by $PATH - I could be wrong.
Whilst Kamaelia isn't the shell, there are lots of similarities, and for some
of them it appears that implementing some more may be useful. The unix path
is a good example.
Taking a silly shell example. Suppose I want to add all the sizes of video up
using the shell I can do this:
/media/disk/Europython09/20090701> echo `ls -l |grep mp4|awk '{print $5}'`|
sed -e "s/ /+/g"|bc
19267846144
I don't have to do this:
ECHO=echo #builtin
LS=/bin/ls
GREP=/usr/bin/grep
AWK=/usr/bin/awk
SED=/usr/bin/sed
BC=/usr/bin/bc
$ECHO `$LS -l |$GREP mp4|$AWK '{print $5}'`|$SED -e "s/ /+/g"|$BC
Now of course, I *can* do this, and indeed, many sysadmins will agree that
doing this can be a good idea - especially if the definitions are in a
separate file allowing profiles.
This latter version is however directly akin to this:
from Kamaelia.Util.Backplane import Backplane, PublishTo, SubscribeTo
from Kamaelia.Chassis.Pipeline import Pipeline
from Kamaelia.Chassis.ServerCore import ServerCore
from Kamaelia.File.Append import Append
from Kamaelia.Util.PureTransformer import PureTransformer
And is inherently a useful thing for all the reasons stated. But suppose we
wanted it to run just like the unix command line. We'd need to provide the
equivalent of this:
~> echo $PATH
/opt/kde3/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin
Where rather than finding programs, or finding python modules (.pth files) I'd
prefer something that can look for individual components.
Now that could look like this:
from Kamaelia import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
Or it could look like this:
Backplane, PublishTo, SubscribeTo, Pipeline, ServerCore, Append,
PureTransformer = Kamaelia.Find("Backplane", "PublishTo", "SubscribeTo",
"Pipeline", "ServerCore", "Append", "PureTransformer")
or this:
Backplane, PublishTo, SubscribeTo, Pipeline, ServerCore, Append,
PureTransformer = Kamaelia.Find("Backplane", "PublishTo", "SubscribeTo",
"Pipeline", "ServerCore", "Append", "PureTransformer")
But my preference is something like:
from < thing > import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
NB, this kind of thinking implies that these should be possible too:
>>> Kamaelia.Which("UnixProcess")
Kamaelia.File.UnixProcess.UnixProcess
>>> Kamaelia.Man("UnixProcess")
===========
UnixProcess
===========
Launch another unix process and communicate with it via its standard input
and output, by using the "inbox" and "outbox" of this component.
Example Usage
-------------
Which you can nearly do:
>>> import Kamaelia.File.UnixProcess
>>> Kamaelia.File.UnixProcess
<module 'Kamaelia.File.UnixProcess' from
'/usr/local/lib/python2.5/site-packages/Kamaelia/File/UnixProcess.pyc'>
>>> print Kamaelia.File.UnixProcess.__doc__
===========
UnixProcess
===========
Launch another unix process and communicate with it via its standard input
and output, by using the "inbox" and "outbox" of this component.
Example Usage
-------------
But there's been sufficient objections regarding this for me to go away and
rethink. Not least because part of the above example is slightly inconsistent
in usage.
It's potentially reasonable to consider these though:
from Kamaelia.Magic import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
from Kamaelia.Path import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
from Kamaelia.Repository import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
from Kamaelia.Components import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
from Kamaelia.Bin import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
from Kamaelia.SBin import Backplane, PublishTo, SubscribeTo, \
Pipeline, ServerCore, Append, PureTransformer
etc. But I'm not rushing into this.
Other issues raised elsewhere which were valid include this:
"wouldn't this approach destroy any chance of autocomplete working with an IDE
such as WingIDE? Of course, you could publish .pi files along with your
modules."
That said the same comment says this:
"That said, it looks like a neat idea. Lazy loading is always a good idea if
you're looking at loading dozens of related, but possibly not used, modules."
Which is precisely the scenario here. So I'm unlikely to merge the original
idea, as desribed, but not going to completely forget about it - since I
think there is something there which is worth teasing out. Afterall,
computers should make developers lives easier :)
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 kamaelia@googlegroups.com
To unsubscribe from this group, send email to
kamaelia+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---
