[Python-ideas] New PEP proposal -- Pathlib Module ShouldContain All File Operations -- version 2

Fri Mar 23 16:09:22 EDT 2018

On Mar 23, 2018, at 7:26 AM, Steve Dower <steve.dower at python.org> wrote:

I had a colleague complaining to me the other day about having to search
multiple packages for the right function to move a file (implying: with the
same semantics as drag-drop).

Thanks Steve — I know there isn’t any kind of consensus about exactly what
should be part of a “most file operations” package/class, but I’ve found it
odd that there doesn’t even seem to be acknowledgment among longtime python
users that the current hodgepodge is pretty dysfunctional for new users.

One thing that’s been hammered home for me teaching newbies is that people
get very far with computing these days without ever having touched a
command line — certainly not a *nix one. Even the concept of a working
directory is foreign to many.

So telling them that they can create and manipulate paths in nifty ways
with the Path object, but then telling them to go to the os module to do
simple things like rename or delete a file, and then looking at the docs
for the os module, which starts with a bunch of references to other modules
you need for not quite as simple things (shutil) or more complex things
(tempfile). Then you look through the module and see a LOT of low level
cryptic and semi-platform dependent functions — not newbie friendly.

Heck, I’ve been using Python for almost 20 years and I still have go look
up whether it’s “delete” or “remove” or “unlink”. And there is so much in
os that ipython or IDE completion doesn’t help much.

So as not to only write a critical rant — here is a proposal of sorts:

The python standard library should have one-stop shopping for the basic
file system manipulations. “Basic” could be guided by “what users typically
do with a GUI file manager”

This could be yet another module, but given that navigating  the file
system ( I.e. path manipulation) is one of the things people typically do
with a file manager, it makes sense to add it all to pathlib, maybe even
all to the Path object. ( though maybe more advanced classes/functions
could be added to pathlib as way to put it all in one place, while not
expanding the Path namespace too much)

Of course, this will require a substantial amount of work to work out the
details in a PEP. I don’t have the time to do that, but if the OP or
someone else does, I’ll help.

-CHB

If there isn’t a pathtools library on PyPI yet, this would certainly be
valuable for newer developers. My view on Path is to either have everything
on it or nothing on it (without removing what’s already there, of course),
and since everything is so popular we should at least put everything in the
one place.

Top-posted from my Windows phone

*From: *Mike Miller <python-ideas at mgmiller.net>
*Sent: *Monday, March 19, 2018 10:51
*To: *python-ideas at python.org
*Subject: *Re: [Python-ideas] New PEP proposal -- Pathlib Module
ShouldContain All File Operations -- version 2

On 2018-03-18 10:55, Paul Moore wrote:

>> Should Path() have methods to access all file operations?

>

> No, (Counterexample, having a Path operation to set Windows ACLs for a
path).

Agreed, not a big fan of everything filesystem-related in pathlib, simply

because it doesn't read well.  Having them scattered isn't a great
experience

either.

Perhaps it would be better to have a filesystem package instead, maybe
named

"fs" that included all this stuff in one easy to use location.  File stuff
from

os, path stuff from os.path, pathlib, utils like stat, and shutil etc?

_______________________________________________

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: <http://mail.python.org/pipermail/python-ideas/attachments/20180323/ca5c935a/attachment.html>