[Python-Dev] The path module PEP (original) (raw)

Jason Orendorff jason.orendorff at gmail.com
Wed Jan 25 17:39:03 CET 2006

On 1/24/06, Ian Bicking <ianb at colorstudy.com> wrote:

There's kind of a lot of methods in here, which is a little bothersome. It also points towards the motivation for the class -- too many options in too many places in the stdlib. But throwing them all in one class consolidates but doesn't simplify, especially with duplicate functionality.

I agree.

Let me explain why there's so much cruft in path.py. The design is heavily skewed toward people already very familiar with the existing stdlib equivalents, because that is the market for third-party modules. I think my users want to type p.methodname() for whatever method name they already know, and have it just work. A sloppy API you've already learned is easier to pick up than a clean API you've never seen before. Ergo, cruft.

A stdlib Path should have different design goals. It should have less redundancy, fewer methods overall, and PEP-8-compliant names.

-j

More information about the Python-Dev mailing list