-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide how to represent pathnames #124
Comments
My 2¢ here is to leave paths as strings. Getting paths "right" for all use cases doesn't seem possible, and having a flexible low-level API somewhere, even if it opens up the possibility for errors, seems valuable to me. For Flow, we have the need to share paths between platforms. These are relative paths, using the However, we do build wrappers around the various paths, to ensure they are not mishandled. But this is an application-layer concern for us. We take the strings returned by system calls into the appropriate (unboxed) wrapper type and coerce back into strings as needed. |
Thanks, that makes sense. And I see that DOS has always supported https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-is-the-dos-path-character |
Do you have a link to your path wrapper library, @samwgoldman? It'd be interesting to contrast it with Fpath and Python's Pathlib. I agree that keeping strings at a low-level in Eio is a reasonable for Eio 1.0. |
At the moment, paths in Eio are strings, which are used in the context of some base directory. e.g.
This should work well on most systems, but we need to think about how to support Windows too.
Possibilities include:
The Fpath library encodes lots of knowledge about Windows paths. It probably can't be used directly because its paths behave differently depending on the host platform (preventing e.g. a program running on Linux from creating paths that are to be used on Windows). The path rules should probably be per-filesystem instead.
The text was updated successfully, but these errors were encountered: