Any other Python flaws?

[Bengt Richter]

On Thu, 14 Jun 2001 14:27:59 -0400, Andrew Kuchling
<akuchlin at mems-exchange.org> wrote:

>I was updating my page of possible Python design flaws
>(http://www.amk.ca/python/writing/warts.html) last night to take 2.1
>into account.  2.1's nested scoping fixes one major wart, and the
>other major one, the type/class dichotomy, might get fixed in 2.2 if
>the descr-branch in CVS turns out well.  (It's neat that the two
>largest ones may both get fixed before 2001 is out.)
>
>That leaves the remaining warts as minor wibbling about 'do'
>statements, print >>, and the like.  Are there any other flaws that
>should be added?

Virtualized file system access with mounting of real-system
files and trees at any desired mount points?

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.

The unix model of a '/' root and everything branching from
there seems like a good one to adopt, but let's think about the
virtual aspect.

For one thing, you would have the opportunity to define access
controls, e.g., by mounting real file trees read-only and
restricting chdir by not allowing access to anything not mounted.

The (OTTOMH ;-) concept is to have an ordinary python directory
as the root, e.g.,

	pyVFS={}

and then populate it by initializing and 'mounting' various things.
One initial thing might be a virtual 'python' subdirectory which
could contain the mount points for various standard parts of
a typical python installation, e.g. docs,libs,etc., e.g.,

	pyVFS['python']={}

Thus mounting doc on my win32 system might be equivalent to

	pyVFS['python']['doc']= \
		PathAccess('drwxr-xr-x','d:\\Python21\\Doc')

whereas on my slackware linux system it might be

	pyVFS['python']['doc']= \
		PathAccess('drwxr-xr-x','/usr/doc/python-1.5.2')

And thus open('/python/doc/index.html') could be platform independent,
assuming the pyVFS tree was designed to a standard. This could also
eliminate much of the need to use sys.path searches.

I don't know how efficient using nested python dictionaries would be,
but that's an optimization detail, and only unusual programs would
care.

The idea of  "PathAccess"  is to have a reference to an
instance of an access class initialized with whatever is needed to
define the access. This would have to be at least partly platform
dependent depending on what it was interfacing to. Compatible classes
would have to have standard methods for accepting path tails to chase,
etc., so that it would fit in with simply chasing nested python
dictionaries within which they may be encountered.

If the system looked in a directory and found that 'doc' was not an
access object, but another virtual subdirectory, it would act
accordingly, and chase the path through it as opposed to names gotten
from a mounted directory via the access object.

This could allow installation of file filters and/or network goodies
and/or even 'files' with funny side effects, like converting data to
plots and storing it to a destination .png file, etc., or piping it
to an X display, or ...

The thing is, you'd have a private python world to play with, mapping
to platform things as necessary and/or possible/desirable, while
being able to sythesize totally new virtual things to access.

I'd love to spend more time on this, but that's my newbie USD0.02 for
now. Got a long evening ahead.