Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #90606 > unrolled thread

Survey -- Move To Trash function in Python?

Back to article view | Back to comp.lang.python

Contents

  Survey -- Move To Trash function in Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-15 01:45 +1000
    Re: Survey -- Move To Trash function in Python? Grant Edwards <invalid@invalid.invalid> - 2015-05-14 15:49 +0000
      Re: Survey -- Move To Trash function in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-15 01:59 +1000
        Re: Survey -- Move To Trash function in Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-15 12:28 +1000
      Re: Survey -- Move To Trash function in Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-15 11:37 +1000
        Re: Survey -- Move To Trash function in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-15 11:53 +1000
        Re: Survey -- Move To Trash function in Python? Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-14 20:49 -0600
        Re: Survey -- Move To Trash function in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-15 12:56 +1000
          Re: Survey -- Move To Trash function in Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-15 14:09 +1000
            Re: Survey -- Move To Trash function in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-15 14:25 +1000
            Re: Survey -- Move To Trash function in Python? random832@fastmail.us - 2015-05-15 14:27 -0400
              Re: Survey -- Move To Trash function in Python? sohcahtoa82@gmail.com - 2015-05-15 17:04 -0700
            Re: Survey -- Move To Trash function in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-16 04:33 +1000
    Re: Survey -- Move To Trash function in Python? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-05-14 18:32 +0100
      Re: Survey -- Move To Trash function in Python? Grant Edwards <invalid@invalid.invalid> - 2015-05-14 18:11 +0000
        Re: Survey -- Move To Trash function in Python? Chris Warrick <kwpolska@gmail.com> - 2015-05-14 20:43 +0200
        Re: Survey -- Move To Trash function in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-14 12:32 -0700
      Re: Survey -- Move To Trash function in Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-15 12:03 +1000
        Re: Survey -- Move To Trash function in Python? Terry Reedy <tjreedy@udel.edu> - 2015-05-14 22:27 -0400
    Re: Survey -- Move To Trash function in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-14 11:29 -0700
    Re: Survey -- Move To Trash function in Python? iMath <redstone-cold@163.com> - 2015-05-18 03:31 -0700
      Re: Survey -- Move To Trash function in Python? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-18 14:46 +0100

Page 1 of 2  [1] 2  Next page →

#90606 — Survey -- Move To Trash function in Python?

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?

Would you like to see that in the standard library, even if it meant that
the library had feature-freeze and could gain no more functionality?


-- 
Steven

[toc] | [next] | [standalone]

#90607

On 2015-05-14, Steven D'Aprano <steve+comp.lang.python@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?

Even withing the limited context of something like a mail client, it's
meaning varies depending on mail store format or which IMAP server
you're talking to.

Or are you assuming the only thing that can be "moved to trash" is a
file?

> Would you like to see that in the standard library, even if it meant that
> the library had feature-freeze and could gain no more functionality?

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having fun
                                  at               HITCHHIKING to CINCINNATI
                              gmail.com            or FAR ROCKAWAY!!

[toc] | [prev] | [next] | [standalone]

#90609

On Fri, May 15, 2015 at 1:49 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2015-05-14, Steven D'Aprano <steve+comp.lang.python@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?
>
> Even withing the limited context of something like a mail client, it's
> meaning varies depending on mail store format or which IMAP server
> you're talking to.
>
> Or are you assuming the only thing that can be "moved to trash" is a
> file?

AIUI this is specifically about files.

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.

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.

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.

ChrisA

[toc] | [prev] | [next] | [standalone]

#90640

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

> On Fri, May 15, 2015 at 1:49 AM, Grant Edwards <invalid@invalid.invalid>
> wrote:
>> On 2015-05-14, Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#90636

On Fri, 15 May 2015 01:49 am, Grant Edwards wrote:

> On 2015-05-14, Steven D'Aprano <steve+comp.lang.python@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.


> Even withing the limited context of something like a mail client, it's
> meaning varies depending on mail store format or which IMAP server
> you're talking to.
> 
> Or are you assuming the only thing that can be "moved to trash" is a
> file?

I'm specifically referring to files, hence "move FILE to trash".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90637

On Fri, May 15, 2015 at 11:37 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 15 May 2015 01:49 am, Grant Edwards wrote:
>
>> On 2015-05-14, Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#90642

[Multipart message — attachments visible in raw view] — view raw

On May 14, 2015 7:55 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
> (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.)

The answer is "raise an exception". Moving to trash and deleting are
different operations, and one shouldn't be substituted for the other any
more than a failed attempt to create a hard link should create a soft link
instead.

If the user wants, they can catch the exception and delete the file
instead. Recovering from an accidental deletion would be more difficult.

[toc] | [prev] | [next] | [standalone]

