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

[Ronald Oussoren]

> 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).  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.

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).

Ronald