Magic Module Methods?

[Tim Peters]

[Magnus Lie Hetland]
> OK - bad example (and terse explanation). The situation was this: I was
> using a module as a config file, and at the same time as an object
> containing defaults at some other point in the program (available for
> users of the library).

So you were pointing a gun at your foot, and just deciding which toe to blow
off <wink>.  Why not write a little ConfigFile class and supply methods and
attributes in an obvious way?  Better, exploit the ConfigParser module in
the std library, and get a powerful config file facility for free.

> Therefore, the defaults should be accessible from the module,
> but the people writing the config file might not want to set absolutely
> all the values...

IOW, a module is a poor implementation of what you want.  You ask why Python
doesn't add stuff to modules so they do what you want here directly.  I ask
why you don't use classes instead, which have always supported what you want
here.

> I could of course do an update() on the module __dict__,
> and that might be clearer, but possibly not near-infinitely? ;)

Long ago Guido challenged c.l.py to just *try* writing Python without
abusing __dict__ (and the other __xxx__ implementation details).  It was
excellent advice then, and still is.  What would you do if Python didn't
allow playing any dynamic tricks with module namespaces?  Answering that
should lead to a cleaner solution.

> ...
> Well, I wasn't saying that modules should act like lists or integers or
> any other specific class of objects -- simply like objects in general.
> (Everything is supposed to be an object now, right?)

Everything has always been an object, but not everything is of the same
type, and different types support different operations.  Indeed, that's why
there *are* different types:  different behaviors for different intended
uses.  Complex numbers and strings also have attributes, but if you want to
define __getattr__ for one of those, same thing applies:  you'll have to
wait for 2.2 and subclass.  Supporting __getattr__ makes no sense for the
intended uses of the builtin strings and complexes.

Modules are intended to be used as the unit of separate compilation in
Python, and are intended to supply a stable, static, documented interface.
Since modules are intended to have a static (fixed) namespace after
initialization is complete, __getattr__ on modules doesn't make sense for
their intended uses either; that's why it isn't supported.

>> you-can-subclass-the-module-type-in-2.2-but-hoping-you-don't-ly
>>     y'rs  - tim

> Subclassing the module type wouldn't be of much help here, would it?

Using any flavor of module for this purpose seems wrong-headed to me, but if
you want a module-like object that supports getattr, you *can* build one in
2.2, and stuff it into sys.modules like any other module.  That wouldn't
seem like "a help" to me even if you persisted until it worked <wink>, but
you'll have to judge that for yourself.

> ...
> I still couldn't get the object-like behaviour directly from the
> module.

I think you mean class-instance-like behavior, and that's right if so:
class instances are intended to be used for class-instance-like behavior.
Everything in Python has object-like behavior (which doesn't amount to much
more than responding to id() and almost always str() and repr()).
Subclassing of builtin types in 2.2 *allows* to add bonzo behaviors to
builtin-like objects, but you have to add the ones you want one at a time.
There are some cool uses for this, but likely more bad ones.

> (And no, I probably won't subclass it anyway.)

Oh, live a little <wink>.

> I don't really see what's wrong with the idea (of magic functions in a
> module), but I'll accept "Tim doesn't like it" as a valid reason. :)

If only life were that easy.  "Tim doesn't approve of terrorism."  WHOA!
Unless I'm badly mistaken, the world is now a safer place <wink>.

cheers-from-the-anthrax-capital-of-the-world-ly y'rs  - tim