module importing and variable syntax

[Alex Martelli]

"Jeff Davis" <jdavis at dynworks.com> wrote in message
news:3AADF3DC.1030003 at dynworks.com...
> I was previously a perl user, but now I am taking an interest in python.
> I am used to common perl methods such as using "variable variables"
> where the accessed variable depends on the situation (perl: "print
> ${$x};").

Isn't this style of ``soft'' referencing deprecated as dangerous
and unadvisable in Perl itself?

> Module importing doesn't take a string argument, but just a "bare word"
> (in perl terms). This means I have to know the name of the file in
> advance, and it needs to be in the right directory, or I need to use
eval().

Or, as other have suggested, __import__.  Also note that if the
module HAS already been imported, the module-object can also be
found at sys.modules[name] where name is a string that names
the module.


> What I am trying to do is have an arbitrary string with an arbitrary
> type (type with respect to my program, not python) access the function
> associated with the string in the module associated with the type.
>
> For example: someone writes an extension to my program creating a new
> object of name "O". Then some other part of the program (i.e. another
> extended module) tries to square an instance of that object, like:
> o = O()
> o.square()
>
> However, my program is completely unaware of either "O" or "square"
> until someone writes the module(s) and registers them with the program
> (not writing to the main program's source).
>
> It seems like I could get away with it if I used a lot of eval()
> statements, but talk about unreadable code (especially since you have to
> concatenate the variables in python to form a string)!

The "other extended module" can perfectly well import module O,
access its O attribute (a class, calling which creates an instance
thereof), and access (and call) the instance attribute called
'square', all on its own, without bothering "your program" -- if
I understand what you're saying.

If the call must happen in your main program, it need not be the
case that your main code has to be aware of anything -- it may
be passed the appropriate *objects*, rather than strings it's
supposed to use to fetch the objects.  Module-object, instance
object, bound-method object o.square -- whatever.  As I don't
exactly understand what you're doing, I can't tell whether this
is the appropriate route, but it often is -- people coming from
other programming languages often think in terms of passing
strings around, where in Python they might be better off passing
appropriate objects instead.


> I think I am having problems understanding the way python works in this
> regrard, which is why this question was probably way more complex than
> it needed to be.

Everything's object-centered; strings (names, variables, etc) are
basically 'tags' for the objects -- names (keys) whose corresponding
value is a reference to the object in some appropriate dictionary
('hash' for a Perlist).  Handy for human consumption, but programs
may have an easier time handly the objects directly.


> I would really appreciate some clarification. I like a lot about the way
> python is made and I think it has a lot of potential. Right now the
> concatenation of strings can be annoying compared to just (perl)
> '$string = "a $anotherstring be";', but for a lot of programs it is well
> worth the tradeoff.

Concatenation would be:
Perl:
    $string = "a " . $anotherstring . " be";
Python:
    astring = "a " + anotherstring + " be"
essentially equivalent.

What you're doing is variable-interpolation:

Perl:
    $string = "a $anotherstring be";
Python:
    astring = "a %(anotherstring)s be" % vars()

but note that in Python you can contextually pass
another dictionary to the %-operator (which does
the formatting, aka interpolation), AND use a
different format-specifier than %...s (which just
lets the object supply a string in whatever way
it wishes) much like in C's printf, if you wish.

Another equivalent approach:

    astring = "a %s be" % anotherstring

some find this preferable to having the names
mixed in with the format-string (mostly, ones
coming from C, I think:-).


Alex