Any other Python flaws?

[Bengt Richter]

On 15 Jun 2001 18:11:48 +1200, Paul Foley <see at below> wrote:

>On Fri, 15 Jun 2001 04:01:49 GMT, Bengt Richter wrote:
>
>> The guiding star would be having a platform-independent abstract
>> hierarchical name space to virtualize access to various
>> containers and sources and destinations of stuff. Mapping
>> access to a particular platform's file systems would be one use.
>> Mapping to unix could be pretty transparent as far as usage
>> is concerned.
>
>> One benefit would be that Python could have its _own_ standard
>> hierarchical file-and-such-entities-as-my-be-desired name space
>> independent of platform, or at least more independent.
>
>http://www.xanalys.com/software_tools/reference/HyperSpec/Body/chap-19.html
>
Thanks for the link, although ISTM it focuses on regularizing path
expressions relative to _existing_ file systems without creating a
_new_ hierarchy, which is a key part of what I was trying to describe.

Defining a standard abstract tree of names is more akin
to the LSB/FHS effort found at:
Linux Standard Base: http://www.linuxbase.org/
Filesystem Hierachy Standard: http://www.pathname.com/fhs/

_EXCEPT_ that they are trying to standardize _actual_ file systems
whereas I was saying that you could define an _abstract_ tree of/for
names totally independently, and then attach/mount things to standard
places in that tree so that they can be accessed in known abstract
tree locations irrespective of their actual file system tree locations
or the pathnaming conventions of the particular OS/file system.

As far as files go, on unix you could do virtually the same thing
by creating a tree of your own and populating it with links to the
things you are interested in having appear in your standard tree.

But all platforms do not support this, nor can you link in
python objects etc., since you are not in python there.

Having an abstract tree would also make possible laying out python
package and module relations in terms of their standardized abstract
tree locations without worrying about where they were actually
installed on disks or networks, or indeed whether they were hooked-in
python objects playing proxy roles.

Also, switching experimental stuff in and out would be made more
flexible, I would anticipate, since changing a few lines in a
configuration file could determine what shows up where.