Hi Folks, it seems for me that the welcoming of this proposal is rather positive than not.
Of course several details could be put into it, but I think it would better to let the developers decide the details, because they know the environment and the possibilities. The name of the functions and the method they solve the problem (for example rmdir(tree=True9 instead of removedirs()) is all the same. The (main) goal would be that file and directory operations reside in one module. And currently the pathlib seems to be the best candidate. (we could put then into a very new module, but it would be just another duplicataion) So what do You think, this proposal IS PEPable or should I do something with this to achieve the PEPable state? BR, George 2018-03-18 9:05 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>: > On 16 March 2018 at 03:15, Chris Angelico <ros...@gmail.com> wrote: > >> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof <geo...@fischhof.hu> >> wrote: >> > >> > >> > " if new file functions are added, they will go only in pathlib, >> > which makes pathlib effectively mandatory;" >> > Yes but I think this part of the evolution: slowly everyone will shift >> to >> > pathlib, >> > and being mandatory is true for the current status as well: if you need >> a >> > function, you need the module. >> > Right now if you wan to execute some file operations, you need os plus >> > shutil, because the half of the >> > functions are in one of them, the other half is in the other module >> >> The os module is cheap; pathlib has a definite cost. If every file >> operation goes through pathlib > > > Keep in mind that the `os` layer will never go away: `pathlib` still needs > a lower level API to call to *do the work* of actually interacting with the > underlying operating system APIs (e.g. this is why we added os.scandir). > > A similar situation applies when it comes to glob, fnmatch, etc. > > Even `shutil` will likely retain its place as a lower level procedural API > behind pathlib's object-oriented facade, since raw strings are still > frequently going to be easier to work with when mixing and matching Python > code and native operating system shell code. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
