instance as fake module (Re: why is there no class (static) methods in Python ?)

[Alex Martelli]

<James_Althoff at i2.com> wrote in message
news:mailman.992898207.28586.python-list at python.org...
    ...
> >As Alex Martelli has demonstrated a few times, you can substitute a
> >class instance that implements __setattr__ and __getattr__ in place of
> >the module object in sys.modules.
>
> How would such an approach work with "import", "from", "__import__", etc.?

Pretty well, thanks (it DOES give problems with 'reload', though,
if that is what you mean by 'etc':-).  Why not give it a try -- it
*IS* as simple as a crystal-clear spring, after all.

Here's a toy example:

:: fake.py
class _fake:
    __all__ = []
    def __getattr__(self, name):
        if name.startswith('__'): raise AttributeError, name
        else: return 'fake_'+name
import sys
sys.modules[__name__] = _fake()
:: end of fake.py

D:\py21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.4 -- Copyright 2001, Chris Gonnerman
>>> import fake
>>> fake.pop
'fake_pop'
>>> fake.plap
'fake_plap'
>>> from fake import foopi
>>> foopi
'fake_foopi'
>>> fakefake = __import__('fake')
>>> fakefake
<fake._fake instance at 007F8AFC>
>>> fakefake.ploppy
'fake_ploppy'
>>> fakefake is fake
1
>>>


> Is it really viable to try to create a class whose instances "fake" module
> objects?

Sure!  It's not just viable, it's EASY -- as long as client code
does no type-tests, of course, just as for any other application
of Python's signature-based polymorphism.  (The "Protocol
Adaptation" PEP is my personal big hope for a really powerful
way to wean people who write client-code off doing rigid
type-tests, which break all of the niftiest polymorphic tricks:-).

> And use this as the standard idiom for modules?

I'll pass on this one.  I suspect that by-far-MOST modules have
no need for __getattr__ and __setattr__, so I don't really see
why having a module replace its entry in sys.modules would ever
become "THE standard idiom".  But when I *DO* need a "module
__getattr__" etc, it seems to work pretty well today.


I'll pass on metaclasses, "true class methods", etc, too -- it
does not appear to me that the instance-as-a-fake-module idea
gives anywhere near ALL the power that such deep concepts might
yield.  But I haven't done nearly enough Smalltalking to feel
the need for such specific packaging-of-power deep in my bones.

Specifically, my personal gut feeling is that classes are nice
but vastly overrated in most OO literature, and other tools
and mechanisms may be preferable for several tasks -- so, by
instinct rather than by reason, I feel suspicious of attempts
to load yet more power and functionality on classes' backs and
sympathetic to ideas of "off-loading" tasks now entrusted to
classes to other simpler entities (e.g., "interfaces").

But that's guts, not reason - mostly an impression that comes
to me from comparing _previous_ attempts to "do it all with
classes" (e.g. the class==interface identification in C++
or Eiffel, the class==namespace in old C++ versions, &c) with
ones to separate concepts (the class/interface split in Java,
the class/namespace split in modern C++).  It may well be that
my instincts are operating on inappropriate foundations when
it comes to judging specific class-related ideas in the
specific context of Python's future developments.


Alex