Re: python newbie

On Sun, 04 Nov 2007 12:05:35 -0800, Paul Rubin wrote:

Bruno Desthuilliers <bdesth.quelquechose@xxxxxxxxxxxxxxxxxxx> writes:
from random import random
x = random()
y = random.choice((1,2,3)) # oops

from random import random, choice

x = random()
y = choice((1, 2, 3))

Really, a lot of these modules exist primarily to export a single class
or function, but have other classes or functions of secondary interest.
I'd like to be able to get to the primary function without needing to
use a qualifier, and be able to get to the secondary ones by using a
qualifier instead of having to import explicitly and clutter up the
importing module's name space like that. It just seems natural.

+1 on Paul's suggestion. It's a style thing: it is so much more elegant
and obvious than the alternatives.

A module is a single conceptual unit. It might very well have a rich
internal API, but many modules also have a single main function. It might
be a function or class with the same name as the module, or it might
literally be called "main". It might be designed to be called from the
shell, as a shell script, but it need not be.

A good clue that you're dealing with such a module is if you find
yourself usually calling the same object from the module, or if the
module has a main class or function with the same name as the module. The
module is, in effect, a single functional unit.

Possible candidates, in no particular order: StringIO, random, glob,
fnmatch, bisect, doctest, filecmp, ...

Note that they're not *quite* black boxes: at times it is useful to crack
that functional unit open to access the internals: the module's "not
main" functions. But *much of the time*, you should be able to use a
module as a black box, without ever caring about anything inside it:

import module
module(data) # do something with the module


The model I have in mind is that of shell-scripting languages, like Bash.
For the purpose of syntax, Bash doesn't distinguish between built-in
commands and other Bash scripts, but Python does. When you call a script
(module) in Bash, you don't need to qualify it to use it:

ls > myscript --options

instead of ls > myscript.myscript --options

If you think of modules (at least sometimes) as being the equivalent of
scripts, only richer and more powerful, then the ugliness of the current
behaviour is simply obvious.

This model of modules as scripts isn't appropriate for all modules, but
it is backwards compatible with the current way of doing things (except
for code that assumes that calling a module will raise an exception). For
those modules that don't have a single main function, simply don't define
__call__.



The "natural" way to treat a module as a functional whole *and* still be
able to crack it open to access the parts currently is some variation of:

from module import main
import module

That's inelegant for at least six reasons:

(1) There's no standard interface for module authors. Should the main
function of the module be called "main" or "__main__" or "__call__" or
something derived from the name of the module? The same as the module
name?

(2) Namespace pollution. There are two names added to the namespace just
to deal with a single conceptual unit.

(3) The conceptual link between the module and it's main function is now
broken. There is no longer any obvious connection between main() and the
module. The two are meant to be joined at the hip, and we're treating
them as independent things.

(4) What happens if you have two modules you want to treat this way, both
with a main function with the same name? You shouldn't have to say "from
module import main as main2" or similar.

(5) You can't use the module as a black box. You *must* care about the
internals, if only to find out the name of the main function you wish to
import.

(6) The obvious idiom uses two imports (although there is an almost as
obvious idiom only using one). Python caches imports, and the second is
presumably much faster than the first, but it would be nice to avoid the
redundant import.


As far as I know, all it would take to allow modules to be callable would
be a single change to the module type, the equivalent of:

def __call__(self, *args, **kwargs):
try:
# Special methods are retrieved from the class, not
# from the instance, so we need to see if the
# instance has the right method.
callable = self.__dict__['__call__']
except KeyError:
return None # or raise an exception?
return callable(self, *args, **kwargs)



--
Steven
.

Relevant Pages

  • cron messes up time format
    ... I've done this by using cron to run bash ... scripts which run python scripts which gather the data. ... since I think it's the difference between the bash shell I'm ...
    (comp.unix.bsd.freebsd.misc)
  • Re: conversion of csh scripts to bash
    ... > I recognize that bash is the superior shell, but like many people, I was ... > first exposed to csh 12 years ago because that's what everyone in my ... Note that shell programming sucks in general, ... I would certainly not write bash specific scripts, but instead, ...
    (comp.unix.shell)
  • Re: [ Attn: Randy ] Ad-hoc Parsing?
    ... One of the biggest advantages of Unix-like shells ... > flexible as the Unix scripts using the more powerful ... about bash, which being a fully-capable shell, can launch programs ... > execute the com program itself). ...
    (alt.lang.asm)
  • Re: Most directories locked read-only: unlocked!
    ... The only difference is that if bash is called as "sh" it mimics the behavior of a regular bourne shell. ... scripts bash can be used but the scripts application may be confused if it is called bash rather than sh. ... and then copy it over to linux. ... Apparently the Debian installer always adds this option to the fstab mount line for the root directory, and no one on the list could enlighten me as to what purpose it serves by being there, In any event, any error in mounting the root directory effectively disables the computer, with consequent difficulty in getting it working it again as I have experienced. ...
    (Debian-User)
  • Re: subversion on boot
    ... We have a very good guide about the internals of the rc.d scripts now, ... which you can read online at: ... A sample `svnserve' script could be as simple as: ...
    (freebsd-questions)