On 1/24/06, Ian Bicking <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
