[Python-Dev] Unipath package

[Mike Orr]

On 1/28/07, Tobias Ivarsson <thobes at gmail.com> wrote:
> I am a MSc of Computer Engineering student from Sweden. A frequent reader of
> python-3000, and an occasional reader of python-dev for about a year now. I
> have wanted to get involved in the development of python for a while but
> haven't found the time before. Now, when I'm in the process of trying to
> figure out what project to do for my thesis, I have actually found myself
> having more time than before. Therefore I thought that now is a better time
> than never to get involved. After that compulsory first-post-introduction of
> myself, lets get to the reason I choose to send the post at all.

Hi Tobias!  You've got the first step in Python development -- reading
python-dev.  Now you just have to pick an interesting task from the
dozens hinted on the list and do it.  Of course, there are many tasks
not on python-dev that are also worthwhile.  Bugfixes in the Python
core, adopting a package that lost its maintainer, being active in the
SIGs, testing code (as you've just done) -- these are just a few
things off the top of my head.  Working on third-party libraries is
just as legitimate as working on the core; both are needed.  There are
also non-technical needs like promoting/marketing Python.  If you can
make it to PyCon or EuroPython, you'll meet a lot of contacts you can
potentially collaborate with.  Laura Creighton lives in Sweden and is
highly involved in Python activities; she would no doubt have some
suggestions.  If you can't locate her I can dig up her address.  If
you'd like to write me privately about your specific interests and
talents in Python, I can try to steer you to a group that is working
on that.

> I noticed that you wanted Mac OS tests, here are the test results from my
> Mac OS X (10.4), running on an Intel Core Duo MacBook, using python 2.5:

Thanks for the results.  The details of Unipath's code are outside the
scope of python-dev so I'll respond privately.  The issue here is what
kind of path object would be suitable for the standard library in 2.x.
 Guido has said he's not convinced that any OO-based path class is
necessarily superior to the existing functions, but left the door open
to later consideration.  The existing proposals were rejected for
reasons the Guido didn't personally elaborate, but others channeling
him speculated they were too monolithic: too many methods in one
class, too many diverse kinds of methods in one class, and especially
mixing pathname-calculation and filesystem-access methods
undifferentiated in one class.  There is general agreement that a
pathname-calculation class is more needed than a filesystem-access
class due to the nesting of pathname calculations in expressions, so a
pathname-calculation class has a greater chance of acceptance. There's
also the question of what can be put in Python 2.x vs 3.0.  There's a
parallel proposal to move the filesystem-access functions in os.path
into os, and to move everything in shlib into os, possibly with
changes.  This has the greatest chance of acceptance in 2.x.  A small
os.path.Path class has a middling chance.

The discussion has been hampered by the lack of released code.  Only
Orendorff's class has been widely used in production systems.  The
others have either never been used or only by their authors; they
haven't made it to the Cheeseshop.  Unipath is merely to say "Here's
another way to do it; see if it works for you."  Certainly the Path
methods need more testing and use in the real world before they'd be
ready for the stdlib.  The FSPath methods are more experimental so I'd
say they need a year of use before they can be considered sufficiently
stable.

-- 
Mike Orr <sluggoster at gmail.com>