[Python-Dev] Unipath package (original) (raw)

Mike Orr sluggoster at gmail.com
Sun Jan 28 19:30:19 CET 2007

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>

More information about the Python-Dev mailing list