2001 Enchancement Wishlist

[Alex Martelli]

"Thomas Wouters" <thomas at xs4all.net> writes:

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

We appear not to have important disagreement on substance -- just on
who said what when, which, as I say, is easy to check (never saw a
"sorry, that wasn't what I meant" by you on this thread before this
post, for example).  At least, I hope this clarification assuages
your oft-expressed surprise at my reaction: I was responding to your
words, and not to the intended meaning (well) hidden behind them.

I don't particularly "care about singletons", either, nor do I have
any objection whatsoever to factory-functions (out of all creational
patterns in the GoF book, I rate Singleton the least useful, the
Factory ones the most useful).  And, most emphatically, I was never
asserting "Python can't" do this-or-that in my post to which you
originally objected.


> (Modules are namespaces, and should stay namespaces. If you want an object
> to be 'configurable', you shouldn't use a namespace. Keep Python Simple ;)

Modules are not *just* namespaces.  They *have* namespaces, they
also have initialization-code (which is what may originally do
some populating of that namespace, but it can also do other things).

Recognizing (e.g.) a "def __setattr__" at module-level as providing
a similar function to a similarly-named method in a class instance
would (in my opinion) not 'complicate' the Python language: it would
just extend an already-existing concept (which currently only applies
to class-instances, and modules coded in C) to some more objects
(to wit, modules coded in Python).  It would just add a modest amount
of functionality at an even more modest conceptual cost.

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

Exactly.  A few lines above, you wrote you thought of my desire for (e.g.)
a module having __setattr__ that "it's a pretty useless idea".  Now, "there
might be other good reasons" for something that might be provided through
such means (whether or not singletons are involved)...

A different approach to providing such features would be to make a little
addition to _dictionaries_ (all objects _using_ dictionaries would then
potentially benefit) -- whether it be something as simple as a 'flags'
field, regulating whether entries can be [a] overwritten if already
present, [b] added if not yet present (two separate flags for the two
permissions, or, to reduce things to the bare bones, one for both); or,
something as rich as callables equivalent to __setattr__/__getattr__,
which (with a bit more effort) might provide for 'freezing' but also
for much, much more.  (Of course, ways would have to be provided to
access/mutate these things, be they as simple as 1 flag or as rich as
2 callables -- barest-bones might be a single new 'freeze' method of
dictionary objects irretrievably turning the 'single [a]+[b] permission
flag' off, full-featured would require a little bit more).

Working at dictionary-level might not be any harder than working on a
specific user of dictionaries (e.g., module-objects), either in terms
of code changes or conceptually for the Python programmer, yet could
provide more power for the same cost.

An alternative would be to leave built-in dictionary objects alone,
but let any user-coded mapping object be used instead of a dict (with
some way to set it... where __dict__ is a read-only attribute, it
might have to become r/w, or else some other way to set it might
be supplied -- e.g. a new setdict function).

That might be conceptually simplest for the Python programmer, just
generalizing the already widely-applicable idea that "like can be
substituted for like" to a few more cases.  It would require hunting
through the Python C sources for uses of PyDict_something to be
changed into PyMapping_whatever (thus it might be a 'pervasive'
mod, touching many source files, but conceptually it would seem
reasonably simple).

BTW, I just noticed in the docs (6.4 in the C/API reference) that
PyMapping_* appears _GetItem and _SetItem -- only the string
versions are documented -- and this seems to reflect what gets
exposed by the abstract.h headerfile.  I *am* somewhat confused;
are only strings valid keys in generic mapping objects (and if
so, why is PyMapping_DelItem provided in both generic and string
versions...)?


> 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

I don't see any imperfection to factory-functions in OO theory,
either (a language which refuses to acknowledge anything _but_
'methods' might see factory-functions as factory-methods, of
course, but that's six of one, half a dozen of the other).


Alex