#90643

On Fri, May 15, 2015 at 12:49 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On May 14, 2015 7:55 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>> (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.)
>
> The answer is "raise an exception". Moving to trash and deleting are
> different operations, and one shouldn't be substituted for the other any
> more than a failed attempt to create a hard link should create a soft link
> instead.
>
> If the user wants, they can catch the exception and delete the file instead.
> Recovering from an accidental deletion would be more difficult.

Yes, but sometimes it's at the file system's discretion - particularly
when you're working with network mounts. The application may not even
know that the file got hard deleted.

ChrisA

[toc] | [prev] | [next] | [standalone]

#90647

On Fri, 15 May 2015 12:56 pm, Chris Angelico wrote:

> On Fri, May 15, 2015 at 12:49 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On May 14, 2015 7:55 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>>> (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.)
>>
>> The answer is "raise an exception". Moving to trash and deleting are
>> different operations, and one shouldn't be substituted for the other any
>> more than a failed attempt to create a hard link should create a soft
>> link instead.
>>
>> If the user wants, they can catch the exception and delete the file
>> instead. Recovering from an accidental deletion would be more difficult.
> 
> Yes, but sometimes it's at the file system's discretion - particularly
> when you're working with network mounts. The application may not even
> know that the file got hard deleted.

Citation needed.

"Move to trash" is a move operation, not an unlink. By definition, it is
reversible. Which platforms/file systems implements it as an unlink?

(I think the answer is, "broken ones".)

I've never heard of any file system implement a move to trash operation as a
primitive, it's always implemented at the application layer (desktop
management being an application for these purposes). As far as the file
system is concerned, it is just a file rename, or very occasionally if the
implementation is lousy, a copy followed by delete.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90648

On Fri, May 15, 2015 at 2:09 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> Yes, but sometimes it's at the file system's discretion - particularly
>> when you're working with network mounts. The application may not even
>> know that the file got hard deleted.
>
> Citation needed.
>
> "Move to trash" is a move operation, not an unlink. By definition, it is
> reversible. Which platforms/file systems implements it as an unlink?
>
> (I think the answer is, "broken ones".)

With individual files, you're right that it's broken systems; I do
recall having some setups with network mounts where the "trash"
request was sent over to a remote system and that system, for whatever
reason, chose to delete since it was unable to trash. However, it's
worth noting that a lot of trash cans have strict capacity
limitations, and trashing an entire directory may well result in most
of its content being hard-deleted (or, to be technically correct,
trashed and then purged before the user had a chance to do anything).
And to add insult to injury, some systems (which shall remain
nameless, despite being well known for using UTF-16 file names and
other such anomalies) have such appalling trash-management algorithms
that deleting an entire directory becomes a ridiculously slow
operation - I suspect there's some sort of O(n) linear search being
done for every trashed file, resulting in quadratic performance for
trashing a directory. And when the directory in question is a set of
files that can't usefully be used individually, I'd really rather tell
the application to just hard-delete the whole lot... but that
application didn't even give that option. Anyway.

The main thing is that trashing invites the system to delete the file
at its leisure, so it'll consume disk space and be undeletable for an
unspecified and highly uncertain period of time. If you're depending
on your trash can to protect you, you're just as vulnerable as someone
who depends on disk-level undeletion. There's no solution to that; it
comes down to one of the two hardest problems in computing (cache
management).

ChrisA

[toc] | [prev] | [next] | [standalone]

#90683

On Fri, May 15, 2015, at 00:25, Chris Angelico wrote:
> The main thing is that trashing invites the system to delete the file
> at its leisure,

I've never seen a system whose trash can emptied itself without user
intervention.

[toc] | [prev] | [next] | [standalone]

#90699

On Friday, May 15, 2015 at 11:27:18 AM UTC-7, rand...@fastmail.us wrote:
> On Fri, May 15, 2015, at 00:25, Chris Angelico wrote:
> > The main thing is that trashing invites the system to delete the file
> > at its leisure,
> 
> I've never seen a system whose trash can emptied itself without user
> intervention.

Windows won't empty the entire trash without user intervention, but is IS configured by default to only use up to a specific amount of hard drive space.  Once the trash reaches its capacity, it'll start removing files from it to make room for more.

[toc] | [prev] | [next] | [standalone]

#90684

On Sat, May 16, 2015 at 4:27 AM,  <random832@fastmail.us> wrote:
> On Fri, May 15, 2015, at 00:25, Chris Angelico wrote:
>> The main thing is that trashing invites the system to delete the file
>> at its leisure,
>
> I've never seen a system whose trash can emptied itself without user
> intervention.

