[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1437: Replace os.path (etc.) with twisted.python.filepath

[Tahoe-LAFS]

#1437: Replace os.path (etc.) with twisted.python.filepath
-------------------------------+-----------------------------
     Reporter:  arch_o_median  |      Owner:  zancas
         Type:  defect         |     Status:  new
     Priority:  minor          |  Milestone:  undecided
    Component:  code           |    Version:  1.8.2
   Resolution:                 |   Keywords:  unicode cleanup
Launchpad Bug:                 |
-------------------------------+-----------------------------

Old description:

> The filepath file system interface offers a single consistent object
> oriented interface for the various file system operations we need.
> Initially we just wanted to know if a file was the descendant of some
> directory, but this seemingly trivial question is not easily answered
> with the traditional python file system libraries (e.g. shutil, os.path,
> the open builtin, ... etc).  Moreover these functions are not to be found
> in a single place, and lack a consistent interface.
>   Additionally we think filepath is unique in offering atomic overwrite,
> (through setContent).  So this ticket is to replace all the older ways of
> manipulating the filesystem with shiny new !FilePath.

New description:

 The filepath file system interface offers a single consistent object
 oriented interface for the various file system operations we need.
 Initially we just wanted to know if a file was the descendant of some
 directory, but this seemingly trivial question is not easily answered with
 the traditional python file system libraries (e.g. shutil, os.path, the
 open builtin, ... etc).  Moreover these functions are not to be found in a
 single place, and lack a consistent interface.
   Additionally we think filepath is unique in offering atomic overwrite,
 (through setContent).  So this ticket is to replace all the older ways of
 manipulating the filesystem with shiny new !FilePath.

--

Comment (by zooko):

 I really want to use `filepath`. It results in more readable and less
 error-prone code than using the smorgasbord of `open()`, `os.whatever`,
 `shutil.whatever`, and so on. I think we should do it. However, there are
 several issues that the maintainers of `filepath` are not going to fix
 anytime soon, or even one critical issue that they refuse to fix in the
 way that I want it done, so I think we'll need to do it by forking or
 embedding filepath into our codebase.

 The critical issue about which they and I disagree is: what do you do if
 you go to read a filename from the operating system, and you get a
 sequence of bytes which cannot be decoded in the nominal encoding? Their
 answer is: store the bytes, because if you write them back out to the
 ''same'' filesystem later, later users will presumably treat them as
 having the same encoding, whatever it was, even though our code doesn't
 know what it was. My answer is: raise an error, because we can't safely
 transport these bytes out to ''other'' systems, or process these bytes,
 and anyway this is probably a rare condition or even an outright error in
 the user's system. (That is what we long ago decided to do in Tahoe-LAFS,
 and we've never had a complaint about it. There are quite extensive
 discussion threads in old closed tickets and in the tahoe-dev email
 archive about this design decision.)

 That discussion is https://twistedmatrix.com/trac/ticket/5203 . Other
 tickets are:

 * https://twistedmatrix.com/trac/ticket/2366
 * https://twistedmatrix.com/trac/ticket/5279
 * https://twistedmatrix.com/trac/ticket/5280

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1437#comment:7>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage