Python Forum
file system path representation
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
file system path representation
#1
why is a special function needed to get the "file system path representation" (how the documentation refers to it)? isn't the existing representation good enough? i'd like to see printed out what a representation that is not good enough looks like and what __fspath__() or os.fspath() would return. imagine you were the on implementing this function. what would the code look like?
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#2
I think the purpose of the method is to allow new classes, perhaps user-defined classes, to represent or abstractize the notion of a path in a file system. In the circumstance where an actual OS path is required, the os.fspath() method is the bridge that allows the code to actually persist something on disk.

In the pyfilesystem module (named fs), a base class is defined with methods such as .makedir() or .open() or .remove(), .touch() etc, then subclasses are defined. It allows client code to manipulate in a uniform way a virtual file system which could concretely be a memory file system or a tar file or a remote system accessed through ftp. I even wrote my own file system with Python dictionaries. Under certain circumstances, for example when calling such or such C library, a path to an actual OS file or directory is required. This actual path is obtained through the .getsyspath() method. Of course this method will succeed only for some of the subclasses, those that refer to actual files or directories on disk. In the current implementation of PyFileSystem, this method invokes fspath().
Reply
#3
(Feb-27-2021, 10:41 PM)Skaperen Wrote: why is a special function needed to get the "file system path representation" (how the documentation refers to it)? isn't the existing representation good enough? i'd like to see printed out what a representation that is not good enough looks like and what __fspath__() or os.fspath() would return. imagine you were the on implementing this function. what would the code look like?
So still on this wonder about this,did you read PEP 519👀
Short history in Python 3.4 we got pathlib.
>>> from pathlib import Path
>>> 
>>> working_dir = Path.cwd()
>>> working_dir
WindowsPath('C:/code')
>>> type(working_dir)
<class 'pathlib.WindowsPath'> 
So for various there is sometime a need to get string representation,as OS has the C's own decision to represent file system paths as string const char *.
So str() work,but has corner cases that may fail or create a file unwanted.
>>> working_dir
WindowsPath('C:/code')
>>> # Convert to string path
>>> new_path = str(working_dir)
>>> new_path
'C:\\code'
>>> type(new_path)
<class 'str'>
The preferred way is to use __fspath__() or os.fspath(),added in Python 3.6.
>>> working_dir
WindowsPath('C:/code')
>>> # Convert to string path
>>> working_dir.__fspath__()
'C:\\code'

>>> # Or 
>>> import os
>>> 
>>> os.fspath(working_dir)
'C:\\code
Reply
#4
for pathlib i mostly just do file things with it as-is. i did need the actual string once and tried str(obj) and it worked; i got the path as a str. i thought about trying bytes(obj) but moved on.

so they want something different than simply str(obj)?

so the representations that one might need to get a str of via fspath are the instances of classes made to represent or refer to a file, such as database indexes and other such things. the preferred way to get a str representation is not to use str(obj) but use fspath somehow. so that would mean using str(obj) on non-text things will some day be depricated?
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#5
(Mar-01-2021, 02:42 AM)Skaperen Wrote: so they want something different than simply str(obj)?
Yes they where getting feedback from users that it could be error error-prone in some cases.
PEP 515 Wrote:This lack of support required users of pathlib to manually convert path objects to strings by calling str(path) which many found error-prone.

One issue in converting path objects to strings comes from the fact that the only generic way to get a string representation of the path was to pass the object to str().
This can pose a problem when done blindly as nearly all Python objects have some string representation,
whether they are a path or not, e.g. str(None) will give a result that builtins.open() will happily use to create a new file.
Skaperen Wrote:the preferred way to get a str representation is not to use str(obj) but use fspath somehow.
so that would mean using str(obj) on non-text things will some day be depricated?
I think this specials case for Path's object where str(pathlib_obj) is not recommended.
Reply
#6
how does someone go about making this kind of error? now i am curious why an error like this is considered to be important enough to change things this way? when will str(path) at least raise an exception? i can only imagine what that exception might say.
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#7
(Mar-02-2021, 12:21 AM)Skaperen Wrote: how does someone go about making this kind of error? now i am curious why an error like this is considered to be important enough to change things this way?
Not sure as i have not seen any feedback the have got from users.
Skaperen Wrote:when will str(path) at least raise an exception? i can only imagine what that exception might say.
Path should not call str() internally to allow inheritance
class MyPath(pathlib.PosixPath):

  def __fspath__(self) -> str:
    # Custom fspath

  def __str__(self) -> str:
    raise TypeError(
        f'Please do not use `str()` directly:'
        ' * For display: Use, f-string, `.format` or `repr`'
        ' * To access the path string: Use `os.fspath`, as per PEP 519'
    )

  def __format__(self, format_spec) -> str:
    return format(super().__str__(), format_spec)
Will probably never happen as author got second taught and close it.
If someone use str() and it work and don't know about fspath i see no problem in that.
pathlib makers did not think of this behaviour,so adding stuff later like raise exception that can break str() in more places is not ideal.
Reply
#8
there are many errors coders can make with any class of object. gather all the classes for which str(obj) is the first implemented way to get its string representation (for purposes you would not use repr(obj)). now why does the Path class stand out as error prone? or are they all error prone. i do not recall making any errors with that. what do these users want? a Python in which no one can make any error, ever (a dream language). i'd have rather had obj.str(). is that what those users wanted?
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020