On Fri, May 15, 2015 at 11:37 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Fri, 15 May 2015 01:49 am, Grant Edwards wrote: > >> On 2015-05-14, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> >> wrote: >> >>> I'd like to do a little survey, and get a quick show of hands. >>> >>> How many people have written GUI or text-based applications or >>> scripts where a "Move file to trash" function would be useful? >> >> How would you even define what "move to trash" means in a standard >> way? > > There are standard locations for the trash on Linux, Windows and OS X. > > I presume that there are standard locations on the other main OSes, such as > Android, iOS, any Unix which supports the Free Desktop Standard(?), etc. > Anything else can either remain unsupported, or can use a caller-defined > location. >
Point to note: Inclusion in the Python standard library would cement its *API*, but not its OS and desktop support. A call like trash.retrieve("oops_i_deleted_this") will either succeed or raise an error; it can change from raising to succeeding for a given platform without breaking anyone's code. So it wouldn't be a problem to start out supporting only the most major platforms (or not even all of them), and expand later. Much as I detest the operation itself, I do think this is something worth papering over. The multiprocessing module papers over a whole lot of platform quirks, and all we have left is "make sure your main module is importable if you use this on Windows"; a trashing module could deal with all the differing ways of trashing things, and leave us with "trashing may not work on certain file systems". (Though when it comes to the bikeshedding phase, I'm sure there'll be some who say "if it can't be trashed, just hard delete it", and others who say "if it can't be trashed, raise an exception". And neither is truly wrong.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list