2001 Enchancement Wishlist

[Thomas Wouters]

On Thu, Jan 04, 2001 at 11:10:10PM +0100, Alex Martelli wrote:
> "Thomas Wouters" <thomas at xs4all.net> writes:
> 
> > > A module object, in contrast, has no such flexibility.  It can of
> > > course have *attributes*, which, as they can be anything (in particular,
> > > they can be class-instances), are as flexible as can be -- but it
> > > cannot present any 'face' to client-code, except its own.
> >
> > Nor is it intended to. Nor should you ever *want* to. *That* is why I
> don't
> 
> Recapitulating: I said "it's a pity one can't do X".  You answered "but
> of course one can" (do X).  Now, in contrast, you say that one's not
> _intended_ to do X, and it's even a "forbidden desire" to harbor.  This
> is in total contradiction to your original rebuttal of my "you can't".

Not at all. *You* can do X. So can I. So can every programmer. Using Python.
But if you insist on only using a module namespace, for some odd reason. you
can't. 

> > understand your problem with me saying that it's perfectly possible to use
> > a module namespace to provide singletons.
> 
> I never said one cannot use a module namespace to provide singletons.
> 
> What I said was, and I quote, that a module "can't define special methods
> to determine how it will print, how it will let usercode loop on its items,
> etc";
> and you sharply contradicted my "can't" by asserting "of course it can".
> It's easy to check who said what when, you know.

Alex, I already said that that wasn't what I meant. If you use Python, you
use Python, not one the single feature of module namespaces. Module
namespaces can do jack shit. That doesn't mean Python can't.

> > I don't give a gerbil's tush about semantics myself.

> I.e., you don't care what words mean? 

I don't care what *you* think my words mean, no :) I've tried to explain
what I meant, but if that isn't enough, I stop caring. I have years of
experience with people who refuse to listen to what I *intend* to say, and
instead focus on their interpretation of my words, despite the fact that I
repeatedly stated that wasn't what I meant. That way I've been accused of
being a rascist (even though I grew up in the black slums of Amsterdam where
most of my schoolfriends were black), a gay-basher (even though I grew up
knowing my father's gay and I have no problem with that) and a fascist
(though I'm strongly left-wing, almost communist ;) -- and those were just
the friendly ones. When you've experienced that for the umpteenth time
(which happened some years ago) you turn into a cynical old coot and stop
caring what other people think or say as long as they don't make your life
harder :)

> My "forbidden desire" (to get in a module-object some of the nice
> flexibility I get with class instance objects)

Aaah, now I see the problem. You realized that *module instances* are
singletons (which I didn't think about, because I don't care about
singletons, either :) and thus were talking about modules themselves, not
the contents of their namespaces. What /F proposed, or at least how I
interpreted his proposal, was to use module namespaces as namespaces to hold
singletons, not use modules themselves as your singletons. And yes, I agree,
you can't let the module define how it behaves. I simply thought you were
talking about objects in a module's namespace, since needing modules to be
definable is such a boggling concept, to me :-)

> That a singleton (which is not a module object) may be bound to an
> attribute in a module's namespace is certainly true (just as it may be
> bound to an item in a tuple, or whatever), and not particularly
> interesting.  Part of the lack of flexibility of module objects means that
> the module cannot stop that attribute from accidentally being re-bound to
> something different, of course -- a class instance COULD do that regarding
> its attributes by defining __setattr__ suitably, of course -- but maybe I
> shouldn't even *discuss* my forbidden desires, as class instances are
> *intended* to be able to protect attributes against accidental rebinding
> while module objects aren't, and that's that...?

Of course you can express your forbidden desires. Even the desire for
__str__ and __[gs]etattr__, even though I think it's a pretty useless idea.
(Modules are namespaces, and should stay namespaces. If you want an object
to be 'configurable', you shouldn't use a namespace. Keep Python Simple ;)

Regardless of singletons, there might be other good reasons to provide, for
instance, 'frozen' modules, with a read-only namespace after initialization.
Or rather, *easy* frozen modules, since I think you can already do it from
C. But I still fail to see how using a factory function is an imperfect
solution, other than for the sake of theory. Maybe Guido should Pronounce
that Python is not a singleton language, just like it isn't a functional
one, but it does provide ways of working around the missing parts.

> But anyway, what irked me was not basically what you _meant_ (not
> being particularly well-provided with ESP, I could hardly guess that by
> saying 'of course you can' you meant 'you cannot and should not
> even *want* to'), but, rather, what you _said_ -- which now appears
> you agree is utterly false and unfounded, and not far from the reverse
> of your intended meaning (and if you think that by saying the opposite
> of what you mean you are "making clear" anything, you must have a
> peculiar view of 'clarity').

No, not at all. I still stand by my original statement: you can do anything
you want to an object in a module namespace. It's just that we were talking
about something different -- module namespaces *contents* versus module
namespaces themselves. I wonder which was the one /F intended ? :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!