On 5/3/2017 7:13 PM, Koos Zevenhoven wrote: > On Thu, May 4, 2017 at 1:07 AM, Terry Reedy <tjreedy at udel.edu> wrote: >> On 5/3/2017 2:15 PM, Brett Cannon wrote: >>> >>> My allergies have hit me hard so I'm not thinking at full capacity, but >>> did we ever decide if supporting os.PathLike in the stdlib was viewed as an >>> enhancement or bugfix? Specifically I'm thinking of >>> https://bugs.python.org/issue30218 for adding support to >>> shutil.unpack_archive() and whether it should be backported to 3.6. >> >> >> On the face of it, that particular issue looks like an enhancement that >> should have gone into 3.6 > > Agreed. > >> (if ever), but did not. I notice that >> https://www.python.org/dev/peps/pep-0519/#implementation >> did not include "Update shutil", so it was not done, at least not >> completely. > > Shutil was among the most important to be updated, IMO. > > I had made some sort of list of affected modules elsewhere [1]: > ntpath, posixpath, os.scandir, os.[other stuff], DirEntry (tempted to > say os.DirEntry, but that is > not true), shutil.[stuff], (io.)open, fileinput, filecmp, zipfile, > tarfile, tempfile (for the 'dir' keyword arguments), maybe even glob > and fnmatch (are the patterns paths?) What did not get done for 3.6 should be proposed for 3.7. > It looks like what made it to PEP519 was mainly this: > > "It is expected that most APIs in Python's standard library that > currently accept a file system path will be updated appropriately to > accept path objects (whether that requires code or simply an update to > documentation will vary)." To me that says that not being updated (yet) is not a bug. >> Was shutil updated at all? Is unpack_archive the only shutil function not >> updated? If so, I could see the omission as a bug. >> >> If the patch for 30218 were applied in 3.6, would the doc >> https://docs.python.org/3/library/shutil.html#shutil.unpack_archive >> need to be changed, with a note "Added in 3.6.2: filename can be any >> pathlike object"? If so, it is an enhancement. > > Regardless of bugfix vs enhancement semantics, that seems like a good > thing to do. Enhancing public APIs in normal (non-provisional) modules in bugfix releases has turned out to be a bad thing to do. Hence the policy to not do that. The few exceptions have been necessary to fix a bug that needed to be fixed, and could not reasonably be fixed otherwise. > [1] e.g. in this thread somewhere: > https://mail.python.org/pipermail/python-ideas/2016-April/039827.html -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4