Survey -- Move To Trash function in Python?

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu May 14 22:28:28 EDT 2015


On Fri, 15 May 2015 01:59 am, Chris Angelico wrote:

> On Fri, May 15, 2015 at 1:49 AM, Grant Edwards <invalid at invalid.invalid>
> wrote:
>> On 2015-05-14, Steven D'Aprano <steve+comp.lang.python at 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?
[...]
> I have never used such a feature, and generally found them to be more
> annoying than useful. The times when I want to mark a file for
> deletion either now or at some undefined time in the future (at the
> file system's discretion) are approximately zero; either I want the
> file, or I can delete it immediately. Given that actually-removed
> files can usually be undeleted if their disk space hasn't been
> reclaimed, I don't think trash cans really help much.

If you're relying on the ability to undelete, you're already in trouble, you
just don't know it. As I understand it, you can't undelete from SSDs. Or
maybe it's the opposite, you can't securely delete from SSDs? I forget. In
any case, undelete is *unreliable* -- if you're relying on it for "Oh, I
changed my mind", then you're in trouble.

The primary purpose of trash cans is to protect users who are, um, let's
say, less than comfortable with computers, or careless, or both. But even
experienced users can make mistakes, or change my mind, and I find myself
recovering files from the trash, oh, once or twice a year.

I think every person who deletes files from the command line has
accidentally deleted the wrong file *more than once*. (And again, I hold my
hand up sheepishly here too: been there, done that.) If we were sensible,
we'd give ourselves a safety net just like the desktop guys, but there's a
machismo associated with command line use than makes us tough it out. No
matter how many times we delete the wrong file and have to recover it from
backups (or recreate it from scratch because the backups aren't working),
we tell ourselves it will be the very last time and it will never happen
again.

At least many Linux distros alias mv to mv -i by default, which is a start,
and use rm -i for root.

Anyway, this isn't meant to be a critical look at sys admin psychology :-)


> Plus, I think it's a UI insanity when a console program dumps
> something in the trash, which to me has always felt like a GUI file
> manager tool.

I'm not sure why you should feel that way. Every other file manager function
is more or less unified between GUI and CLIs. There's only one file
manager, and I think you would be annoyed if (say) renaming a file via a
CLI only showed the new name at the CLI, not from the GUI.

If I was writing a file manager tool, it shouldn't matter whether it used a
GUI or CLI, or a rich Curses text-based interface. I'd want to offer both
delete immediately and move to trash.


> That said, though, I think a standardized API for trashing files is
> not a bad thing; and it's not something that will need huge API
> changes, so the costs of feature-freeze would be low.

Indeed.



-- 
Steven




More information about the Python-list mailing list