Suggest design to accomodate non-unix platforms ?

Dan Stromberg drsalists at gmail.com
Fri Apr 20 13:44:58 EDT 2012


On Thu, Apr 19, 2012 at 5:14 PM, Chris Angelico <rosuav at gmail.com> wrote:

> The question then is whether to choose or auto-detect. Attempting to
> auto-detect could be quite inefficient; imagine if you have to call on
> ssh every couple of seconds, and something in $PATH is on a slow
> network share (or on a floppy drive, if you still have one of those).
> Yes, it's a poor choice of executable path, but it's perfectly legal,
> and the detection could get pathologically expensive. At very least,
> consider caching the result.
>
The wrapper class for autodetecting could cache locations to speed things
up.  bash does this normally (hence the "rehash" command), but probably not
across distinct shell processes.

I'm not a big fan of hardcoding paths; they have a way of changing.  I
prefer $PATH, or $PATH search that caches.

> That way when Haiku takes the world by storm, your porting effort should
> be
> > smaller.  ^_^  (Or something.  I really, really hope that Windows, OS/X
> and
> > Linux won't be the only major OS's for all time)
>
> Heh. Point. But the detection technique does depend on 'ssh' being the
> secure shell client and accepting parameters exactly like you're
> looking for - imagine if the Haiku (or whatever) ssh client takes
> slightly different params. How do you handle that with autodetection?
>
True, that gets more complicated.

For commands that look faintly similar but aren't really very similar,
you'd probably have a less-generic wrapper class that gets a usage message
from the ssh binary or something.  The generic one is just for the simple
case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20120420/db3fef2b/attachment-0001.html>


More information about the Python-list mailing list