The thread on python-dev with respect to PEP 355 seems to have died out, so I thought it might be a good time to move things over here.
What I'd like to do is to start by examining the most fundamental assumptions about refactoring os.path and the various other path-related functions. Before we even begin to write a new PEP, I want to at least make sure that consensus is even possible - even though we may not all be on the same page (to use a tired metaphor), we're at least reading from the same book :) Let me break this down into a number of questions: 1) Does os.path need to be refactored at all? I think most people agree that os.path isn't perfect, but IMHO it isn't terrible either - you can get work done with it, and its not really that hard to learn. From my own experience, I've often run into cases where I overlooked some critical feature of the standard library, and ended up looking foolish after posting my question on the python mailing lists, only to discover that the answer was there all along (kind of like Dorothy's red slippers in that way.) But I've not yet had an occasion, as far as I can recall, where the os.path module was the culprit. 2) Putting aside for the moment the issue of syntactic sugar, convenience, code beauty, and ease of learning, is there anything that the existing os.path *won't do* that we desperately need it to do? 3) Assuming that the answer to #1 is "yes", the next question is: "evolution or revolution?" Do we want something that looks 95%, 80%, or 0% the same as the existing library? Is this just a case of moving around a few stray functions, or is are we going to take and axe and give os.path a reprogramming job it will never forget? 4) My third question is: Who are we going to steal our ideas from? Boost, Java, C# and others - all are worthy of being the, ahem, target of our inspiration. Or we have some alternative that's so cool that it makes sense to "Think Different(ly)"? 5) Must there be one ring to rule them all? I suggested earlier that we might have a "low-level" and a "high-level" API, one built on top of the other. Is this a good idea, or a non-starter? OK lets start with that and see what happens. -- Talin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
