From steve at pearwood.info Thu Jan 1 00:14:19 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 1 Jan 2015 10:14:19 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> Message-ID: <20141231231419.GG24472@ando.pearwood.info> On Wed, Dec 31, 2014 at 11:50:04AM +0100, Andrew Barnert wrote: > On Dec 31, 2014, at 0:47, Steven D'Aprano wrote: > > What's wrong with asking the Finder to move the file? Under what > > circumstances would that be unacceptable? Are there scenarios on OS X > > where the Finder isn't available but the trash is? > > I already answered this briefly earlier in the thread, but in more detail: [...] Thank you for the detailed and extensive answer! -- Steven From ram at rachum.com Thu Jan 1 11:37:55 2015 From: ram at rachum.com (Ram Rachum) Date: Thu, 1 Jan 2015 12:37:55 +0200 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20141231231419.GG24472@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> Message-ID: Hi everyone, I'm a complete ignoramus when it comes to Mac, so I can't say anything about that, but as I understand the discussion, there are problems with implementing this on Mac. Okay. So maybe this should be available only on Windows and Linux? (If it's not a problem to do on Linux.) As much as I don't like having functionality that's only available on certain OSs, it makes more sense than depriving Windows users of functionality that they could be using just because Mac doesn't support it. (And of course, Python has lots of OS-specific modules.) So maybe we can add a function to the `os` module that sends a file to the recycle bin, and a constant that will say whether the current OS supports this? Then we could have code like this: if os.RECYCLE_BIN_SUPPORT: os.recycle(my_file) else: os.remove(my_file) What do you think? Thanks, Ram. On Thu, Jan 1, 2015 at 1:14 AM, Steven D'Aprano wrote: > On Wed, Dec 31, 2014 at 11:50:04AM +0100, Andrew Barnert wrote: > > On Dec 31, 2014, at 0:47, Steven D'Aprano wrote: > > > > What's wrong with asking the Finder to move the file? Under what > > > circumstances would that be unacceptable? Are there scenarios on OS X > > > where the Finder isn't available but the trash is? > > > > I already answered this briefly earlier in the thread, but in more > detail: > [...] > > Thank you for the detailed and extensive answer! > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Thu Jan 1 11:46:37 2015 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 1 Jan 2015 21:46:37 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> Message-ID: On Thu, Jan 1, 2015 at 9:37 PM, Ram Rachum wrote: > As much as I don't like having functionality that's only available on > certain OSs, it makes more sense than depriving Windows users of > functionality that they could be using just because Mac doesn't support it. > (And of course, Python has lots of OS-specific modules.) Most OS-specific stuff is in the os module, but path handling is inherently platform-specific to some extent, so either place would be reasonable. > So maybe we can add a function to the `os` module that sends a file to the > recycle bin, and a constant that will say whether the current OS supports > this? Then we could have code like this: > > if os.RECYCLE_BIN_SUPPORT: > os.recycle(my_file) > else: > os.remove(my_file) > > What do you think? Or: try: delete = os.recycle except AttributeError: delete = os.remove delete(my_file) ChrisA From steve at pearwood.info Thu Jan 1 13:35:26 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 1 Jan 2015 23:35:26 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> Message-ID: <20150101123526.GC15262@ando.pearwood.info> On Thu, Jan 01, 2015 at 12:37:55PM +0200, Ram Rachum wrote: > So maybe we can add a function to the `os` module that sends a file to the > recycle bin, and a constant that will say whether the current OS supports > this? Then we could have code like this: The os module is for low-level operating-system functions. "Send to trash" is neither low-level nor part of the OS per se, it is part of the desktop environment. I'm not convinced that this needs to be in the standard library, but if it is, I think that the os module is completely the wrong place for it. I think, in order of preference: 1) shutil 2) pathlib is the right place. (The actual implementation for the move_to_trash function could come from another, platform-specific, module.) > if os.RECYCLE_BIN_SUPPORT: > os.recycle(my_file) > else: > os.remove(my_file) "Recycle" is not a good name for the function, because it doesn't recycle the file. It does the opposite of recycle: it prevents the file from being deleted and over-written. I think an explicit name like move_to_trash is better than something misleading like "recycle". No need for a special flag to check if the function exists, just check for the function: try: f = shutil.send_to_trash except AttributeError: f = os.remove f(my_file) But I'm still not sure that this needs to be in the standard library. For such a specialist need, what's wrong with using a third party solution? -- Steven From ram at rachum.com Thu Jan 1 13:43:09 2015 From: ram at rachum.com (Ram Rachum) Date: Thu, 1 Jan 2015 14:43:09 +0200 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150101123526.GC15262@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> <20150101123526.GC15262@ando.pearwood.info> Message-ID: I take your point about it not being in the `os` module, I have no issue with it being in shutil or pathlib. I also agree about the name, "recycle" doesn't really make sense. Regarding your question: "But I'm still not sure that this needs to be in the standard library. For such a specialist need, what's wrong with using a third party solution?" Well, I can use a third-party solution for everything, but it would be nicer for me if it was in the standard library because then I could count on it always being there and the API not changing. I could say the same thing you said about the `webbrowser` module, that opening a new browser tab is quite a specialist need, but I do enjoy having it available in the standard library and I feel the same about sending a file to trash, which I think is a basic feature that's we've all been taking for granted for the last decade or two. Happy new year, Ram. On Thu, Jan 1, 2015 at 2:35 PM, Steven D'Aprano wrote: > On Thu, Jan 01, 2015 at 12:37:55PM +0200, Ram Rachum wrote: > > > So maybe we can add a function to the `os` module that sends a file to > the > > recycle bin, and a constant that will say whether the current OS supports > > this? Then we could have code like this: > > The os module is for low-level operating-system functions. "Send to > trash" is neither low-level nor part of the OS per se, it is part of the > desktop environment. > > I'm not convinced that this needs to be in the standard library, but if > it is, I think that the os module is completely the wrong place for it. > I think, in order of preference: > > 1) shutil > 2) pathlib > > is the right place. > > (The actual implementation for the move_to_trash function could come > from another, platform-specific, module.) > > > > if os.RECYCLE_BIN_SUPPORT: > > os.recycle(my_file) > > else: > > os.remove(my_file) > > > "Recycle" is not a good name for the function, because it doesn't > recycle the file. It does the opposite of recycle: it prevents the file > from being deleted and over-written. I think an explicit name like > move_to_trash is better than something misleading like "recycle". > > No need for a special flag to check if the function exists, just check > for the function: > > try: > f = shutil.send_to_trash > except AttributeError: > f = os.remove > f(my_file) > > > But I'm still not sure that this needs to be in the standard library. > For such a specialist need, what's wrong with using a third party > solution? > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam.marsh.home at gmail.com Thu Jan 1 13:47:54 2015 From: liam.marsh.home at gmail.com (Liam Marsh) Date: Thu, 1 Jan 2015 13:47:54 +0100 Subject: [Python-ideas] pep 397 In-Reply-To: References: Message-ID: "I suspect you don't need any changes to the language to make this work" - you are right, this problem does not affect the language itself, but the idlelib library.... - I was thinking of an "pyidle" executable next to the "py" and "pyw" executables. I am also trying to create a small script to do this... 2014-12-30 23:38 GMT+01:00 Chris Angelico : > On Wed, Dec 31, 2014 at 7:31 AM, Liam Marsh > wrote: > > the pep 397 says that any python script is able to choose the language > > version which will run it, between all the versions installed on the > > computer, using on windows a launcher in the "C:\windows" folder. > > > > can the idle version be chosen like this too, or can the idle "run" > command > > do it? > > I don't know of a way off-hand. However, if the information is already > there in the shebang (as per PEP 397), it ought to be possible to rig > up a launcher/chooser script. This might be something to discuss on > python-list at python.org, rather than here; there are a lot more people > on python-list than there are here on -ideas, and I suspect you don't > need any changes to the language to make this work. > > It's also entirely possible that someone there already knows exactly > what you need to do! > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus at unterwaditzer.net Thu Jan 1 13:47:15 2015 From: markus at unterwaditzer.net (Markus Unterwaditzer) Date: Thu, 1 Jan 2015 13:47:15 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150101123526.GC15262@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> <20150101123526.GC15262@ando.pearwood.info> Message-ID: <20150101124715.GA7009@chromebot.lan> On Thu, Jan 01, 2015 at 11:35:26PM +1100, Steven D'Aprano wrote: > On Thu, Jan 01, 2015 at 12:37:55PM +0200, Ram Rachum wrote: > > > So maybe we can add a function to the `os` module that sends a file to the > > recycle bin, and a constant that will say whether the current OS supports > > this? Then we could have code like this: > > The os module is for low-level operating-system functions. "Send to > trash" is neither low-level nor part of the OS per se, it is part of the > desktop environment. > > I'm not convinced that this needs to be in the standard library, but if > it is, I think that the os module is completely the wrong place for it. > I think, in order of preference: > > 1) shutil > 2) pathlib > > is the right place. Maybe the right way to do this is to create a new module, stdlib or not, for desktop-related APIs. Besides a `recycle` function this might, for example, include a subset of pyxdg's functionality. -- Markus From rosuav at gmail.com Thu Jan 1 14:27:18 2015 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 2 Jan 2015 00:27:18 +1100 Subject: [Python-ideas] pep 397 In-Reply-To: References: Message-ID: On Thu, Jan 1, 2015 at 11:47 PM, Liam Marsh wrote: > "I suspect you don't > need any changes to the language to make this work" > > - you are right, this problem does not affect the language itself, but the > idlelib library.... > - I was thinking of an "pyidle" executable next to the "py" and "pyw" > executables. > I am also trying to create a small script to do this... A small script ought to be able to handle it. All it needs to do is: 1) Read in the first line of the file. 2) See if it can be parsed according to PEP 397 3) Invoke IDLE. Since this is primarily for your own personal use, rather than being a part of the language or standard library, you could make a few assumptions - for instance, assume an ASCII-compatible file encoding, assume that it won't get any arguments other than the script to open, anything else that'll make your life easier. Knock something together, and if you have trouble with the details, python-list will undoubtedly be willing to help out. All the best! ChrisA From abarnert at yahoo.com Thu Jan 1 16:37:52 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 1 Jan 2015 16:37:52 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> Message-ID: On Jan 1, 2015, at 11:37, Ram Rachum wrote: > Hi everyone, > > I'm a complete ignoramus when it comes to Mac, so I can't say anything about that, but as I understand the discussion, there are problems with implementing this on Mac. Okay. So maybe this should be available only on Windows and Linux? (If it's not a problem to do on Linux.) On Linux, it's not exactly like Mac, but it's similar. Linux has no notion of trash at all; desktop environments like GNOME do. And if you want it to work exactly like the way GNOME does, you call the API via GObject; otherwise you have to implement a complicated approximation based on rename that won't be fully functional. Really, on all three platforms, the answer is the same: you call an API from your desktop manager. The only difference is that Windows merges desktop and kernel together to the point where they can't be separated--so Python is already using Win32, unlike Cocoa or GObject. > As much as I don't like having functionality that's only available on certain OSs, it makes more sense than depriving Windows users of functionality that they could be using just because Mac doesn't support it. No one is "depriving" Windows users of anything. Python comes with pip, send2trash installs without needing a compiler (at least I hope so; if not, someone can write a new third-party module that does). Not everything needs to be in the stdlib. So far, there aren't many third-party modules mentioned in the stdlib docs, but that's only because we didn't have preinstalled pip, wheels, etc. until 3.4. > (And of course, Python has lots of OS-specific modules.) > > So maybe we can add a function to the `os` module that sends a file to the recycle bin, and a constant that will say whether the current OS supports this? Then we could have code like this: > > if os.RECYCLE_BIN_SUPPORT: > os.recycle(my_file) > else: > os.remove(my_file) > > What do you think? There's no such flag for anything else platform-contingent. EAFP. > > > Thanks, > Ram. > > On Thu, Jan 1, 2015 at 1:14 AM, Steven D'Aprano wrote: >> On Wed, Dec 31, 2014 at 11:50:04AM +0100, Andrew Barnert wrote: >> > On Dec 31, 2014, at 0:47, Steven D'Aprano wrote: >> >> > > What's wrong with asking the Finder to move the file? Under what >> > > circumstances would that be unacceptable? Are there scenarios on OS X >> > > where the Finder isn't available but the trash is? >> > >> > I already answered this briefly earlier in the thread, but in more detail: >> [...] >> >> Thank you for the detailed and extensive answer! >> >> >> -- >> Steven >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Thu Jan 1 16:54:59 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 1 Jan 2015 16:54:59 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150101124715.GA7009@chromebot.lan> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> <20150101123526.GC15262@ando.pearwood.info> <20150101124715.GA7009@chromebot.lan> Message-ID: <78E3056F-D649-4777-9755-6CBEF5598CA1@yahoo.com> On Jan 1, 2015, at 13:47, Markus Unterwaditzer wrote: > On Thu, Jan 01, 2015 at 11:35:26PM +1100, Steven D'Aprano wrote: >> On Thu, Jan 01, 2015 at 12:37:55PM +0200, Ram Rachum wrote: >> >>> So maybe we can add a function to the `os` module that sends a file to the >>> recycle bin, and a constant that will say whether the current OS supports >>> this? Then we could have code like this: >> >> The os module is for low-level operating-system functions. "Send to >> trash" is neither low-level nor part of the OS per se, it is part of the >> desktop environment. >> >> I'm not convinced that this needs to be in the standard library, but if >> it is, I think that the os module is completely the wrong place for it. >> I think, in order of preference: >> >> 1) shutil >> 2) pathlib >> >> is the right place. > > Maybe the right way to do this is to create a new module, stdlib or not, for > desktop-related APIs. Besides a `recycle` function this might, for example, > include a subset of pyxdg's functionality. That's a great idea. To do something as simple as getting special directory names or creating a shortcut/alias/bookmark (as opposed to a symlink) or, yes, trashing a file in a cross-platform way requires something way too heavy-duty (like Qt or JUCE)... or copying code off some blog (that doesn't actually work on localized Windows or in a sandboxed OS X app or on non-Debianish Linux, but you won't know that until you think to test it). A third-party module can get away with 90% support. Most Mac users are on 10.8+, most apps don't fork, most Linux users who care about the desktop have a GNOME-compatible one; etc. > > -- Markus > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From markus at unterwaditzer.net Thu Jan 1 17:00:52 2015 From: markus at unterwaditzer.net (Markus Unterwaditzer) Date: Thu, 1 Jan 2015 17:00:52 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

