extension of Pathlib.path break other libraries about fastcore HOT 3 CLOSED

Many thanks for the report and the link to the previous issue. I hadn't seen before that someone had suggested a way to subclass pathlib.Path - something I've tried to do before but had many problems. I'll see if that works. Otherwise I'll see if we can rename these methods to something less common, since it does seem like plenty of libraries are making this silly assumption! :)

from fastcore.

Sorry, I found this is a duplicate issue: #29 although it isn't resolved properly in my opinion. I agree that the issue is in other libraries checking if something is an open file by checking if it has a read() or write() function, but it is not very user-friendly as it is now as it causes an error that can be very hard to debug if you are unaware of the fastcore patching done to pathlib.Path.

from fastcore.

Fixed in v1.1

from fastcore.