2001 Enchancement Wishlist

Alex Martelli aleaxit at yahoo.com
Thu Jan 4 17:10:10 EST 2001


"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".

> 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.


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

I.e., you don't care what words mean?  That would seem to square with
the self-contradictions above noticed, yes.  Or are you using 'semantics'
to refer to programming languages, to assert you don't care what various
programming constructs actually *do*...?

> I was merely making clear what /F suggested: use a
> module namespace to expose singletons -- and I still don't understand what
> your problem is with that.

My "forbidden desire" (to get in a module-object some of the nice
flexibility I get with class instance objects) is the only source of my
(mild) 'problem' with using module _objects_ as singletons.  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...?

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').


Alex



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com





More information about the Python-list mailing list