Misaggregation of symbols from disparate namespaces? was: Re: Global in multiple files

[Bengt Richter]

On Mon, 11 Jun 2001 16:27:34 +0200, "Alex Martelli"
<aleaxit at yahoo.com> wrote:

>"Roman Suzi" <rnd at onego.ru> writes:
[...]
[unattributed quote, sorry]
>> >"Do the simplest thing that could possibly work", because
>> >"you ain't gonna need it" (where "it" is the rich, complex,
>> >over-engineered, over-designed very general solution:-).
>> 
>> That is why Microsoft systems still have those funny
>> A:, B:, C: letters before file paths ;-)
>
>Nope, this has absolutely nothing to do with it.  Backwards
>compatibility with externally-visible interfaces to previous
>releases of your software (and older software you choose
>to be similar/compatible to: CP/M, in Microsoft's case) are 
>(as should be obvious -- I'm amazed I have to point this out)
>a completely different issue.
>
"A:, ..." accidentally poked one of my hot buttons ;-)

IMHO "A:, B:, C:" prefixes for file paths are evidence of
a serious problem with name spaces: Applications have to
handle symbols that should really only be the business of
the OS and special utilities. You will note that Unix has
a mount function to keep '/dev/hdc0' and such out of path
strings like '/home' etc.

The conventions of using container names (file names and extensions)
to identify and carry type information about the content is
also dangerous IMHO, however convenient. Magic numbers and
special prefixes embedded in the data at least survive a simple
renaming of the container. (I'm tempted to ramble about what
we could do with one or two sectors as data prefix instead of
a few bytes, but I'll restrain myself ;-)

Python name spaces seem to be a product of thoughtful design,
so I wonder if it has succeeded in avoiding the pitfalls of
misaggregating symbols from different kinds of namespaces in
what should be abstract path representations.