They always grow to infinity on your systems? Huh. That's probably the
better option, but I've had to manage Windowses back as far as XP
recently (back as far as W95 but not for many years, fortunately) and
the system would very kindly remove from the trash... I'm fairly sure
the algorithm was either random or outright malicious, but it did
remove stuff.

ChrisA

[toc] | [prev] | [next] | [standalone]

#90620

Steven D'Aprano <steve+comp.lang.python@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?
>
>Would you like to see that in the standard library, even if it meant that
>the library had feature-freeze and could gain no more functionality?

It's bad enough when things are filesystem-dependent but this is
OS-dependent or even desktop-version-dependent in the case of Linux
distros, so not easy.

E.g. in the case of KDE4, the command-line is:
$ kioclient move <filename> trash:/

...and for KDE3 it was:
$ kfmclient  move <filename> trash:/

[toc] | [prev] | [next] | [standalone]

#90623

On 2015-05-14, Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> wrote:
> Steven D'Aprano <steve+comp.lang.python@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?
>>
>>Would you like to see that in the standard library, even if it meant that
>>the library had feature-freeze and could gain no more functionality?
>
> It's bad enough when things are filesystem-dependent but this is
> OS-dependent or even desktop-version-dependent in the case of Linux
> distros, so not easy.

Or even file-manager dependent.  I think some desktops support
multiple file-manager (at least XFCE always used to) -- and there's
probably no requirement that they all handle "trash" the same way. 

For this to work "right" you're going to need to be able to figure out
which desktop you're using: Linux systems often have multiple desktops
available.  Most of mine only have one, but some of them have as many
as three.

Then you might have to determine which file-manager you're using. 
Some of my desktops use file browsers that don't have any concept of
"trash".  And some of them don't have any file-browsers or "trash"
folders at all.

Sounds pretty nasty...

-- 
Grant Edwards               grant.b.edwards        Yow! MMM-MM!!  So THIS is
                                  at               BIO-NEBULATION!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#90625

On Thu, May 14, 2015 at 8:11 PM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2015-05-14, Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> wrote:
>> Steven D'Aprano <steve+comp.lang.python@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?
>>>
>>>Would you like to see that in the standard library, even if it meant that
>>>the library had feature-freeze and could gain no more functionality?
>>
>> It's bad enough when things are filesystem-dependent but this is
>> OS-dependent or even desktop-version-dependent in the case of Linux
>> distros, so not easy.
>
> Or even file-manager dependent.  I think some desktops support
> multiple file-manager (at least XFCE always used to) -- and there's
> probably no requirement that they all handle "trash" the same way.

Actually, there is. There are actual STANDARDS in Linux desktops. One
of them is the Trash Specification:
http://standards.freedesktop.org/trash-spec/trashspec-1.0.html

This spec is implemented by Xfce, KDE, GNOME, PCManFM and probably many others.

And if you are looking for a mostly-compliant Python library/app (and
a shameless plug): https://pypi.python.org/pypi/trashman/1.5.0

-- 
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16

[toc] | [prev] | [next] | [standalone]

#90629

On 05/14/2015 11:43 AM, Chris Warrick wrote:

> And if you are looking for a mostly-compliant Python library/app (and
> a shameless plug): https://pypi.python.org/pypi/trashman/1.5.0

The docs listed link to Package Builder.  How is that related to TrashMan?

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#90639

On Fri, 15 May 2015 03:32 am, Dave Farrance wrote:

> Steven D'Aprano <steve+comp.lang.python@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?
>>
>>Would you like to see that in the standard library, even if it meant that
>>the library had feature-freeze and could gain no more functionality?
> 
> It's bad enough when things are filesystem-dependent but this is
> OS-dependent or even desktop-version-dependent in the case of Linux
> distros, so not easy.
> 
> E.g. in the case of KDE4, the command-line is:
> $ kioclient move <filename> trash:/
> 
> ...and for KDE3 it was:
> $ kfmclient  move <filename> trash:/


I'm not sure if you intend that as a vote in favour or against the idea :-)


The idea is that the library will hide that complexity from you, so your
python code will just say:

import shutil
shutil.move_to_trash(filename)


and it will work on any supported OS, filesystem and desktop.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90641

On 5/14/2015 10:03 PM, Steven D'Aprano wrote:

> The idea is that the library will hide that complexity from you, so your
> python code will just say:
>
> import shutil
> shutil.move_to_trash(filename)

Since 'trash' is (or is used as) a verb, shutil.trash(filename)
seems sufficient.

> and it will work on any supported OS, filesystem and desktop.

This seems like a plausible enhancement.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#90624

On 05/14/2015 08:45 AM, Steven D'Aprano 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?

Never.

> Would you like to see that in the standard library, even if it meant that
> the library had feature-freeze and could gain no more functionality?

Nope.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web