On 11/1/06, glyph@divmod.com glyph@divmod.com wrote:
On 01:46 am, sluggoster@gmail.com wrote:
On 11/1/06, glyph@divmod.com glyph@divmod.com wrote:
This is ironic coming from one of Python's celebrity geniuses. "We made this class but we don't know how it works." Actually, it's downright alarming coming from someone who knows Twisted inside and out yet still can't make sense of path patform oddities.
Man, it is going to be hard being ironically self-deprecating if people keep going around calling me a "celebrity genius". My ego doesn't need any help, you know? :)
I respect Twisted in the same way I respect a loaded gun. It's powerful, but approach with caution.
If you ever think I'm suggesting breaking something in Python, you're misinterpreting me ;). I am as cagey as they come about this. No matter what else happens, the behavior of os.path should not really change.
The point is, what *should* a join-like method do in a future improved path module? os.path.join should not change because too many programs depend on its current behavior, in ways we can't necessarily predict. But a new function/method is not bound by these constraints, as long as the boundary cases are well documented. All the os.path and file-related os/shutil functions need to be reexamined in this context. Maybe the existing behavior is best, maybe we'll keep it even if it's sub-optimal, but we should document why we're making these choices.
The user didn't call normpath, so should we normalize it anyway?
That's really the main point here.
What is a path that hasn't been "normalized"? Is it a path at all, or is it some random garbage with slashes (or maybe other things) in it? os.path performs correct path algebra on correct inputs, and it's correct (as far as one can be correct) on inputs that have weird junk in them.
I'm tempted to say Path("/a/b").join("c", "d") should do the same thing your .child method does, but allow multiple levels in one step.
But on the other hand, there will always be people with prebuilt "path/fragments" to join to other fragments, and I'm not sure we should force them to split the fragment just to rejoin it again. Maybe we need a .join_unsafe method for this, haha.