On 12 October 2012 21:33, Ethan Furman
Antoine Pitrou wrote:
On Fri, 12 Oct 2012 12:23:46 -0700 Ethan Furman
wrote: Which is why I would like to see Path based on str, despite Guido's misgivings. (Yes, I know I'm probably tilting at windmills here...)
If Path is string based we get backwards compatibility with all the os and third-party tools that expect and use strings; this would allow a gentle migration to using them, as opposed to the all-or-nothing if Path is a completely new type.
It is not all-or-nothing since you can just call str() and it will work fine with both strings and paths.
D'oh. You're correct, of course.
What I was thinking was along the lines of:
--> some_table = Path('~/addresses.dbf') --> some_table = os.path.expanduser(some_table)
vs
--> some_table = Path('~/addresses.dbf') --> some_table = Path(os.path.expanduser(str(**some_table)))
The Path/str sandwich is ackward, as well as verbose.
A lot of them might end up inadvertently converting back to a pure string as well, so a better comparison will in many places be: some_table = Path('~/addresses.dbf')
some_table = Path(os.path.expanduser(some_table))
vs some_table = Path('~/addresses.dbf')
some_table = Path(os.path.expanduser(str(**some_table)))
which is only five characters different. I would also prefer: some_table = Path('~/addresses.dbf')
some_table = Path(os.path.expanduser(some_table.raw()))
or some other method. It just looks nicer to me in this case. Maybe .str(), .chars() or.text(). Additionally, if this is too painful and too often used, we can always make an auxiliary function. some_table = Path('~/addresses.dbf')
some_table = some_table.str_apply(os.path.expanduser)
Where .str_apply takes (func, *args, **kwargs) and you need to wrap the function if it takes the path at a different position. I don't particularly like this option, but it exists.