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.... :-)
--
https://mail.python.org/mailman/listinfo/python-list
