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 -- http://mail.python.org/mailman/listinfo/python-list