Message-ID: <20150101160052.GA8524@chromebot.lan> On Thu, Jan 01, 2015 at 04:37:52PM +0100, Andrew Barnert wrote: > On Jan 1, 2015, at 11:37, Ram Rachum wrote: > > > Hi everyone, > > > > I'm a complete ignoramus when it comes to Mac, so I can't say anything > > about that, but as I understand the discussion, there are problems with > > implementing this on Mac. Okay. So maybe this should be available only on > > Windows and Linux? (If it's not a problem to do on Linux.) > > On Linux, it's not exactly like Mac, but it's similar. Linux has no notion of > trash at all; desktop environments like GNOME do. And if you want it to work > exactly like the way GNOME does, you call the API via GObject; otherwise you > have to implement a complicated approximation based on rename that won't be > fully functional. Actually it seems that the trash location is standardized by the XDG Desktop Specification: https://github.com/kevva/xdg-trash http://www.ramendik.ru/docs/trashspec.html From abarnert at yahoo.com Thu Jan 1 23:59:59 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 1 Jan 2015 23:59:59 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150101160052.GA8524@chromebot.lan> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

<20150101160052.GA8524@chromebot.lan> Message-ID: On Jan 1, 2015, at 17:00, Markus Unterwaditzer wrote: > On Thu, Jan 01, 2015 at 04:37:52PM +0100, Andrew Barnert wrote: >> On Jan 1, 2015, at 11:37, Ram Rachum wrote: >> >>> Hi everyone, >>> >>> I'm a complete ignoramus when it comes to Mac, so I can't say anything >>> about that, but as I understand the discussion, there are problems with >>> implementing this on Mac. Okay. So maybe this should be available only on >>> Windows and Linux? (If it's not a problem to do on Linux.) >> >> On Linux, it's not exactly like Mac, but it's similar. Linux has no notion of >> trash at all; desktop environments like GNOME do. And if you want it to work >> exactly like the way GNOME does, you call the API via GObject; otherwise you >> have to implement a complicated approximation based on rename that won't be >> fully functional. > > Actually it seems that the trash location is standardized by the XDG Desktop > Specification: > > https://github.com/kevva/xdg-trash > http://www.ramendik.ru/docs/trashspec.html Yes, as I just said: Linux has no notion of trash; desktop environments do. The FreeDesktop standard is not Linux; it's a standard that at least two desktop environments (which also work on multiple non-Linux systems) support. On most Linux systems, you will have Gtk libraries; on most Linux systems without Gtk libraries, you will not have a FreeDesktop-compliant trash. So, using GObject is a good 90% solution (like using NSFileManager is a good 90% solution on Mac). Of course you _could_ implement that full spec yourself in Python, right? Well, read it. There are references to things "the implementation" may do, like providing a way for the administrator to disable sticky-bit checking for filesystems that don't support it. Do you know how to check whether the administrator has disabled sticky-bit checking on a filesystem? Or do you just want your code to say a file can't be trashed, or trash by moving it across the network to ~, even when the desktop and other apps have no problem trashing it properly? For that matter, do you know how every FreeDesktop-compatible system wants to report a problem to the administrator? You may meet the XDG Trash spec and still not satisfy user expectations. And it'll be a lot of work. In other words, "you have to implement a complicated approximation based on rename that won't be fully functional". Is that really a better solution than using GObject? If you're writing your own portability library like Qt or JUCE, probably; otherwise, I doubt it. From steve at pearwood.info Fri Jan 2 01:09:14 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 2 Jan 2015 11:09:14 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> <20150101123526.GC15262@ando.pearwood.info> Message-ID: <20150102000913.GD15262@ando.pearwood.info> On Thu, Jan 01, 2015 at 02:43:09PM +0200, Ram Rachum wrote: > Regarding your question: "But I'm still not sure that this needs to be in > the standard library. For such a specialist need, what's wrong with using a > third party solution?" > > Well, I can use a third-party solution for everything, but it would be > nicer for me if it was in the standard library because then I could count > on it always being there and the API not changing. Which is exactly the point. It has been said that the standard library is where good modules go to die. Do you think that the "move to trash" API is ready to die? I don't think so. I think that there is a lot more than just moving files to the trash. I've spent a little bit of time over the last day or so thinking about what sort of trash-related functionality I would like, as a Linux user: - move to trash, of course, but which trash? - return the name of the trash directory in my home directory - list trash directories on other partitions and disks - list trash directories for all users (if I have read permission) - empty one or more of those trash directories - optionally only deleting sufficiently old and/or large files - validate and/or repair the trash metadata - report how much space is used by the trash, with or without metadata - support legacy .Trash directories as well as .local/share/Trash For some operations, I would want to specify either a specific trash directory, or all trash directories for a given user (defaulting to the current user), or all trash directories for all users. (The later would only work if I was running as the root/Administrator user, of course.) The point being that the API for all this functionality isn't obvious, and it is very unlikely to be so stable that it is ready to move into the standard library. -- Steven From random832 at fastmail.us Fri Jan 2 14:24:26 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 02 Jan 2015 08:24:26 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

Message-ID: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> On Tue, Dec 30, 2014, at 18:12, Andrew Barnert wrote: > By "suitable" I mean "suitable for widespread-enough use that it should > be in the stdlib". As I said earlier in the thread, I think it's > perfectly reasonable to have a third-party library that uses a deprecated > API, requires 10.8, requires a runloop, directly or indirectly asks the > Finder to do the work for you, or doesn't quite meet Apple's HIG rules, > because all of those could be acceptable in _many_ applications; I just > don't think any of those should be in the stdlib, because none of those > are acceptable in _most_ applications. Not having one isn't acceptable either. Because what _not_ having a cross-platform wrapper gets you is windows and mac left behind by applications with badly-written direct implementations of the way you do it on Unix. Can you define "doesn't quite meet Apple's HIG" rules and link the relevant section of the HIG? From random832 at fastmail.us Fri Jan 2 14:30:43 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 02 Jan 2015 08:30:43 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150101123526.GC15262@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info> <20150101123526.GC15262@ando.pearwood.info> Message-ID: <1420205443.2838218.208808325.450952DE@webmail.messagingengine.com> On Thu, Jan 1, 2015, at 07:35, Steven D'Aprano wrote: > The os module is for low-level operating-system functions. "Send to > trash" is neither low-level nor part of the OS per se, it is part of the > desktop environment. What is the correct place for high-level functions that need to be implemented in a different way on each OS? I think the problem is that some people view os as "low-level functions, like the ones found in unistd.h" and other people view it as "where to put stuff that needs a separate implementation per platform". The actual description in the documentation is "This module provides a portable way of using operating system dependent functionality." Nothing about low-level. From random832 at fastmail.us Fri Jan 2 14:36:24 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 02 Jan 2015 08:36:24 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

Message-ID: <1420205784.2839657.208808873.1C78CB92@webmail.messagingengine.com> On Thu, Jan 1, 2015, at 10:37, Andrew Barnert wrote: > On Linux, it's not exactly like Mac, but it's similar. Linux has no > notion of trash at all; desktop environments like GNOME do. And if you > want it to work exactly like the way GNOME does, you call the API via > GObject; otherwise you have to implement a complicated approximation > based on rename that won't be fully functional. There is an actual standard for the Trash system that all three major desktop environments implement, so your "complicated approximation based on rename" can actually be correct rather than an approximation. If that's not exactly like how GNOME does it, then GNOME is incorrect. From random832 at fastmail.us Fri Jan 2 14:43:44 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 02 Jan 2015 08:43:44 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

<20150101160052.GA8524@chromebot.lan> Message-ID: <1420206224.2842545.208810201.5532DB2B@webmail.messagingengine.com> On Thu, Jan 1, 2015, at 17:59, Andrew Barnert wrote: > Of course you _could_ implement that full spec yourself in Python, right? > Well, read it. There are references to things "the implementation" may > do, like providing a way for the administrator to disable sticky-bit > checking for filesystems that don't support it. Do you know how to check > whether the administrator has disabled sticky-bit checking on a > filesystem? A python implementation would be an independent implementation, and not bound by another implementation's (even on the same machine) implementation-specific decisions. There is therefore no reason the python implementation couldn't simply not provide such a method, and therefore any .Trash directory without the sticky bit set does not pass the checks, and all that will happen is .Trash-$uid gets used instead - no harm done. From ncoghlan at gmail.com Fri Jan 2 19:40:52 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 3 Jan 2015 04:40:52 +1000 Subject: [Python-ideas] python on mobile In-Reply-To: References:

<87k31833vw.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 31 December 2014 at 13:42, Russell Keith-Magee wrote: > > > On Wed, Dec 31, 2014 at 11:16 AM, Stephen J. Turnbull > wrote: >> >> Fetchinson . writes: >> >> > > I'm not sure exactly what would be discussed [on mobile-sig], >> > > especially in the short term when the big ticket item is getting >> > > the patches into the main Python tree. >> >> It probably matters more that there *is* substantive discussion than >> *what* is discussed. There are probably a lot of people who are far >> more interested in "how to do 'it' *now*" than "get 'it' into the main >> Python tree 'someday'", for example. >> > > I'm not sure if a mailing list would help with this as much as a good, > simple set of docs. It's not like there's unknown territory here; once > you've got Python installed on a mobile device, the "how" is reasonably > easy. The catch is that someone with Python experience won't necessarily > have experience managing a cross-platform C/Automake build, which is what > you need to get Python installed in the first place. > One of the benefits of a SIG over python-ideas is that their remit can be broader than just CPython. distutils-sig is probably the most expansive on that front, but As far as setting one up goes, I believe the page at https://www.python.org/community/sigs/guidelines/ is still accurate (although the blurb isn't quite right when it comes to long lived topical sigs like distutils-sig, or intermittently active sigs like import-sig) Although it's a couple of months off, I would suggest a talk (if it's >> still possible to schedule), a BOF, and a sprint at Pycon North >> America in March. That should get things moving, and several of the >> "important" folks who have already expressed interest should be there, >> too. >> > > Unfortunately, due to the tyranny of distance (I'm based on the west coast > of Australia), plus work commitments, it's unlikely that I'll be attending > PyCon in Montreal. > Will you be at LCA this year? At the very least we can continue the various discussions from PyCon AU :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Fri Jan 2 20:46:51 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Fri, 2 Jan 2015 20:46:51 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> Message-ID: <11C6719F-3F28-4311-966E-CFEA6CD10467@yahoo.com> On Jan 2, 2015, at 14:24, random832 at fastmail.us wrote: > On Tue, Dec 30, 2014, at 18:12, Andrew Barnert wrote: >> By "suitable" I mean "suitable for widespread-enough use that it should >> be in the stdlib". As I said earlier in the thread, I think it's >> perfectly reasonable to have a third-party library that uses a deprecated >> API, requires 10.8, requires a runloop, directly or indirectly asks the >> Finder to do the work for you, or doesn't quite meet Apple's HIG rules, >> because all of those could be acceptable in _many_ applications; I just >> don't think any of those should be in the stdlib, because none of those >> are acceptable in _most_ applications. > > Not having one isn't acceptable either. Because what _not_ having a > cross-platform wrapper gets you is windows and mac left behind by > applications with badly-written direct implementations of the way you do > it on Unix. I'm not sure what "the way you do it on Unix" means. There is no Unix/POSIX/etc. notion of trashing a file. Of course some Unix desktop environments (going back at least as far as NeXTStep) have had such a thing, but that can't be what you mean. If you're referring to XDG, I don't know of a single application that uses a badly-written direct implementation of the XDG trash spec on Mac or Windows. Do you? More importantly, which of those other options do you think is better than continuing to have no trash API? Drop 10.6-10.7 compat? Use a deprecated API and break Mac App Store compatibility? Require all scripts to have a runloop? > Can you define "doesn't quite meet Apple's HIG" rules and link the > relevant section of the HIG? Of course not, because I have no idea what exactly you'd write in place of calling the appropriate API. Give me a design or some code, and I'll tell you what it does wrong. From abarnert at yahoo.com Fri Jan 2 21:01:08 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Fri, 2 Jan 2015 21:01:08 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420205784.2839657.208808873.1C78CB92@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

<1420205784.2839657.208808873.1C78CB92@webmail.messagingengine.com> Message-ID: On Jan 2, 2015, at 14:36, random832 at fastmail.us wrote: > On Thu, Jan 1, 2015, at 10:37, Andrew Barnert wrote: >> On Linux, it's not exactly like Mac, but it's similar. Linux has no >> notion of trash at all; desktop environments like GNOME do. And if you >> want it to work exactly like the way GNOME does, you call the API via >> GObject; otherwise you have to implement a complicated approximation >> based on rename that won't be fully functional. > > There is an actual standard for the Trash system that all three major > desktop environments implement, so your "complicated approximation based > on rename" can actually be correct rather than an approximation. If > that's not exactly like how GNOME does it, then GNOME is incorrect. First, XDG specifications are explicitly not standards (and XDG Trash is a draft extension proposal to those specs) so there is not an actual standard. But, far more importantly, there are large areas that the spec leaves open to the implementation, or open for future expansion, that GNOME (and KDE) fills in with appropriate behavior. I gave one example earlier in the thread, which I picked by pointing my finger at one random paragraph from the spec. If you read through it, there are plenty of others. If you call the APIs via GObject or Qt on a GNOME or KDE system, you will get the exact same behavior as everything else on the system. If you implement it yourself and ignore what GNOME and KDE do, nobody's going to care that you're 100% compliant with a draft spec proposal, they're going to care that your app refuses to trash something that everything else can trash (or, worse, that your app trashes it by copying 8GB over the network). From abarnert at yahoo.com Fri Jan 2 21:05:51 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Fri, 2 Jan 2015 21:05:51 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420206224.2842545.208810201.5532DB2B@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

<20150101160052.GA8524@chromebot.lan> <1420206224.2842545.208810201.5532DB2B@webmail.messagingengine.com> Message-ID: <73AA04B8-4D4A-4626-8381-9A071C78EA5B@yahoo.com> On Jan 2, 2015, at 14:43, random832 at fastmail.us wrote: > On Thu, Jan 1, 2015, at 17:59, Andrew Barnert wrote: >> Of course you _could_ implement that full spec yourself in Python, right? >> Well, read it. There are references to things "the implementation" may >> do, like providing a way for the administrator to disable sticky-bit >> checking for filesystems that don't support it. Do you know how to check >> whether the administrator has disabled sticky-bit checking on a >> filesystem? > > A python implementation would be an independent implementation, and not > bound by another implementation's (even on the same machine) > implementation-specific decisions. Then a Python implementation would be a bad implementation. The whole point of XDG is to make it easier to write desktop software that's consistent with other desktop software. So if you write some Qt software and I run it on a GNOME system, Qt follows (as best it can--which is better each version) the GNOME rules, and your GNOME-based settings, rather than ignoring them and pretending it's on a KDE system. > There is therefore no reason the > python implementation couldn't simply not provide such a method, and > therefore any .Trash directory without the sticky bit set does not pass > the checks, and all that will happen is .Trash-$uid gets used instead - > no harm done. Except that if you can't create a .Trash-$uid, then you can't trash files on that filesystem even though Nautilus, etc. can. (And, needless to say, if you try to implement any other trash functionality, like listing trash contents or undeleting, you're going to be wrong there too.) From ncoghlan at gmail.com Sat Jan 3 02:36:01 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 3 Jan 2015 11:36:01 +1000 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <73AA04B8-4D4A-4626-8381-9A071C78EA5B@yahoo.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<20141230234702.GE24472@ando.pearwood.info> <20141231231419.GG24472@ando.pearwood.info>

<20150101160052.GA8524@chromebot.lan> <1420206224.2842545.208810201.5532DB2B@webmail.messagingengine.com> <73AA04B8-4D4A-4626-8381-9A071C78EA5B@yahoo.com> Message-ID: On 3 Jan 2015 06:06, "Andrew Barnert" wrote: > > Except that if you can't create a .Trash-$uid, then you can't trash files on that filesystem even though Nautilus, etc. can. (And, needless to say, if you try to implement any other trash functionality, like listing trash contents or undeleting, you're going to be wrong there too.) It sounds to me that what is needed before changes to pathlib can be discussed is a reference third party module that appropriately respects desktop conventions (whether Windows, Mac OS X, GNOME, KDE, or other XDG based Linux window manager), and associated clear documentation on how to delete files in a way that integrates well with underlying platforms. The standard library isn't the place to work through that standardisation activity, although a PEP is certainly a reasonable place to track it. Guido's work on PEP 3156 and the asnycio module is a good point of reference here, as is Antoine's work on pathlib itself. Once a pathlib independent reference implementation of imperative desktop trash management exists, and there is broad acknowledgement that it is a suitable candidate for inclusion in the standard library (perhaps as part of shutil, perhaps as a new independent module, depending on API complexity), *then* it becomes feasible to discuss adding trash management support to the pathlib abstraction layer. Regards, Nick. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Jan 3 02:50:45 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 3 Jan 2015 12:50:45 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> Message-ID: <20150103015045.GB27426@ando.pearwood.info> On Fri, Jan 02, 2015 at 08:24:26AM -0500, random832 at fastmail.us wrote: > Not having one [move to trash function] isn't acceptable either. I'm not sure about that. Do other languages offer a move-to-trash functionality? Say, PHP, Javascript, Java, Ruby, Boo, Go, Lua? If Python is the odd one out that DOESN'T offer such functionality, and all the others do, then you might have a strong case. Otherwise, consider that the great bulk of scripts that are written in Python don't do any file management at all, other than perhaps reading or writing a few files. So even if Python gained this functionality, it wouldn't have any impact on most scripts and applications.[1] > Because what _not_ having a > cross-platform wrapper gets you is windows and mac left behind Really? I would expect that Windows is probably the *easiest* platform to implement this functionality, as it has a single, standard, stable API for moving files to trash. (Or so I am lead to believe.) You can probably use that API via ctypes, or via pywin32. Getting OS X right is very complicated, as Andrew has so ably explained. In Linux and other Unixes, the situation is like OS X, only more so since there's no one single authority. You have a choice of desktop environments, which may or may not provide a move-to-trash API, including no desktop environment at all. Gnome provides an API for moving to trash, but I don't know how well it supports the freedesktop standard; KDE supports the freedesktop standard, but I don't know if it provides an API that can be called. XFCE has partial support. It seems to me that "move to trash" is at least straight forward on Windows, but tricky and complicated everywhere else. Or, there is always the option of using a third-party module: https://pypi.python.org/pypi/Send2Trash [1] With one possible exception. If Andrew is correct, then the wrong implementation of move-to-trash might effect in a bad way anyone trying to put their app on the Apple Store, whether they use that move-to-trash functionality or not. -- Steve From rosuav at gmail.com Sat Jan 3 03:18:24 2015 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 3 Jan 2015 13:18:24 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150103015045.GB27426@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> Message-ID: On Sat, Jan 3, 2015 at 12:50 PM, Steven D'Aprano wrote: > Otherwise, consider that the great bulk of scripts that are written in > Python don't do any file management at all, other than perhaps reading > or writing a few files. So even if Python gained this functionality, it > wouldn't have any impact on most scripts and applications.[1] I've always thought of a trash can as an inherently human-controlled feature. When you go in using a GUI file manager and delete a file, it lands in trash. When you use another application, it's always felt surprising - for instance, BitTorrent on Windows deletes things by moving them to trash. (Which has abysmal performance if you select a huge bunch of things and wipe them all out at once; trashing gobs of stuff across thousands of files seems to trigger an O(N*N) repeated search for which files "fall out" of trash - not to mention that this probably means a fairly arbitrary subset of the freshly-deleted is in trash, and little or nothing from previous deletions remains.) Most apps should do file management at the file system level, unless they're specifically replicating/replacing the file manager. So a "move to trash" feature is something that (a) isn't going to be needed by most apps, and especially (b) would be an attractive nuisance. A third-party module has that extra little hump of having to be consciously sought, so it can be there for those who want it but not waving itself around at those who really should be looking at os.remove(). I'm -0.5 on adding a "move to trash" function to the stdlib, ever, and a definite -1 on adding one now. ChrisA From breamoreboy at yahoo.co.uk Sat Jan 3 09:07:47 2015 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sat, 03 Jan 2015 08:07:47 +0000 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> Message-ID: On 03/01/2015 02:18, Chris Angelico wrote: > On Sat, Jan 3, 2015 at 12:50 PM, Steven D'Aprano wrote: >> Otherwise, consider that the great bulk of scripts that are written in >> Python don't do any file management at all, other than perhaps reading >> or writing a few files. So even if Python gained this functionality, it >> wouldn't have any impact on most scripts and applications.[1] > > I've always thought of a trash can as an inherently human-controlled > feature. As, for example, holding down the SHIFT key on Windows and skipping the recycle bin completely? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence From rosuav at gmail.com Sat Jan 3 09:10:55 2015 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 3 Jan 2015 19:10:55 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> Message-ID: On Sat, Jan 3, 2015 at 7:07 PM, Mark Lawrence wrote: > On 03/01/2015 02:18, Chris Angelico wrote: >> >> On Sat, Jan 3, 2015 at 12:50 PM, Steven D'Aprano >> wrote: >>> >>> Otherwise, consider that the great bulk of scripts that are written in >>> Python don't do any file management at all, other than perhaps reading >>> or writing a few files. So even if Python gained this functionality, it >>> wouldn't have any impact on most scripts and applications.[1] >> >> >> I've always thought of a trash can as an inherently human-controlled >> feature. > > As, for example, holding down the SHIFT key on Windows and skipping the > recycle bin completely? That's a human deciding _not_ to use it; but yes, it should be under human control. ChrisA From abarnert at yahoo.com Sat Jan 3 11:28:52 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 3 Jan 2015 11:28:52 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> Message-ID: <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> On Jan 3, 2015, at 3:18, Chris Angelico wrote: > On Sat, Jan 3, 2015 at 12:50 PM, Steven D'Aprano wrote: >> Otherwise, consider that the great bulk of scripts that are written in >> Python don't do any file management at all, other than perhaps reading >> or writing a few files. So even if Python gained this functionality, it >> wouldn't have any impact on most scripts and applications.[1] > > I've always thought of a trash can as an inherently human-controlled > feature. I think this may be an accident of the fact that cmd.exe didn't include a trash command, neither did OS X, and the idea was dropped from xdg-trash; we've all been trained for a couple decades now that you can't trash from the command line. I'm not sure that's a good thing. But it is nevertheless a thing that can't be ignored. > When you go in using a GUI file manager and delete a file, it > lands in trash. When you use another application, it's always felt > surprising In some GUI applications, it does make sense to trash things via a menu or other user interaction. (Except maybe when you're using Apple's versions/history thingy or some similar mechanism.) One of the things Aquamacs adds to the standard emacs distribution is a move-to-trash command that you can use in diredit mode, for example. Although I guess you could argue that counts as "unless you're replacing the file manager", and maybe the same is true of most other such examples... But not all. When I worked on TuneUp, we had a feature to move selected duplicate tracks from quarantine to trash, which I thought was stupid and unnecessary (the quarantine folder is already effectively an app-level trash can...). But when we removed it, we got hundreds of user complaints, and a nasty blog post saying we were trying to deliberately destroy out users' music collections on behalf of the RIAA or something. And: > for instance, BitTorrent on Windows deletes things by > moving them to trash. (Which has abysmal performance if you select a > huge bunch of things and wipe them all out at once; trashing gobs of > stuff across thousands of files seems to trigger an O(N*N) repeated > search for which files "fall out" of trash - not to mention that this > probably means a fairly arbitrary subset of the freshly-deleted is in > trash, and little or nothing from previous deletions remains.) The Mac version also does the move-to-trash; it has perfectly acceptable performance. (Actually, old versions were terribly slow at trashing a torrent with a lot of top-level files or dirs, but newer versions seem to do a single operation per torrent instead, which works fine.) And I'm actually glad it does this. At least twice, I've downloaded an ISO, mounted it, then trashed the torrent with all files; if they were deleted instead of trashed, I would have had to repeat the download to update my VMs... You could argue that I'm an idiot for doing this, and you'd be right, but I'm probably not the only such idiot; in fact, that's kind of what trash is for in the first place. > Most > apps should do file management at the file system level, unless > they're specifically replicating/replacing the file manager. So a > "move to trash" feature is something that (a) isn't going to be needed > by most apps, and especially (b) would be an attractive nuisance. A > third-party module has that extra little hump of having to be > consciously sought, so it can be there for those who want it but not > waving itself around at those who really should be looking at > os.remove(). I agree with this, but it still might be nice to mention that third-party module in shutil and/or pathlib. Whether that's send2trash or a complete trash management module as Steven (I think?) envisioned or a reference to the platform APIs and the various ways to get at them, it would be useful. (In fact, some prominent reference to PyWin32, PyObjC, GObject, and PyQt/PySide for non-GUI-but-still-desktop apps in the docs might be helpful for lots of reasons.) Honestly, I think one of the big things people want is the ability to write the "trash" tool for use on the command line that all of the major desktop systems are missing. It feels like it should be a 3-line Python script, and the fact that it isn't possible looks like a weakness. But really, I don't think that's a problem. OS X comes with a Python with PyObjC; a GNOME or KDE system can install python-gobject or PySide in one apt-get/urpmi/port/etc. command; Windows' function is accessible via the built-in ctypes. I have such scripts on my Mac and Fedora boxes; the fact that they're _different_ 3-line scripts is hardly a serious problem. From rosuav at gmail.com Sat Jan 3 11:39:46 2015 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 3 Jan 2015 21:39:46 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> Message-ID: On Sat, Jan 3, 2015 at 9:28 PM, Andrew Barnert wrote: > The Mac version also does the move-to-trash; it has perfectly acceptable performance. > Good. The note about performance was a mere parenthesis, and the last time I did anything like that on Windows was on XP, so it's quite possibly different on Win7/8. > I agree with this, but it still might be nice to mention that third-party module in shutil and/or pathlib. > Maybe. Is there a mention of other third-party packages in stdlib docs? It's a slippery slope; which ones deserve mention? Maybe just something like "Note that moving objects to the trash can is possible in OS-dependent ways; packages are available on PyPI to make this easier", without naming any. > Honestly, I think one of the big things people want is the ability to write the "trash" tool for use on the command line that all of the major desktop systems are missing. It feels like it should be a 3-line Python script, and the fact that it isn't possible looks like a weakness. But really, I don't think that's a problem. OS X comes with a Python with PyObjC; a GNOME or KDE system can install python-gobject or PySide in one apt-get/urpmi/port/etc. command; Windows' function is accessible via the built-in ctypes. I have such scripts on my Mac and Fedora boxes; the fact that they're _different_ 3-line scripts is hardly a serious problem. > As an explicit "trash" tool, sure. Typing "trash some_file" is under human control just as much as hitting Delete without holding Shift is. I just don't think it should be the obvious way for an application to remove files. ChrisA From abarnert at yahoo.com Sat Jan 3 12:04:24 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 3 Jan 2015 12:04:24 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> Message-ID: <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> On Jan 3, 2015, at 11:39, Chris Angelico wrote: > On Sat, Jan 3, 2015 at 9:28 PM, Andrew Barnert wrote: >> I agree with this, but it still might be nice to mention that third-party module in shutil and/or pathlib. > > Maybe. Is there a mention of other third-party packages in stdlib > docs? It's a slippery slope; which ones deserve mention? Maybe just > something like "Note that moving objects to the trash can is possible > in OS-dependent ways; packages are available on PyPI to make this > easier", without naming any. The impression I get is that this is a slope that Python (or at least Nick Coghlan) wants to start sliding down--with the advent of wheels and pre-installed pip, keeping things out of the stdlib but still accessible for most users is now possible, and often desirable. But I could be putting words (or complete ideas) in people's mouths. From tomirendo at gmail.com Sat Jan 3 14:37:03 2015 From: tomirendo at gmail.com (yotam vaknin) Date: Sat, 3 Jan 2015 15:37:03 +0200 Subject: [Python-ideas] Slicing and Chainging iterables. Message-ID: I would like to purpose that in python 3 it will be easy to chain and slice Iterators just like you can add and slice lists and tuples easily. I think there could be 2 methods to do this: 1. Implementing '+' and slicing ([1:2:3]) for iterators and generators by default, Resulting in Itertool's chain(a,b) and islice(a,b,c) respectively. 2. Having itertool's chain and islice imported by default. I think since python 3 return zip,map, dict.items and so on as iterators, it makes working with those kind of objects more difficult without having these methods around. And since those methods are important enough to have for lists, it seems important enough for iterators too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Jan 3 16:28:44 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 4 Jan 2015 02:28:44 +1100 Subject: [Python-ideas] Slicing and Chainging iterables. In-Reply-To: References: Message-ID: <20150103152844.GG27426@ando.pearwood.info> On Sat, Jan 03, 2015 at 03:37:03PM +0200, yotam vaknin wrote: > I would like to purpose that in python 3 it will be easy to chain and slice > Iterators just like you can add and slice lists and tuples easily. > > I think there could be 2 methods to do this: > 1. Implementing '+' and slicing ([1:2:3]) for iterators and generators by > default, Resulting in Itertool's chain(a,b) and islice(a,b,c) respectively. > 2. Having itertool's chain and islice imported by default. The iterator protocol is intentionally simple. To create an iterator, you need to only define two methods: (1) __iter__, which returns the instance itself; (2) __next__, which returns the next item and raises StopIterator when done. With your proposal, you would have to define two or three more methods: (3) __add__ and possibly __radd__, to chain iterators; (4) __getitem__, for slicing. There is nothing stopping you from adding these methods to your own iterator classes, but with your proposal that would be compulsory for all iterators. > I think since python 3 return zip,map, dict.items and so on as iterators, > it makes working with those kind of objects more difficult without having > these methods around. And since those methods are important enough to have > for lists, it seems important enough for iterators too. It only takes a single line of code to get iterator chaining and slicing: from itertools import chain, islice And now you can chain and slice any iterator, regardless of where it came from. I don't think that is difficult. *If* iterators where instances of a concrete base class, then it would make sense to add chain and slice methods to that base class so all other iterators could inherit from it. But they aren't, iterators in Python are values which obey a protocol, not inheritence. That means that a functional approach, like itertools, is more appropriate. I can see the appeal of using + and [a:b:c] syntax instead of function syntax chain() and islice(), but I don't think the advantage is enough to out-weigh the costs. -- Steve From tomirendo at gmail.com Sat Jan 3 16:53:12 2015 From: tomirendo at gmail.com (yotam vaknin) Date: Sat, 3 Jan 2015 17:53:12 +0200 Subject: [Python-ideas] Slicing and Chainging iterables. In-Reply-To: <20150103152844.GG27426@ando.pearwood.info> References: <20150103152844.GG27426@ando.pearwood.info> Message-ID: Sorry, I probably wasn't clear enough. My idea was to add these method (__add__, __getitem__) to the already available iterators (map,zip,dict.items) and generators by default. Not to make these methods part of the iterator protocol. 2015-01-03 17:28 GMT+02:00 Steven D'Aprano : > On Sat, Jan 03, 2015 at 03:37:03PM +0200, yotam vaknin wrote: > > I would like to purpose that in python 3 it will be easy to chain and > slice > > Iterators just like you can add and slice lists and tuples easily. > > > > I think there could be 2 methods to do this: > > 1. Implementing '+' and slicing ([1:2:3]) for iterators and generators by > > default, Resulting in Itertool's chain(a,b) and islice(a,b,c) > respectively. > > 2. Having itertool's chain and islice imported by default. > > The iterator protocol is intentionally simple. To create an iterator, > you need to only define two methods: > > (1) __iter__, which returns the instance itself; > > (2) __next__, which returns the next item and raises StopIterator when > done. > > > With your proposal, you would have to define two or three more methods: > > (3) __add__ and possibly __radd__, to chain iterators; > > (4) __getitem__, for slicing. > > There is nothing stopping you from adding these methods to your own > iterator classes, but with your proposal that would be compulsory for > all iterators. > > > > I think since python 3 return zip,map, dict.items and so on as iterators, > > it makes working with those kind of objects more difficult without having > > these methods around. And since those methods are important enough to > have > > for lists, it seems important enough for iterators too. > > It only takes a single line of code to get iterator chaining and > slicing: > > from itertools import chain, islice > > And now you can chain and slice any iterator, regardless of where it > came from. I don't think that is difficult. > > *If* iterators where instances of a concrete base class, then it would > make sense to add chain and slice methods to that base class so all > other iterators could inherit from it. But they aren't, iterators in > Python are values which obey a protocol, not inheritence. That means > that a functional approach, like itertools, is more appropriate. > > I can see the appeal of using + and [a:b:c] syntax instead of function > syntax chain() and islice(), but I don't think the advantage is enough > to out-weigh the costs. > > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Sat Jan 3 21:40:59 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 3 Jan 2015 21:40:59 +0100 Subject: [Python-ideas] Slicing and Chainging iterables. In-Reply-To: References: <20150103152844.GG27426@ando.pearwood.info> Message-ID: <9BA6ABD2-2F58-4F95-959D-F0D3ECB3F3E8@yahoo.com> On Jan 3, 2015, at 16:53, yotam vaknin wrote: > Sorry, I probably wasn't clear enough. > My idea was to add these method (__add__, __getitem__) to the already available iterators (map,zip,dict.items) and generators by default. Not to make these methods part of the iterator protocol. Well, dict.items doesn't return an iterator, it returns an iterable view. More importantly, if you add this just to generators and map and zip, it won't apply to (among other things) filter; the built-in iterators for list, tuple, set, dict, and the dict views; the special type used to iterate types that implement __getitem__ but not __iter__; any of the iterators from itertools--including the result of slicing or chaining two map iterators; files; csv readers; XML iterparse; ? I think that would make the language a lot worse. In general, code doesn't care whether it's gotten an iterator from mapping a function over a file, chaining two iterators together, or iterating a sequence. If you wrote some code that expected to get a generator, used the + operator, and then changed the calling code to filter that generator, it would break, for no good reason. If you really wanted to, you could make this general pretty easily: change the meaning of the + operator so that, after checking __add__ and __radd__, before raising a TypeError, it checks whether both operand have __iter__ methods and, if so, it returns a chain of the two. Slicing has another problem, however. First, it's a bit odd to be able to do i[5:7] but not i[5]. But, more seriously, I wouldn't expect i[5:7] to give me an iterable that, when accessed, discards the first 5 elements of i. And imagine how confusing this code would be: >>> i = iter(range(10)) >>> a = i[2:4] >>> b = i[4:6] >>> list(a) [2, 3] >>> list(b) [8, 9] Hiding the fact that i is an iterable rather than a sequence will just confuse your readers. > 2015-01-03 17:28 GMT+02:00 Steven D'Aprano : >> On Sat, Jan 03, 2015 at 03:37:03PM +0200, yotam vaknin wrote: >> > I would like to purpose that in python 3 it will be easy to chain and slice >> > Iterators just like you can add and slice lists and tuples easily. >> > >> > I think there could be 2 methods to do this: >> > 1. Implementing '+' and slicing ([1:2:3]) for iterators and generators by >> > default, Resulting in Itertool's chain(a,b) and islice(a,b,c) respectively. >> > 2. Having itertool's chain and islice imported by default. >> >> The iterator protocol is intentionally simple. To create an iterator, >> you need to only define two methods: >> >> (1) __iter__, which returns the instance itself; >> >> (2) __next__, which returns the next item and raises StopIterator when >> done. >> >> >> With your proposal, you would have to define two or three more methods: >> >> (3) __add__ and possibly __radd__, to chain iterators; >> >> (4) __getitem__, for slicing. >> >> There is nothing stopping you from adding these methods to your own >> iterator classes, but with your proposal that would be compulsory for >> all iterators. >> >> >> > I think since python 3 return zip,map, dict.items and so on as iterators, >> > it makes working with those kind of objects more difficult without having >> > these methods around. And since those methods are important enough to have >> > for lists, it seems important enough for iterators too. >> >> It only takes a single line of code to get iterator chaining and >> slicing: >> >> from itertools import chain, islice >> >> And now you can chain and slice any iterator, regardless of where it >> came from. I don't think that is difficult. >> >> *If* iterators where instances of a concrete base class, then it would >> make sense to add chain and slice methods to that base class so all >> other iterators could inherit from it. But they aren't, iterators in >> Python are values which obey a protocol, not inheritence. That means >> that a functional approach, like itertools, is more appropriate. >> >> I can see the appeal of using + and [a:b:c] syntax instead of function >> syntax chain() and islice(), but I don't think the advantage is enough >> to out-weigh the costs. >> >> >> >> -- >> Steve >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Sat Jan 3 22:14:54 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 3 Jan 2015 22:14:54 +0100 Subject: [Python-ideas] Slicing and Chainging iterables. In-Reply-To: References: <20150103152844.GG27426@ando.pearwood.info> Message-ID: <892E5E24-CB4D-448F-8B76-239E80EF6C90@yahoo.com> On Jan 3, 2015, at 16:53, yotam vaknin wrote: > Sorry, I probably wasn't clear enough. > My idea was to add these method (__add__, __getitem__) to the already available iterators (map,zip,dict.items) and generators by default. Not to make these methods part of the iterator protocol. Reading this again, I think what you _really_ want is probably a generalized view protocol, where views of sequences act like (in fact, _are_) sequences, but with the main advantages of iterators (no storage or upfront computation). Like dictionary views (which is why I chose the name "view", of course). And there's no reason map _couldn't_ return a view instead of an iterator. When called on (all) sequences it would be a sequence view; when called on (any) iterators it would be an iterator view; otherwise it would be a non-sequence non-iterator (that is, reusable, but not indexable) iterable view. But in any case, it would never call the mapped function on a given mapped value until the result is requested. In other words: >>> def spam(x): ... print(x) ... return x+1 >>> m = map(spam, range(5)) >>> m >>> m[2] 2 3 >>> ms = m[2:4] >>> ms[1] 3 4 You can build view-based zip similarly, and filter, and most of the functions in itertools, and so on (although note that in some cases--like filter--a view of a sequence wouldn't be a sequence). You could also make slices into lazy views instead of copying (as NumPy already does with its arrays). In fact, Python could have designed all of its collections and higher-order functions around views instead of iterators. That's what Swift did. (Swift goes farther, with a hierarchy of kinds of indexing, based on C++, instead of just iterables and sequences.) I wrote a blog post last year (based on the first beta of Swift, which had some oddities in its implementation) examining how this could work in Python terms (http://stupidpythonideas.blogspot.com/2014/07/swift-style-map-and-filter-views.html). I think I've also got a partial implementation somewhere on Github of map, filter, and maybe a few more functions implemented as views. But it would be a pretty major change to Python to move from iterators to views. And iterators are much simpler to create than views, so the tradeoff probably wouldn't be worth it, even if it weren't for the historical/compatibility issue. (It's much the same with Haskell-style lazy lists; Python iterables can only substitute for lazy lists 90% of the time, but that doesn't mean lazy lists are a better language choice.) From sturla.molden at gmail.com Sat Jan 3 23:14:53 2015 From: sturla.molden at gmail.com (Sturla Molden) Date: Sat, 3 Jan 2015 22:14:53 +0000 (UTC) Subject: [Python-ideas] Slicing and Chainging iterables. References: Message-ID: <605337341442016047.995305sturla.molden-gmail.com@news.gmane.org> yotam vaknin wrote: > 1. Implementing '+' and slicing ([1:2:3]) for iterators and generators by > default, Resulting in Itertool's chain(a,b) and islice(a,b,c) respectively. This will break NumPy. Sturla From ncoghlan at gmail.com Sun Jan 4 07:05:23 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 4 Jan 2015 16:05:23 +1000 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

Message-ID: On 4 January 2015 at 17:45, Devin Jeanpierre wrote: > On Sat, Jan 3, 2015 at 11:23 PM, Nick Coghlan wrote: >> On 4 January 2015 at 07:14, Andrew Barnert >> wrote: >>> But it would be a pretty major change to >>> Python to move from iterators to views. And iterators are much simpler to create than views, so the tradeoff probably wouldn't be worth it, even if it weren't for the historical/compatibility issue. (It's much the same with Haskell-style lazy lists; Python iterables can only substitute for lazy lists 90% of the time, but that doesn't mean lazy lists are a better language choice.) >> >> It's worth noting that many types implement >> Mapping.(keys,values,items) as iterators in Python 3 rather than as >> views, and generally don't receive any complaints from users. > > They probably should implement keys/etc. properly. > collections.abc.[Mutable]Mapping make it easy to support views if you > otherwise implement a dictionary-like object. What people "should" do and what they actually do in practice often differ wildly. In this particular case, folks migrating from Python 2 will frequently rename existing iter* methods to be the Python 3 implementations of the base methods. It's technically a non-compliant implementation of the Python mapping protocol, but you'll only encounter problems if you attempt to use that container implementation with code that relies on the Python 3 view behaviour. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From wes.turner at gmail.com Sun Jan 4 10:27:43 2015 From: wes.turner at gmail.com (Wes Turner) Date: Sun, 4 Jan 2015 03:27:43 -0600 Subject: [Python-ideas] Slicing and Chainging iterables. In-Reply-To: References: Message-ID: In addition to itertools.chain and itertools.islice, this is possible with a number of third-party packages: * http://toolz.readthedocs.org/en/latest/api.html#itertoolz (concat, pluck, first, last, take) * https://github.com/kachayev/fn.py#streams-and-infinite-sequences-declaration (<< 'Stream' operator) * http://funcy.readthedocs.org/en/latest/seqs.html Stdlib docs for this: * https://docs.python.org/2/howto/functional.html#iterators * https://docs.python.org/2/tutorial/classes.html#iterators * https://docs.python.org/2/library/stdtypes.html#iterator-types * https://docs.python.org/2/reference/datamodel.html#object.__iter__ * On Sat, Jan 3, 2015 at 7:37 AM, yotam vaknin wrote: > I would like to purpose that in python 3 it will be easy to chain and > slice Iterators just like you can add and slice lists and tuples easily. > > I think there could be 2 methods to do this: > 1. Implementing '+' and slicing ([1:2:3]) for iterators and generators by > default, Resulting in Itertool's chain(a,b) and islice(a,b,c) respectively. > 2. Having itertool's chain and islice imported by default. > > I think since python 3 return zip,map, dict.items and so on as iterators, > it makes working with those kind of objects more difficult without having > these methods around. And since those methods are important enough to have > for lists, it seems important enough for iterators too. > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Sun Jan 4 11:32:13 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sun, 4 Jan 2015 11:32:13 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> Message-ID: <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> On Jan 4, 2015, at 7:05, Nick Coghlan wrote: > On 3 January 2015 at 21:04, Andrew Barnert > wrote: >> On Jan 3, 2015, at 11:39, Chris Angelico wrote: >> >>> On Sat, Jan 3, 2015 at 9:28 PM, Andrew Barnert wrote: >>>> I agree with this, but it still might be nice to mention that third-party module in shutil and/or pathlib. >>> >>> Maybe. Is there a mention of other third-party packages in stdlib >>> docs? It's a slippery slope; which ones deserve mention? Maybe just >>> something like "Note that moving objects to the trash can is possible >>> in OS-dependent ways; packages are available on PyPI to make this >>> easier", without naming any. >> >> The impression I get is that this is a slope that Python (or at least Nick Coghlan) wants to start sliding down--with the advent of wheels and pre-installed pip, keeping things out of the stdlib but still accessible for most users is now possible, and often desirable. But I could be putting words (or complete ideas) in people's mouths. > > Your parenthetical qualification is correct - while I personally think > providing authoritative recommendations of third party modules is a > good idea, this is far from a universally held opinion amongst the > core development team. My own caveat on the idea is that any such > explicit recommendations should only cover projects that potentially > *could* be included in the standard library from an API design > perspective, but we don't want to include them (yet, or perhaps ever) > for project governance reasons, such as their update cycles for > feature releases needing to be faster than those of the standard > library. > > The "pro" case for this approach is primarily about lowering barriers > to entry: for folks just learning Python, "not in the standard > library" is currently functionally equivalent in many cases to "Python > can't do this". New users often won't yet have the skills needed to do > their own research and evaluate competing solutions to their problem, > and teaching someone how to find a module on the internet, evaluate > the trustworthiness of the people publishing it, get it onto their > computer, and update it appropriately over time is genuinely difficult > (even with pip provided by default - that helps with the last two > steps, but the first two are still genuinely difficult, in a way > experienced open source developers often take for granted). Providing > authoritative recommendations of third party projects in the standard > library documentation helps resolve that situation without needing to > resort to making the standard library larger (with the additional long > term maintenance complications the latter approach entails). > > You see a similar dynamic operating in a slightly different way with a > project like Django - when the Django developers are significantly > more experienced in web development than you are, their opinionated, > all-inclusive approach to web framework design is a *feature*, not a > defect. It's only when you become more experienced with web service > development yourself, and need to deal with problems that don't fit > neatly into the SQL-backed three-tier web application model, or need > to integrate with other systems which weren't built with Django in > mind, that less opinionated frameworks like Flask or Pyramid become > interesting - those frameworks leave many more decisions to the > developers using them, which is exactly what you want in many > situations as an experienced developer, but constantly asking people > to make decisions they aren't yet qualified to make poses a huge > barrier to entry. It's a potential problem when less experienced folks > are put off by the request to make those decisions (since not > understanding the questions you're being asked by your tools makes for > a terrible user experience), and decide to go learn something else > that places fewer demands on them, but it's even worse for everyone > trying to deploy and manage the resulting software systems when folks > happily make the decisions these advanced DIY integration frameworks > ask of them without even realising they're not yet qualified to make > them. > > djangopackages.com is also incredibly useful as a tool for finding > peer evaluations of projects in the Django ecosystem. I'm not yet > aware of any successful attempts to expand that model to other plugin > ecosystems, but the core grid concept of assembling a set of criteria, > providing answers across a set of related projects, and publishing the > results to provide a starting point for anyone doing their own > research in that topic area is a wonderful one. > > The "con" case is that providing default recommendations can be > controversial - when there are multiple competing projects in an area, > being the default recommendation of the CPython core development team > can be a huge popularity boost, since reputation is to some degree > transitive. If someone trusts CPython, and we trust another project > enough to recommend it, then a lot of folks will use that > recommendation as a substitute for doing their own research (even when > they *can* do that research themselves, the default recommendation is > likely to be good enough, letting them defer investigation of > alternatives until after they've tried the default option). > > I suspect that objection could potentially be dealt with the same way > we deal with any other standard library design decisions: if a module > maintainer is comfortable making a recommendation based on their own > expertise they can, but broader recommendations spanning several > modules would require at least a discussion on python-dev, and > potentially even a PEP. The question here, then, is how this applies to desktop/shell functionality like moving to trash, administering trash in all the ways someone (Steven?) wanted, other features that someone else raised (aliases/bookmarks/shortcuts/desktop files), and maybe additional stuff (accessing the desktop's extension/file-type mapping). Some of that stuff is already in the stdlib (or might be confusing to novices--e.g., IIRC, on XDG desktops, some things that are done with aliases on Mac are done with desktop files, but in some cases you just use symlinks, so a Linux novice might not even realize he's not writing cross-platform code...). For a GUI app, it's not at all clear that choosing Qt or Wx or one of the platform-specific libraries automatically solves all of these problems for you, while choosing Tk doesn't. For a command-line app, it's even worse. Most Windows users probably have no idea they're asking for desktop integration rather than OS support when they ask how to move a file to the trash or create a shortcut, because Windows intentionally buries that distinction. So when they see that neither os nor shutil nor anything else in the stdlib can help them, they're not going to think, "Oh, I need to go find a platform-specific or cross-platform desktop integration library." (And they're also not going to think "Well, Perl and Ruby and Node don't have these either, so why should I expect Python to?") So, I think in this case it would be useful to recommend something. The question is _what_ to recommend (and where). I think for platform-specific code there are pretty clear winners (PyWin32, PyObjC, GObject, and PyQt/PySide, for the big four). Some might argue for including the XDG package (e.g., if you want to do the same thing as one of the XDG-utils tools, you don't need Gtk or Qt for that), and Mac users might also want a link to the ScriptingBridge guide or something (because some things that are done by API on Windows are done by scripting System Events or Finder or something else), and people using a third-tier desktop on Linux may not have Gtk or Qt libraries to bind to, etc., but I think those are minor questions compared to whether it would be useful to have pointers to these packages for novices. (I think it goes without saying that none of these packages should be added to the stdlib, right?) But for cross-platform code there really isn't an answer. (Well, PyQt/PySide would work, but it's still non-trivial to install and configure on Mac and Windows, and it's overkill.) So, maybe what we need here is for someone to first create the desktop package, and then we can worry about whether it should be added to the stdlib, recommended in the stdlib, or neither. And that still leaves open the possibility that some small subset of this functionality might be separable enough and useful enough to put in the stdlib, or in a small package linked from the stdlib. After all, the equivalent of start/open/xdg-open is already there for some platforms, and webbrowser.open and some of the stuff in shutil. I don't think moving to trash is part of such a subset (for the reasons I gave earlier), but I could be wrong. From ncoghlan at gmail.com Sun Jan 4 14:01:08 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 4 Jan 2015 23:01:08 +1000 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> Message-ID: On 4 January 2015 at 20:32, Andrew Barnert wrote: > The question here, then, is how this applies to desktop/shell functionality like moving to trash, administering trash in all the ways someone (Steven?) wanted, other features that someone else raised (aliases/bookmarks/shortcuts/desktop files), and maybe additional stuff (accessing the desktop's extension/file-type mapping). Some of that stuff is already in the stdlib (or might be confusing to novices--e.g., IIRC, on XDG desktops, some things that are done with aliases on Mac are done with desktop files, but in some cases you just use symlinks, so a Linux novice might not even realize he's not writing cross-platform code...). > > For a GUI app, it's not at all clear that choosing Qt or Wx or one of the platform-specific libraries automatically solves all of these problems for you, while choosing Tk doesn't. For a command-line app, it's even worse. Most Windows users probably have no idea they're asking for desktop integration rather than OS support when they ask how to move a file to the trash or create a shortcut, because Windows intentionally buries that distinction. So when they see that neither os nor shutil nor anything else in the stdlib can help them, they're not going to think, "Oh, I need to go find a platform-specific or cross-platform desktop integration library." (And they're also not going to think "Well, Perl and Ruby and Node don't have these either, so why should I expect Python to?") So, I think in this case it would be useful to recommend something. The question is _what_ to recommend (and where). > > I think for platform-specific code there are pretty clear winners (PyWin32, PyObjC, GObject, and PyQt/PySide, for the big four). Some might argue for including the XDG package (e.g., if you want to do the same thing as one of the XDG-utils tools, you don't need Gtk or Qt for that), and Mac users might also want a link to the ScriptingBridge guide or something (because some things that are done by API on Windows are done by scripting System Events or Finder or something else), and people using a third-tier desktop on Linux may not have Gtk or Qt libraries to bind to, etc., but I think those are minor questions compared to whether it would be useful to have pointers to these packages for novices. (I think it goes without saying that none of these packages should be added to the stdlib, right?) Right, a useful first step might be a "Tools for writing rich client applications in Python" overview page. That's out of scope for any of the current *.python.org documentation set (it doesn't fit under docs.python.org *or* packaging.python.org, nor anywhere on the main site), but if it's written in an appropriate tone (i.e. making it clear that these are default starting points, and recommendations for further evaluation, rather than universally applicable definitive conclusions), then a future "ecosystem.python.org" guide could start the same way p.p.o did, as a separate Sphinx project hosted on ReadTheDocs that was later blessed with a python.org subdomain. https://packaging.python.org/en/latest/deployment.html is an example skeleton of such a page for package deployment tools. We haven't filled that one *in* yet, but hopefully it conveys the general idea. https://packaging.python.org/en/latest/extensions.html is another one reviewing binary extensions, and some of the tools available in that space. For those curious as to "Why not the wiki?", a Sphinx project hosted on a pull request capable service like GitHub, BitBucket or Kallithea offers a much nicer workflow for reviewing of proposed changes, together with an integrated issue tracker for submitting proposals for updates (https://github.com/pypa/python-packaging-user-guide/ is the project behind packaging.python.org, for example). > But for cross-platform code there really isn't an answer. (Well, PyQt/PySide would work, but it's still non-trivial to install and configure on Mac and Windows, and it's overkill.) So, maybe what we need here is for someone to first create the desktop package, and then we can worry about whether it should be added to the stdlib, recommended in the stdlib, or neither. Just describing the problem space can be incredibly valuable for newcomers - one of the hardest things to learn as a beginner is the difference between "this is hard because I don't know what I'm doing" and "this is hard because I'm working on an unsolved problem" (with "this is deceptively easy because I'm setting myself up for problems later on" being an interesting variant that's hard to detect no matter how experienced you are). I see this is a *lot* when working with the scientific community - they actually have much higher expectations of cross-platform tooling than professional developers do. From the outside, the political, personal and commercial meta-issues that combine to make cross-platform standards development an unholy nightmare aren't immediately obvious, and nor are the trade-offs between "lowest common denominator" (or Java-style "reinvent all the wheels") functionality that works everywhere, and providing access to advanced platform specific functionality. > And that still leaves open the possibility that some small subset of this functionality might be separable enough and useful enough to put in the stdlib, or in a small package linked from the stdlib. After all, the equivalent of start/open/xdg-open is already there for some platforms, and webbrowser.open and some of the stuff in shutil. I don't think moving to trash is part of such a subset (for the reasons I gave earlier), but I could be wrong. While I think it's better to leave the question open rather than try to pre-empt an answer, I do believe we can at least say *now* isn't the right time to be adding "move to trash" functionality to the standard library - the functionality isn't mature enough within the broader ecosystem to determine an appropriate answer. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From random832 at fastmail.us Sun Jan 4 20:24:36 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sun, 04 Jan 2015 14:24:36 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150103015045.GB27426@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> Message-ID: <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> On Fri, Jan 2, 2015, at 20:50, Steven D'Aprano wrote: > > Because what _not_ having a > > cross-platform wrapper gets you is windows and mac left behind > > Really? I would expect that Windows is probably the *easiest* platform > to implement this functionality, as it has a single, standard, stable > API for moving files to trash. (Or so I am lead to believe.) You can > probably use that API via ctypes, or via pywin32. Why would someone who is developing on Linux and has no pre-made library function to call bother with that? If being cross-platform isn't easy, it won't happen. You see it now with the lack of any support for "call glob on arguments on windows and not on unix" [because the shell handles it on unix] whether directly, in argparse, or in fileinput - today, nothing ever calls glob, and so people calling such scripts on windows can't use wildcards (glob is also different from windows wildcards in subtle ways) > Getting OS X right is very complicated, as Andrew has so ably explained. > > In Linux and other Unixes, the situation is like OS X, only more so > since there's no one single authority. However, what authority there is does not allegedly demand that you present dialog boxes and admin elevation prompts to the user (this has been asserted, but no citation has been given). > You have a choice of desktop > environments, which may or may not provide a move-to-trash API, > including no desktop environment at all. Gnome provides an API for > moving to trash, but I don't know how well it supports the freedesktop > standard; KDE supports the freedesktop standard, but I don't know if it > provides an API that can be called. XFCE has partial support. I don't see why you need to call an API to the desktop enviroment. The entire point of the spec is to provide compatibility _between_ implementations on the same filesystem - you can quit gnome and log into KDE and see the same trash. Python would just be a separate implementation that stands by itself. From ncoghlan at gmail.com Sun Jan 4 21:25:01 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 5 Jan 2015 06:25:01 +1000 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> Message-ID: On 5 Jan 2015 05:25, wrote: > > On Fri, Jan 2, 2015, at 20:50, Steven D'Aprano wrote: > > You have a choice of desktop > > environments, which may or may not provide a move-to-trash API, > > including no desktop environment at all. Gnome provides an API for > > moving to trash, but I don't know how well it supports the freedesktop > > standard; KDE supports the freedesktop standard, but I don't know if it > > provides an API that can be called. XFCE has partial support. > > I don't see why you need to call an API to the desktop enviroment. The > entire point of the spec is to provide compatibility _between_ > implementations on the same filesystem - you can quit gnome and log into > KDE and see the same trash. That compatibility is implemented *by* the desktop environments. Yes, you could write your own, but why would you, when the whole point of providing a standard API would be to integrate more cleanly with the underlying OS. > Python would just be a separate > implementation that stands by itself. The word "just" does not belong in that sentence. Reliable cross-platform development & testing for operations that are tightly coupled to operating system services is hard, period - the associated test matrix of platforms and permission levels ensures that. Regards, Nick. -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Sun Jan 4 21:35:07 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 4 Jan 2015 21:35:07 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> Message-ID: <20150104213507.708c3548@fsol> On Mon, 5 Jan 2015 06:25:01 +1000 Nick Coghlan wrote: > On 5 Jan 2015 05:25, wrote: > > > > On Fri, Jan 2, 2015, at 20:50, Steven D'Aprano wrote: > > > > You have a choice of desktop > > > environments, which may or may not provide a move-to-trash API, > > > including no desktop environment at all. Gnome provides an API for > > > moving to trash, but I don't know how well it supports the freedesktop > > > standard; KDE supports the freedesktop standard, but I don't know if it > > > provides an API that can be called. XFCE has partial support. > > > > I don't see why you need to call an API to the desktop enviroment. The > > entire point of the spec is to provide compatibility _between_ > > implementations on the same filesystem - you can quit gnome and log into > > KDE and see the same trash. > > That compatibility is implemented *by* the desktop environments. Yes, you > could write your own, but why would you, when the whole point of providing > a standard API would be to integrate more cleanly with the underlying OS. For the same reason that we ship a HTTP server while we could integrate more cleanly with Apache? :-) When there's a well-defined spec, it can be simpler to implement the spec yourself rather than pull third-party dependencies, especially when those happen to be huge as may be the case with desktop environments. Regards Antoine. From abarnert at yahoo.com Sun Jan 4 22:02:27 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sun, 4 Jan 2015 22:02:27 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> Message-ID: <6A8A7845-7865-4746-9859-CD51FC695DDA@yahoo.com> On Jan 4, 2015, at 20:24, random832 at fastmail.us wrote: > On Fri, Jan 2, 2015, at 20:50, Steven D'Aprano wrote: > >> Getting OS X right is very complicated, as Andrew has so ably explained. >> >> In Linux and other Unixes, the situation is like OS X, only more so >> since there's no one single authority. > > However, what authority there is does not allegedly demand that you > present dialog boxes and admin elevation prompts to the user (this has > been asserted, but no citation has been given). Where has that, or anything remotely similar, been alleged or asserted? What _has_ been asserted is that an app has to fit in with the choices made by the platform implementation. And the only example given was given with a direct quote from the spec linked in the preceding email. I'm not sure how much simpler a citation you need in order to be able to follow it. The example was about platform-specific ways to allow admins to disable sticky-bit checking on network mounts. There are more such things that are left incompletely specified, or explicitly left unspecified for future development. I don't think any of them have anything to do with dialog boxes or other user interaction, and I don't recall anyone saying otherwise. (I suppose if you didn't read carefully, you might take something like "SHOULD warn the administrator" as implying a prompt saying "Go get your sys admin and drag him over to the screen" rather than, say, a syslog warning with a string the admin can see later and look up in help or google). >> You have a choice of desktop >> environments, which may or may not provide a move-to-trash API, >> including no desktop environment at all. Gnome provides an API for >> moving to trash, but I don't know how well it supports the freedesktop >> standard; KDE supports the freedesktop standard, but I don't know if it >> provides an API that can be called. XFCE has partial support. > > I don't see why you need to call an API to the desktop enviroment. The > entire point of the spec is to provide compatibility _between_ > implementations on the same filesystem - you can quit gnome and log into > KDE and see the same trash. Python would just be a separate > implementation that stands by itself. The last sentence is exactly the same thing you already got two detailed answers to that you haven't responded to in any way. So I suspect the reason you don't understand why calling an API is a good idea is that you skimmed over the explanations that would explain exactly that. Go back and read those emails. From ethan at stoneleaf.us Sun Jan 4 22:02:39 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Sun, 04 Jan 2015 13:02:39 -0800 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> Message-ID: <54A9AA6F.8020400@stoneleaf.us> On 01/04/2015 11:24 AM, random832 at fastmail.us wrote: > If being cross-platform isn't easy, it won't happen. You see it now with > the lack of any support for "call glob on arguments on windows and not > on unix" [because the shell handles it on unix] whether directly, in > argparse, or in fileinput Could you elaborate on this point? > I don't see why you need to call an API to the desktop enviroment. The > entire point of the spec is to provide compatibility _between_ > implementations on the same filesystem - you can quit gnome and log into > KDE and see the same trash. Python would just be a separate > implementation that stands by itself. If by "stands by itself" you mean "desktops can't interact with it", how would that be useful? -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From abarnert at yahoo.com Sun Jan 4 23:06:42 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Sun, 4 Jan 2015 23:06:42 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150104213507.708c3548@fsol> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> <20150104213507.708c3548@fsol> Message-ID: <8AB561C3-EDFD-4F6B-8AE9-9115627AF6A4@yahoo.com> On Jan 4, 2015, at 21:35, Antoine Pitrou wrote: > On Mon, 5 Jan 2015 06:25:01 +1000 > Nick Coghlan wrote: >> On 5 Jan 2015 05:25, wrote: >>> >>> On Fri, Jan 2, 2015, at 20:50, Steven D'Aprano wrote: >> >>>> You have a choice of desktop >>>> environments, which may or may not provide a move-to-trash API, >>>> including no desktop environment at all. Gnome provides an API for >>>> moving to trash, but I don't know how well it supports the freedesktop >>>> standard; KDE supports the freedesktop standard, but I don't know if it >>>> provides an API that can be called. XFCE has partial support. >>> >>> I don't see why you need to call an API to the desktop enviroment. The >>> entire point of the spec is to provide compatibility _between_ >>> implementations on the same filesystem - you can quit gnome and log into >>> KDE and see the same trash. >> >> That compatibility is implemented *by* the desktop environments. Yes, you >> could write your own, but why would you, when the whole point of providing >> a standard API would be to integrate more cleanly with the underlying OS. > > For the same reason that we ship a HTTP server while we could integrate > more cleanly with Apache? :-) That's an interesting point--but note that Python _also_ has WSGI and various other ways to integrate more cleanly with Apache (and various other web servers). If you just want to put up a simple web service to handle a few users (e.g., as a user interface to your application), SimpleHTTPServer is sometimes the answer. But if you want to add a web service to a major Apache deployment, you generally don't want to do that by deploying SimpleHTTPServer alongside it. It's not _impossible_ to share ports, SSL certs, configs, logs, deployment scripts, monitoring tools, etc. between the two, but it's not the way you'd want to do things. (There's also the fact that SimpleHTTPServer won't be able to handle the same load as Apache?) > When there's a well-defined spec, I suppose it depends on your definition of "well-defined spec". As Nick said, XFCE only partly supports the spec, and he's not sure how completely GNOME does. As I pointed out, there are gaps in the spec for both implementation-defined and future-expansion behavior. That isn't the same as the case with HTTP/1.1. Look at http://www.freedesktop.org/wiki/Software. Notice that xdg-utils does not yet have a trash command, and there is no separate trash program or library. (As far as I know, there are at least two XDG trash programs on github which have not yet been submitted to be part of the XDG software collection, which don't appear to be 100% compatible with each other. (For example, one of them requires top trash directories to have exactly mode 41777, the other just requires them to be executable for the current user and have the sticky bit on.) Does creating a third one--and putting it in the Python stdlib forever--really sound like a good idea? (As a side note, one of the two above-mentioned trash programs is written in Node, and I don't see anyone suggesting that the functionality be moved into the Node stdlib.) From stephen at xemacs.org Sun Jan 4 23:18:07 2015 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 05 Jan 2015 07:18:07 +0900 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> Message-ID: <87tx06197k.fsf@uwakimon.sk.tsukuba.ac.jp> random832 at fastmail.us writes: > I don't see why you need to call an API to the desktop enviroment. The > entire point of the spec is to provide compatibility _between_ > implementations on the same filesystem - you can quit gnome and log into > KDE and see the same trash. Python would just be a separate > implementation that stands by itself. But Python doesn't much care about similarities or differences between GNOME and KDE AFAICS -- the relationships to Mac and Windows are much more interesting. Emacs has had a policy of implementing everything itself for decades, and its mindshare has been decreasing for decades.[1] Many Emacs developers are cross-platform users, and the common cross-platform implementation is great for them. Most potential users are not, and the small differences between Emacs's behavior and the platform API mean that Emacs is not a separate implementation that stands by itself -- it's a bad implementation that spends a lot of time standing in a corner.[2] This is not the only reason for Emacs's relative loss of popularity, but it's definitely a common complaint -- and the complainers often never return to Emacs channels when it becomes clear that the Emacs way is the only way. In any case, the small platform differences and the odd problem with the spec mean that this is definitely suited for out-of-stdlib experimentation. Footnotes: [1] The former is a consequence of a policy that (official) Emacs on non-GNU systems can't have any feature that Emacs on the GNU System doesn't have -- if you want a move-to-trash command on Mac, you have to implement for GNU. [2] A traditional punishment for mischievous children, especially those who don't finish their chores or homework, where I grew up. From random832 at fastmail.us Sun Jan 4 23:50:42 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sun, 04 Jan 2015 17:50:42 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <54A9AA6F.8020400@stoneleaf.us> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> <54A9AA6F.8020400@stoneleaf.us> Message-ID: On Mon, Jan 5, 2015 at 8:02 AM, Ethan Furman wrote: > On 01/04/2015 11:24 AM, random832 at fastmail.us wrote: > >> If being cross-platform isn't easy, it won't happen. You see it now with >> the lack of any support for "call glob on arguments on windows and not >> on unix" [because the shell handles it on unix] whether directly, in >> argparse, or in fileinput > > Could you elaborate on this point? On Unix, a command like "python some_script.py *.txt" is parsed by the shell[1] into a bunch of extra arguments, eg "python some_script.py file_one.txt file_two.txt file_three.txt". On Windows[2], this expansion isn't done, so the script gets a literal "*.txt" as an argument. So a Unix program is usually written to accept multiple args, but a Windows program usually expects to do its own globbing. Now, what happens when you want to reference a file whose name actually includes U+002A (or \x2A, given that file names on most Linux systems consist of bytes)? On Unix, you put a backslash in front of the name, to prevent the shell from expanding it ("\*.txt"), or use some other means of calling up the program (subprocess.call(["python","some_script.py","*.txt"])). Your expectation then is that the script will NOT expand globs; but the script will see the exact same thing in sys.argv as it does on Windows, where the expectation is that it WILL expand globs (and, if I'm not mistaken, asterisks are simply disallowed in file names - though that might be a filesystem-specific rule). So somehow, your script has to know whether it's supposed to call glob or not. Or, more likely, it'll do whatever is appropriate for the platform its developer uses, and then misbehaves on the other one. ChrisA [1] Assuming you're using one of the standard shells, and assuming you haven't configured this feature away, etc, etc. Normal user expectations. [2] Again, assuming you're using the default shell; but again, normal user expectation, ergo replacement shells often replicate this. From steve at pearwood.info Mon Jan 5 01:57:30 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 5 Jan 2015 11:57:30 +1100 Subject: [Python-ideas] Add OS-dependent automatic glob support In-Reply-To: <1420413001.1294229.209490357.7C0E4C45@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> <54A9AA6F.8020400@stoneleaf.us> <1420413001.1294229.209490357.7C0E4C45@webmail.messagingengine.com> <20150105005730.GR27426@ando.pearwood.info> Message-ID: On Mon, Jan 5, 2015 at 11:57 AM, Steven D'Aprano wrote: > On Sun, Jan 04, 2015 at 06:10:01PM -0500, random832 at fastmail.us wrote: > [...] >> Right now, none of this is done. If you pass *.txt on the command line >> to a python script, it will attempt to open a file called "*.txt". > > On Windows, you will get Python's definition of globbing. On POSIX > systems, the globbing module will do nothing, because the shell will > most likely have already expanded the wild-cards You're assuming that there are no wildcard characters actually included in the file names, which on Unix systems is perfectly possible. How can you reliably manipulate a file called *.txt when there are foo.txt and bar.txt in the same directory? With most Unix programs, you escape the asterisk to get it past the shell, the program does no globbing of its own, and you're safe. If your Python script unconditionally globs its file names, you're stuck. >> Another separate but related issue is the fact that windows wildcards do >> not behave in the same way as python glob patterns. > > I don't understand why you say this. As I understand it, there is no > such thing as "Windows wildcards" as every application which wants to > support wildcards has to implement their own. If you want to know what > kinds of globbing wildcards the application supports, you have to read > the application documentation. (Or guess.) > > I am not a Windows expert, so I may have been misinformed. Anyone care > to comment? There's a very standard interpretation, which I think is codified in the FindFirstFile API, although I'm not sure of the details. >> and left bracket is a valid character in >> filenames unlike ? and *. > > And on POSIX systems, *all* wildcards are valid characters in file > names. If you want to specify a file called literally "*.txt", or > "spam[and eggs?].jpg", you have to escape the wildcards. Windows is no > different. No, Windows *is* different, because you simply aren't allowed to have those characters in file names: >>> open("*.txt","w") Traceback (most recent call last): File "", line 1, in open("*.txt","w") OSError: [Errno 22] Invalid argument: '*.txt' Unix allows anything other than a slash or NUL, so all wildcards have to be escaped to get them past the shell; or, alternatively, you can just use a non-shell way of starting a program, like Python's own subprocess module. > The glob module supports escaping of wildcards, doesn't it? If so, we > have no problem. If not, that's a bug, or at least an obvious and > important piece of missing functionality. I'm not sure that's the solution, because then Unix users would have to double-escape everything. It can be done, of course, but this is the exact sort of complication that single-platform developers often don't even think of. Suppose you develop on Windows, and just unconditionally glob all your arguments... your program will work fine on Unix, until it's asked to deal with a file with an asterisk in it, and your user complains very loudly about how it misbehaved... and maybe destroyed a bunch of files. Oops. Not good. ChrisA From steve at pearwood.info Mon Jan 5 02:13:12 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 5 Jan 2015 12:13:12 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> Message-ID: <20150105011312.GS27426@ando.pearwood.info> On Sun, Jan 04, 2015 at 11:01:08PM +1000, Nick Coghlan wrote: > For those curious as to "Why not the wiki?", a Sphinx project hosted > on a pull request capable service like GitHub, BitBucket or Kallithea > offers a much nicer workflow for reviewing of proposed changes, > together with an integrated issue tracker for submitting proposals for > updates (https://github.com/pypa/python-packaging-user-guide/ is the > project behind packaging.python.org, for example). The concept of "proposed changes" goes completely against the grain of community-managed content. Imagine if Wikipedia required you to make pull requests. The question to be asked is not whether "pull requests" are "nicer" than a wiki, but whether this information needs to be owned by a single person (or a small group thereof), and hence use the packaging.python.org module, or owned by the whole community, and hence use the wiki model. At the moment, the wiki is horribly underused. I'm not blaming anyone for that, I'm just as much to blame as anyone else. I have made far more contributions to the ActiveState recipes than I have to the Python wiki. But I'd really like to see the wiki become the second place people look for information, after the official docs. And hopefully there won't be a need for a third place :-) Although the quality of contrabutions is variable, the PHP community has made a very interesting decision to integrate community-supplied information with official docs: http://php.net/manual/en/function.dechex.php I wonder how we might do something similar? -- Steve From donald at stufft.io Mon Jan 5 02:17:57 2015 From: donald at stufft.io (Donald Stufft) Date: Sun, 4 Jan 2015 20:17:57 -0500 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150105011312.GS27426@ando.pearwood.info> References: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> <20150105011312.GS27426@ando.pearwood.info> Message-ID: > On Jan 4, 2015, at 8:13 PM, Steven D'Aprano wrote: > > On Sun, Jan 04, 2015 at 11:01:08PM +1000, Nick Coghlan wrote: > >> For those curious as to "Why not the wiki?", a Sphinx project hosted >> on a pull request capable service like GitHub, BitBucket or Kallithea >> offers a much nicer workflow for reviewing of proposed changes, >> together with an integrated issue tracker for submitting proposals for >> updates (https://github.com/pypa/python-packaging-user-guide/ is the >> project behind packaging.python.org, for example). > > The concept of "proposed changes" goes completely against the grain of > community-managed content. Imagine if Wikipedia required you to make > pull requests. > > The question to be asked is not whether "pull requests" are "nicer" than > a wiki, but whether this information needs to be owned by a single > person (or a small group thereof), and hence use the > packaging.python.org module, or owned by the whole community, and hence > use the wiki model. > > At the moment, the wiki is horribly underused. I'm not blaming anyone > for that, I'm just as much to blame as anyone else. I have made far more > contributions to the ActiveState recipes than I have to the Python wiki. > But I'd really like to see the wiki become the second place people look > for information, after the official docs. And hopefully there won't be a > need for a third place :-) > > Although the quality of contrabutions is variable, the PHP community has > made a very interesting decision to integrate community-supplied > information with official docs: > > http://php.net/manual/en/function.dechex.php > > I wonder how we might do something similar? > On the other hand, a number of pages on the Wiki are either completely out of date because nobody cares about them or need to be locked because too many people care about it and they fight over which project should be named as recommended. Wiki content can be good for more factual based information but I think the format is relatively poor for things which are more opinion based. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA From ben+python at benfinney.id.au Mon Jan 5 02:22:35 2015 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 05 Jan 2015 12:22:35 +1100 Subject: [Python-ideas] Encouraging more use of the Python wiki (was: Adding `pathlib.Path` method that would send file to recycle bin) References: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> <20150105011312.GS27426@ando.pearwood.info> Message-ID: <85387qyqas.fsf_-_@benfinney.id.au> Donald Stufft writes: > On the other hand, a number of pages on the Wiki are either completely > out of date because nobody cares about them or need to be locked > because too many people care about it and they fight over which > project should be named as recommended. In recent years (I noticed this since about 2013), the Python wiki does not offer an ?Edit? function when I am logged in; every page presents ?Immutable Page? instead. That has prevented me from improving pages I've wanted to. And no, I haven't gone to the effort of constructing a bug report for this. Perhaps the same is true for many other logged-in users as well? -- \ ?It is well to remember that the entire universe, with one | `\ trifling exception, is composed of others.? ?John Andrew Holmes | _o__) | Ben Finney From steve at pearwood.info Mon Jan 5 02:31:23 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 5 Jan 2015 12:31:23 +1100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> Message-ID: <20150105013123.GT27426@ando.pearwood.info> On Sun, Jan 04, 2015 at 02:24:36PM -0500, random832 at fastmail.us wrote: > On Fri, Jan 2, 2015, at 20:50, Steven D'Aprano wrote: > > > Because what _not_ having a > > > cross-platform wrapper gets you is windows and mac left behind > > > > Really? I would expect that Windows is probably the *easiest* platform > > to implement this functionality, as it has a single, standard, stable > > API for moving files to trash. (Or so I am lead to believe.) You can > > probably use that API via ctypes, or via pywin32. > > Why would someone who is developing on Linux and has no pre-made library > function to call bother with that? Because they want to write cross-platform code. For my own personal scripts, I wouldn't bother. If I had a Windows system which I intended to use the script on, I would, or if I intended to make the script available to others, I might. > If being cross-platform isn't easy, it won't happen. You see it now with > the lack of any support for "call glob on arguments on windows and not > on unix" [because the shell handles it on unix] whether directly, in > argparse, or in fileinput - today, nothing ever calls glob, and so > people calling such scripts on windows can't use wildcards (glob is also > different from windows wildcards in subtle ways) I think you are mistaken that nothing uses glob: https://searchcode.com/?q=import+glob+lang%3Apython [...] > > You have a choice of desktop > > environments, which may or may not provide a move-to-trash API, > > including no desktop environment at all. Gnome provides an API for > > moving to trash, but I don't know how well it supports the freedesktop > > standard; KDE supports the freedesktop standard, but I don't know if it > > provides an API that can be called. XFCE has partial support. > > I don't see why you need to call an API to the desktop enviroment. You don't *need* to do so, but doing so guarantees that your code will match the expected behaviour as provided by the API, and avoids needing to re-invent the wheel. I would expect that for something which eventually makes it into the standard library, if it ever does, it will have multiple implementations: - call the platform API, if one exists and it is available - fall back to a Python implementation, if no such API exists That is exactly what the third party Send2Trash package does. If Gnome is installed and the GIO library is installed, it uses that, otherwise it falls back on its own (possibly inferior?) implementation. -- Steven From random832 at fastmail.us Mon Jan 5 02:33:48 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sun, 04 Jan 2015 20:33:48 -0500 Subject: [Python-ideas] Add OS-dependent automatic glob support In-Reply-To: <20150105005730.GR27426@ando.pearwood.info> References: <20141229185326.19663a01@fsol> <7D7CB381-EE2A-4931-89DB-E6661A541715@yahoo.com> <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> <20150105013123.GT27426@ando.pearwood.info> Message-ID: <1420422016.1099647.209526789.52D57044@webmail.messagingengine.com> On Sun, Jan 4, 2015, at 20:31, Steven D'Aprano wrote: > I think you are mistaken that nothing uses glob: I am very confident in saying that programs that do not use glob _to process lists of filenames given on the command line_ outnumber those that do at least 1000:1, and that the vast majority of your search consists of uses for processing things other than command line arguments. > https://searchcode.com/?q=import+glob+lang%3Apython The vast majority of results (I used https://searchcode.com/?q=glob.glob+lang%3Apython so I could see the actual call in context) are using it for hardcoded strings, not command line arguments (and to do it correctly they should do even that conditionally on os.name == 'nt' [or os2 or ce, not sure about the other non-posix values]) From ethan at stoneleaf.us Mon Jan 5 02:41:24 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Sun, 04 Jan 2015 17:41:24 -0800 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <20150105011312.GS27426@ando.pearwood.info> References: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> <20150105011312.GS27426@ando.pearwood.info> Message-ID: <54A9EBC4.2010305@stoneleaf.us> On 01/04/2015 05:13 PM, Steven D'Aprano wrote: > Although the quality of contributions is variable, the PHP community has > made a very interesting decision to integrate community-supplied > information with official docs: > > http://php.net/manual/en/function.dechex.php > > I wonder how we might do something similar? I hope that we do not. A separate wiki is fine, but the official docs should just have the official stuff in them. If the docs were a wiki, we'd have scads of entries on "how to program in Python", and IMNSHO the official docs should just be about programming Python in Python. -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From steve at pearwood.info Mon Jan 5 03:07:35 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 5 Jan 2015 13:07:35 +1100 Subject: [Python-ideas] Add OS-dependent automatic glob support In-Reply-To: References: <54A1E167.1050605@canterbury.ac.nz>

<1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <1420399476.1260565.209437029.38EF0C44@webmail.messagingengine.com> <54A9AA6F.8020400@stoneleaf.us> <1420413001.1294229.209490357.7C0E4C45@webmail.messagingengine.com> <20150105005730.GR27426@ando.pearwood.info> <20150105020735.GU27426@ando.pearwood.info> <87lhlh2723.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <160BFDF9-033E-43C2-AF9E-18740FB1E90A@yahoo.com> It seems to me that if you want auto-globbing support on Windows, the "right" way to do it is to link in the fancy setargv instead of the default one. This handles wildcards exactly the same way the command.com/cmd.exe builtin commands do, which I suspect is what Windows users would actually be expecting of they passed a wildcard on the command line. (I think the docs no longer guarantee that this is true, but it's probably still true, and certainly closer to true than if you try to do it manually.) The only problem is that you can't add a command-line switch that controls at runtime which implementation of setargv got linked into the msvcrt prequel at build time. There used to be a way around this for DOS/Win16 programs, but I don't think there is for NT/Win32 (short of ignoring the argv and asking for and parsing the command line instead), so this would be an all-or-nothing change. Are there programs that depend on _not_ having auto-globbing on Windows? There might be... At any rate, I can't imagine many programs want POSIX (sh-style) globbing but without other POSIX shell features (at least the different split/quoting/escape rules, if not the various kinds of expansion, etc.); the only reason anyone calls glob.glob for Windows is because it's relatively easy (compared to using win32api to call FindFirstFile, or using win32api to get the whole command line and then using shlex and os to process it, depending on which one they actually wanted) and not _too_ terrible for simple cases. If there's a way to give people something that's not only easier but better, I don't think they'd complain. Sent from a random iPhone On Jan 5, 2015, at 5:19, "Stephen J. Turnbull" wrote: > Steven D'Aprano writes: > >> In any case, having a platform specific globbing module > > By "platform-specific", do you mean one module that handles all > platforms appropriately (what this thread is about), or do you mean > per-platform modules (what "platform-specific" means to me)? > >> is looking more and more useful. Does this need a PEP? > > If you're really serious about putting it in the stdlib, I would > certainly think so. It's absolutely clear that the solution is going > to be complicated and hard to understand. Without a PEP, nobody will > know what is and what is not a bug. Likely even with a PEP a lot of > people will claim the PEP is buggy no matter what it says! I would > hope the different specs will partition the complainers, but I'm not > even sure of that. ;-) > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From abarnert at yahoo.com Mon Jan 5 11:28:21 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Mon, 5 Jan 2015 11:28:21 +0100 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: <54A9EBC4.2010305@stoneleaf.us> References: <1420205066.2836204.208806917.69EED9B5@webmail.messagingengine.com> <20150103015045.GB27426@ando.pearwood.info> <29AE11E7-7347-4C9C-BC4E-996DFA6C1754@yahoo.com> <1752C815-970E-4588-8DEE-523833EC4E8A@yahoo.com> <822B30F1-3A5C-4CF9-BE10-0A818A5241DB@yahoo.com> <20150105011312.GS27426@ando.pearwood.info> <54A9EBC4.2010305@stoneleaf.us> Message-ID: <31C37528-4EE5-4F52-827D-425D5FB1999E@yahoo.com> On Jan 5, 2015, at 2:41, Ethan Furman wrote: > On 01/04/2015 05:13 PM, Steven D'Aprano wrote: > >> Although the quality of contributions is variable, the PHP community has >> made a very interesting decision to integrate community-supplied >> information with official docs: >> >> http://php.net/manual/en/function.dechex.php >> >> I wonder how we might do something similar? > > I hope that we do not. A separate wiki is fine, but the official docs should just have the official stuff in them. MSDN has something similar. They've gone back and forth between a half-dozen different models, and I think at present it's just (formatted) comments on each documentation page. At any rate, it's very clear what's official documentation and what's some guy saying "the docs say you can't do Foo, but here's some code that simulates Foo in most cases". I've found useful stuff there. Then again, I've also found live code (and StackOverflow questions, etc.) that's broken because someone took some sample fragment from a comment and used it inappropriately (often ignoring the very next comment that explains why you shouldn't do that if X, Y, or Z). Both PHP and MSDN have a separate page for each function/method/attribute, while Python has a page per module (broken down into sections that are usually very nicely organized, so I wouldn't want to lose that...), so I'm not sure a similar comment format would work in the first place. Maybe allowing inline comments at every section break, entry, or even paragraph would work (like the way PyGame docs have inline example-search and other links)? But that could easily lead to docs that are so cluttered with comments (or with disclosure triangles, if they start off hidden) that the actual documentation is hard to read. > If the docs were a wiki, we'd have scads of entries on "how to program in Python", In other fora (python-list, python-tutor, StackOverflow, comments on widely-followed blogs, etc.) when someone suggests writing Java-style code instead of Pythonic code they usually get quickly shouted down, often even with good explanations, so I'm not sure things would be any worse on a wiki attached to the Python docs. Also, the Python wiki is already a wiki, and isn't dominated by that kind of cruft. So I'm not sure that problem is as much of a threat. That being said, I agree with your conclusion. Docs seem to work best information that's managed like code; things that aren't quite docs but are useful may work best in other ways, but people have already found the wiki, StackOverflow, ActiveState, blogs, etc. and aren't having any problem using them. And, of all the alternate places to find elaborated documentation, the wiki seems to be among the least popular, which doesn't seem to imply that more wikification is the answer to any relevant question. From abarnert at yahoo.com Mon Jan 5 11:37:22 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Mon, 5 Jan 2015 11:37:22 +0100 Subject: [Python-ideas] Syntax: 'return: ...' expressions In-Reply-To: References: <54AA093A.2050508@gmail.com> <3002533B-C171-49E0-B3DA-CFB08345D370@yahoo.com> Message-ID: On Jan 5, 2015, at 10:55, Chris Angelico wrote: > On Mon, Jan 5, 2015 at 8:49 PM, Andrew Barnert > wrote: >> Finally, are you sure your new return: isn't ambiguous without look ahead or context? When the parser reads "if spam: return", is it starting a return simple statement, or an expression statement that starts with a return expression? Have you tried actually writing out the grammar? > > The way I see it, the return-expression is "return:", whereas the > simple return statement would have no colon. Are you suggesting that "return:" would be a single token (as opposed to all the other colons in the tokenizer), or that you'd use look ahead to disambiguate? I suspect it probably _is_ possible to make something work that fits into Python's parser, but it isn't immediately obvious (at least to me) what that would be, which is why I wanted to see a grammar. (And also to know which "level" this comes at, to automatically answer questions like how it fits into things like conditional expressions and comprehension clauses and so forth.) From dw+python-ideas at hmmz.org Mon Jan 5 11:38:29 2015 From: dw+python-ideas at hmmz.org (David Wilson) Date: Mon, 5 Jan 2015 10:38:29 +0000 Subject: [Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin In-Reply-To: References: Message-ID: <20150105103828.GA22528@k3> I have no problem with this being included somehow in the standard library, but pathlib to me is all about the filesystem, whereas (as others have pointed out), the Recycle Bin and associated concepts on other OS relate pretty uniformly to the OS shell. There are many shell-related concepts that could be nicely exposed, but again I don't think any of them belong in pathlib. For example, labels/tags, owner application, icon, visibility flags, etc. David On Mon, Dec 29, 2014 at 06:54:46PM +0200, Ram Rachum wrote: > Hi guys, > > I want to have a method of?`pathlib.Path` that would send a file to the recycle > bin. (i.e. soft delete.) > > What do you think about adding this?? > > I see there's a PyPI package `Send2Trash` that does this, but it would be nice > if this was in the standard library. > > > Thanks, > Ram. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From rosuav at gmail.com Mon Jan 5 11:46:46 2015 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 5 Jan 2015 21:46:46 +1100 Subject: [Python-ideas] Syntax: 'return: ...' expressions In-Reply-To: References: <54AA093A.2050508@gmail.com> <3002533B-C171-49E0-B3DA-CFB08345D370@yahoo.com>

Message-ID: On Mon, Jan 5, 2015 at 9:37 PM, Andrew Barnert wrote: > Are you suggesting that "return:" would be a single token (as opposed to all the other colons in the tokenizer), or that you'd use look ahead to disambiguate? Oh, I see what you mean. I'm sure this can be dealt with, though; if nothing else, requiring that this kind of expression be parenthesized would do it, as 'return' inside parens has no meaning. It'd be like a genexp. But I still don't think it's a good idea :) ChrisA From alexisl at hp.com Mon Jan 5 12:20:11 2015 From: alexisl at hp.com (Alexis Lee) Date: Mon, 5 Jan 2015 11:20:11 +0000 Subject: [Python-ideas] inspect.getclassdistance Message-ID: <20150105112011.GB7357@hp.com> Hopefully sufficiently documented to stand without introduction: def getclassdistance(srcs, dst): """srcs may be either a single class or a list of (class, distance) pairs. dst is the superclass to find. Performs a breadth-first search for dst, returning the shortest distance. """ if type(srcs) != list: srcs = [(srcs, 0)] if len(srcs) == 0: return None here, distance = srcs[0] if here == dst: return distance newSrc = srcs[1:] + [(c, distance + 1) for c in list(here.__bases__)] return classDistance(newSrc, dst) If this is already implemented and I just couldn't find it, I'm more than happy to withdraw the idea. Alexis -- Nova Engineer, HP Cloud. AKA lealexis, lxsli. From steve at pearwood.info Mon Jan 5 12:43:15 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 5 Jan 2015 22:43:15 +1100 Subject: [Python-ideas] inspect.getclassdistance In-Reply-To: <20150105112011.GB7357@hp.com> References: <20150105112011.GB7357@hp.com> Message-ID: <20150105114315.GZ27426@ando.pearwood.info> On Mon, Jan 05, 2015 at 11:20:11AM +0000, Alexis Lee wrote: > Hopefully sufficiently documented to stand without introduction: Er, not really. What does distance mean in the context of classes? When would you use this? Can you give some examples, e.g. what's the distance between int and str? > def getclassdistance(srcs, dst): > """srcs may be either a single class or a list of (class, distance) pairs. > dst is the superclass to find. > Performs a breadth-first search for dst, returning the shortest distance. > """ > if type(srcs) != list: > srcs = [(srcs, 0)] > if len(srcs) == 0: > return None Shouldn't that be an exception? > here, distance = srcs[0] > if here == dst: > return distance > newSrc = srcs[1:] + [(c, distance + 1) for c in list(here.__bases__)] > return classDistance(newSrc, dst) What's classDistance? > If this is already implemented and I just couldn't find it, I'm more > than happy to withdraw the idea. Explain it first :-) -- Steven From rosuav at gmail.com Mon Jan 5 12:51:33 2015 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 5 Jan 2015 22:51:33 +1100 Subject: [Python-ideas] inspect.getclassdistance In-Reply-To: <20150105112011.GB7357@hp.com> References: <20150105112011.GB7357@hp.com> Message-ID: On Mon, Jan 5, 2015 at 10:20 PM, Alexis Lee wrote: > def getclassdistance(srcs, dst): > """srcs may be either a single class or a list of (class, distance) pairs. > dst is the superclass to find. > Performs a breadth-first search for dst, returning the shortest distance. > """ > > if type(srcs) != list: > srcs = [(srcs, 0)] > if len(srcs) == 0: > return None > here, distance = srcs[0] > if here == dst: > return distance > newSrc = srcs[1:] + [(c, distance + 1) for c in list(here.__bases__)] > return classDistance(newSrc, dst) I'm not 100% sure that I understand what this is doing, so here's a reimplementation of what I think it's doing. Tell me where this one's wrong, and you'll be a long way toward explaining what yours is accomplishing :) def getclassdistance(src, dst): """Measure the shortest parent chain which leads from src to dst Returns the length of the shortest such chain, or None if no chain exists.""" srcs = [(src, 0)] while srcs: here, distance = srcs.pop(0) if here is dst: return distance for c in here.__bases__: srcs.append((c, distance+1)) I'm still not sure what the value of this is, and therefore why it shouldn't just be a personal utility function (not everything needs to be in the stdlib), but if this is an iterative equivalent to your recursive function (assuming that classDistance is getclassdistance), then it's at least reasonably simple. I made a couple of other changes along the way, including requiring that the first arg be a single class (is there any reason, other than recursion, to provide a pre-populated list?), and using 'is' rather than '==' to compare classes. But since I can't test this against your use-case, I can't verify that it's doing the right job. ChrisA From abarnert at yahoo.com Mon Jan 5 13:09:37 2015 From: abarnert at yahoo.com (Andrew Barnert) Date: Mon, 5 Jan 2015 13:09:37 +0100 Subject: [Python-ideas] inspect.getclassdistance In-Reply-To: <20150105112011.GB7357@hp.com> References: <20150105112011.GB7357@hp.com> Message-ID: <3D63844A-E1EA-4708-ADF0-8AB4D8453EDD@yahoo.com> On Jan 5, 2015, at 12:20, Alexis Lee wrote: > Hopefully sufficiently documented to stand without introduction: It doesn't actually run as written (maybe you just used the wrong name in what was supposed to be a recursive call?), and I'm not sure you're doing the BFS right, but I think I can guess what you're after: You're trying to find out if dst is an ancestor of src (the option of taking a list of pairs, despite being documented, seems to be there only for internal use by recursive calls) and, if so, how long the path is between them. And: * Only actual inheritance counts; abc.register or other subclass hooks are ignored. * In case of diamond inheritance where the sides are of unequal length, the shorter one counts (even if that shorter path would never be followed by the c3 rule and therefore isn't even relevant at runtime). * More generally, you don't care about the c3 MRO path, or the actual path taken for any particular method's lookup, just the inheritance path itself. * The actual classes on the path are irrelevant to you, you just want its length. Also, it seems like it would be simpler to just create a general inheritance-BFS-walker function that yields each base as it goes, which would allow you to write this function as a one-liner. I also don't get why you're using recursion rather than a loop here, given that there's nothing interesting on the stack frames. I suspect you wrote this in Common Lisp or OCaml first and then ported it to Python? That might also explain why it's such a strange fit for the way inheritance works in Python. But, most importantly, if I'm right about what this does, I can't think of anywhere I'd want to use it. I can imagine cases (although not very Pythonic ones) where I'd want to know, say, the MRO path (as in dst.__mro__[:dst.__mro__.find(src)][::-1]), but this... When would it ever be interesting? > def getclassdistance(srcs, dst): > """srcs may be either a single class or a list of (class, distance) pairs. > dst is the superclass to find. > Performs a breadth-first search for dst, returning the shortest distance. > """ > > if type(srcs) != list: > srcs = [(srcs, 0)] > if len(srcs) == 0: > return None > here, distance = srcs[0] > if here == dst: > return distance > newSrc = srcs[1:] + [(c, distance + 1) for c in list(here.__bases__)] > return classDistance(newSrc, dst) > > If this is already implemented and I just couldn't find it, I'm more > than happy to withdraw the idea. > > > Alexis > -- > Nova Engineer, HP Cloud. AKA lealexis, lxsli. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From rosuav at gmail.com Mon Jan 5 13:30:28 2015 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 5 Jan 2015 23:30:28 +1100 Subject: [Python-ideas] inspect.getclassdistance In-Reply-To: <3D63844A-E1EA-4708-ADF0-8AB4D8453EDD@yahoo.com> References: <20150105112011.GB7357@hp.com> <3D63844A-E1EA-4708-ADF0-8AB4D8453EDD@yahoo.com> Message-ID: On Mon, Jan 5, 2015 at 11:09 PM, Andrew Barnert wrote: > Also, it seems like it would be simpler to just create a general inheritance-BFS-walker function that yields each base as it goes, which would allow you to write this function as a one-liner. > def bfs_bases(cls): """Yield the base which are belong to us""" yield from cls.__bases__ for cls in cls.__bases__: yield from bfs_bases(cls) :) ChrisA From jdhardy at gmail.com Mon Jan 5 14:25:08 2015 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 5 Jan 2015 13:25:08 +0000 Subject: [Python-ideas] python on mobile In-Reply-To: References: