pathlib

[Dan Sommers]

On 10/2/19 6:58 PM, DL Neil via Python-list wrote:
 > On 3/10/19 12:42 AM, Dan Sommers wrote:

 > Certainly, although some may have quietly given-up talking to a
 > non-OOP native - and one so 'slow', I am appreciative of all
 > help-given!

I also speak OO as a second language (usually kicking, screaming, and
spouting expletives, but that's my personal perspective and a separate
issue).  Hold this thought.

 >> Maybe you could implement one of the proposed changes in a private
 >> library function as a workaround?

 > In my mind, I'm wondering if it will come to that (having 'got past'
 > the original observation/issue, I'm concerned by .rename()'s silent
 > errors, for example). However, that 'outside' research, eg
 > StackOverflow, shows that sub-classing pathlib is problematic, and
 > quite possibly not part of the design (this is repeating 'gossip' -
 > I'm not going to try to justify the comment or the claim) ...

So don't subclass anything.  :-)

One non-OO option would be to write a function that takes a Path
instance and a new name, calls Path.rename, and returns a new Path
instance with the new name, something like this (untested):

     def path_rename(path, target):
         new_path = pathlib.Path(target)
         path.rename(new_path)
         return new_path

Because it returns a new Path instance rather than mutating an existing
one, you may have to re-think parts of your application that depend on a
specific Path instance being mutated.

The usual OO option that doesn't involve subclassing is Delegation, with
a capital D.  See <https://en.wikipedia.org/wiki/Delegation_pattern>,
and see Mhttps://softwareengineering.stackexchange.com/questions/381140>
for python-specific objections.

 > ... That said, last night my code sub-classing Path() seemed to work
 > quite happily (albeit only tested on a 'Posix' box). The yawning
 > chasm/gaping jaws below, however, are that I've probably made yet
 > another 'assumption' about how things 'should' work.  Run for the
 > hills!

Your caution regarding an assumption is a Good Thing.  Tests, tests, and
more tests.  Document (in large, friendly lettering) that you haven't
tested in a non-Posix environment.

 > This was supposed to be a simple, down-time task; a
 > learning-opportunity re-factoring code to use a new (er, um, as of
 > v3.4) library...

The best laid plans....  :-)