equivalent of Ruby's Pathname?

[Phlip]

Gregory Ewing wrote:

> It wouldn't just be open() that people would want modified --
> it would be every other function that takes a pathname as
> well.

Then refer to the same argument against implicit type conversions in C+
+.

A ::std::string must call .c_str() to turn into a lowly char*, before
passing into a C function. Advocating for 8 characters of convenience
opens the risk of silent bugs at refactor time.

> I seem to recall another point of contention was whether
> path objects should have methods for accessing the file
> system (opening files, renaming them, etc.) or whether it
> should confine itself to representing and manipulating
> pathnames.

In that case, the package I picked seems to have "erred" on the side
of programmer convenience.

Because the basic file operations (exist, stat, move/rename, copy,
open, chmod, unlink) come as a complete and whole kit, a class should
simply present that kit, insulating against filesystem differences.

> In any case, introducing any kind of path object at this
> late stage of the language's development would result in
> More Than One Way to represent pathnames, with neither of
> them being the obvious choice.

Ah, now we get down to the root of the problem. Because Python is so
stuck on the "one best way to do it" mentality, language bigotry
prevented the Committee from picking from among several equally valid
but non-best options. And after 20 years of growth, Python still has
no Pathname class. What a mature community! C-:

--
  Phlip
  http://c2.com/cgi/wiki?MoreliaViridis