[Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin

[Andrew Barnert]

On Dec 31, 2014, at 9:20, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> 
>> On 31 Dec 2014, at 00:12, Andrew Barnert <abarnert at yahoo.com> wrote:
>> 
>> On Dec 30, 2014, at 22:36, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> 
>>> 
>>>> On 30 Dec 2014, at 00:19, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>>> 
>>>> Andrew Barnert wrote:
>>>>> you just look up the name of the trash directory (which I believe
>>>>> is theoretically localized but actually always ~/.Trash on the drive with
>>>>> your user directory, $mnt/.Trash otherwise) and call rename.
>>>> 
>>>> You may also need to invent a unique name if there's already
>>>> a file in the trash with the same name.
>> 
>> At this point too much context has been stripped from the message for the replies to make sense. The original message was pointing out that there is no separate "low-level API" for trashing that could go in os along with a "high-level API" in shutil--unless you consider rename a low-level API for trashing, in which case it's already there.
>> 
>>> And whatever else the api does for you… IMHO its better to use the API for this on OSX, such as FSMoveObjectToTrashSync.
>> 
>> Except that API is deprecated (meaning, among other things, that if shutil linked to it, any py2app-ed or embedding app that imports shutil can't be sold in the Mac App Store), and there are no suitable replacements.
> 
> There’s always the Cocoa APIs for moving files to the Trash, if its fine to depend on OSX 10.6 or later (as you mentioned below).  

Yes, but the 10.6 Cocoa APIs both have problems; the useful one requires 10.8. So as long as Python standard builds are 10.6… (I suppose you could have it in the stdlib but only available at runtime on 10.8+, but I think that would be weird.)

> Whether or not you’d want to do that in the stdlib is a different question.  My point was that just using os.rename move a file to the trash is a bad idea.

Yes, and therefore there just _is_ no low-level, suitable-for-os, function that would help for a higher-level shutil/pathlib function.

> BTW. I’m not really in favour of using either FSMoveObjectToTrash or the Cocoa APIs in the stdlib, given the problems we’ve had with proxy support in the _scproxy extension (basically resulting in “random” crashes when using urllib in a child proces started with os.fork because Apple’s system frameworks don’t support that).

I forgot about that, but you're right, that's another potential reason not to put this in the stdlib.

Anyway, maybe what we need is something in the docs explaining the various ways to do it (with links to
PyPI projects as appropriate) with the pros and cons of each. What I wrote before isn't right, because it doesn't take into account the forking issue. It could be easily extended, although that might get a bit long for stdlib documentation.