[issue42998] pathlib.Path: add `username` argument to `home()`

Barney Gale added the comment: Per discussion, expanduser('~other') is considered unreliable, and we shouldn't add new functions that call through to it. Resolving as 'rejected'. -- resolution: -> rejected stage: patch review ->

[issue44412] Add os.path.fileuri() function

New submission from Barney Gale : Proposal: - Introduce `os.path.fileuri()` function that produces a 'file://' URI - Adjust `PurePosixPath.to_uri()` to call `posixpath.fileuri()` - Adjust `PureWindowsPath.to_uri()` to call `ntpath.fileuri()` - Adjust `nturl2path.pathname2url(

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +25298 pull_request: https://github.com/python/cpython/pull/26708 ___ Python tracker <https://bugs.python.org/issue24

[issue44136] Remove pathlib flavours

Change by Barney Gale : -- pull_requests: +25297 pull_request: https://github.com/python/cpython/pull/26708 ___ Python tracker <https://bugs.python.org/issue44

[issue44412] Add os.path.fileuri() function

Change by Barney Gale : -- keywords: +patch pull_requests: +25296 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26708 ___ Python tracker <https://bugs.python.org/issu

[issue44136] Remove pathlib flavours

Barney Gale added the comment: Depends: bpo-39899, bpo-43757, bpo-44316, bpo-44403, bpo-44412 -- ___ Python tracker <https://bugs.python.org/issue44136> ___ ___

[issue45226] Misleading error message when pathlib.Path.symlink_to() fails with permissions error

Barney Gale added the comment: `os.symlink()` and `pathlib.Path.symlink_to()` have reversed argument orders, but in the repro steps you're supplying arguments in the same order. -- nosy: +barneygale ___ Python tracker <https://bugs.py

[issue39659] pathlib calls `os.getcwd()` without using accessor

New submission from Barney Gale : Whereas most calls to `os` functions from `pathlib.Path` methods happen via `pathlib._Accessor` methods, retrieving the current working directory does not. This problem occurs when calling the `pathlib.Path.cwd()`, `~resolve()` and `~absolute()` methods

[issue39659] pathlib calls `os.getcwd()` without using accessor

Barney Gale added the comment: Those methods are non-pure, i.e. part of `Path` but not `PurePath`. Only impure paths have accessors. The `_Accessor` docstring says: "an accessor implements a particular (system-specific or not) way of accessing paths on the filesystem". This abst

[issue39682] pathlib.Path objects can be used as context managers

New submission from Barney Gale : `pathlib.Path` objects can be used as context managers, but this functionality is undocumented and makes little sense. Example: >>> import pathlib >>> root = pathlib.Path("/") >>> with root: ... print(1)

[issue39783] Optimize construction of Path from other Paths by just returning the same object?

Barney Gale added the comment: Attempted fix shown here: https://github.com/barneygale/cpython/commit/784630ef6ad05031abdefa523e61e0629b15e201 Note that I've already removed context manager support (and hence `_closed`) in this branch. -- nosy: +barne

[issue39682] pathlib.Path objects can be used as context managers

Barney Gale added the comment: Can I ask what sort of backwards-compatibility guarantees Python provides for these cases? In the case of using a Path object as a context manager, I think we can say: - It's easy to do - there's no need to call any underscore-prefixed methods fo

[issue39682] pathlib.Path objects can be used as context managers

Barney Gale added the comment: Also, thank you Antoine for your explanation :-) -- ___ Python tracker <https://bugs.python.org/issue39682> ___ ___ Python-bug

[issue39659] pathlib calls `os.getcwd()` without using accessor

Change by Barney Gale : -- keywords: +patch pull_requests: +18191 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18834 ___ Python tracker <https://bugs.python.org/issu

[issue39894] `pathlib.Path.samefile()` calls `os.stat()` without using accessor

New submission from Barney Gale : `Path.samefile()` calls `os.stat()` directly. It should use the path's accessor object, as `Path.stat()` does. -- components: Library (Lib) messages: 363629 nosy: barneygale priority: normal severity: normal status: open title: `pathlib.Path.sam

[issue39894] `pathlib.Path.samefile()` calls `os.stat()` without using accessor

Change by Barney Gale : -- keywords: +patch pull_requests: +18193 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18836 ___ Python tracker <https://bugs.python.org/issu

[issue39895] `pathlib.Path.touch()` calls `os.close()` without using accessor

New submission from Barney Gale : `Path.touch()` does a lot of os-specific /stuff/ that should probably live in the accessor. Perhaps most importantly, is calls `os.close()` on whatever `accessor.open()` returns, which is problematic for those wishing to write their own accessor that doesn&#

[issue39895] `pathlib.Path.touch()` calls `os.close()` without using accessor

Change by Barney Gale : -- keywords: +patch pull_requests: +18195 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18838 ___ Python tracker <https://bugs.python.org/issu

[issue39897] `pathlib.Path.is_mount()` calls `Path(self.parent)` and therefore misbehaves in `Path` subclasses

New submission from Barney Gale : `pathlib.Path.is_mount()` calls `Path(self.parent)`, which: - Is needless, as `self.parent` is already a Path instance! - Prevents effective subclassing, as `self.parent` may be a `Path` subclass with its own `stat()` implementation -- components

[issue39897] `pathlib.Path.is_mount()` calls `Path(self.parent)` and therefore misbehaves in `Path` subclasses

Change by Barney Gale : -- keywords: +patch pull_requests: +18196 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18839 ___ Python tracker <https://bugs.python.org/issu

[issue39899] `pathlib.Path.expanduser()` does not call `os.path.expanduser()`

New submission from Barney Gale : `pathlib.Path.expanduser()` does not call `os.path.expanduser()`, but instead re-implements it. The implementations look pretty similar and I can't see a good reason for the duplication. The only difference is that `pathlib.Path.expanduser()` r

[issue39899] `pathlib.Path.expanduser()` does not call `os.path.expanduser()`

Barney Gale added the comment: We can check whether `os.path.expanduser()` returned a path beginning with "~" and raise a RuntimeError if so, right? On point #2, I'm not sure this optimization alone justifies the duplicati

[issue39899] `pathlib.Path.expanduser()` does not call `os.path.expanduser()`

Change by Barney Gale : -- keywords: +patch pull_requests: +18198 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18841 ___ Python tracker <https://bugs.python.org/issu

[issue39900] `pathlib.Path.__bytes__()` calls `os.fsencode()` without using accessor

New submission from Barney Gale : `pathlib.Path.__bytes__()` calls `os.fsencode()` without using path's accessor. To properly isolate Path objects from the underlying local filesystem, this should be routed via the accessor object. -- messages: 363638 nosy: barneygale pri

[issue39900] `pathlib.Path.__bytes__()` calls `os.fsencode()` without using accessor

Change by Barney Gale : -- keywords: +patch pull_requests: +18199 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18842 ___ Python tracker <https://bugs.python.org/issu

[issue39901] `pathlib.Path.owner()` and `group()` use `pwd` and `grp` modules directly

New submission from Barney Gale : The implementations of `Path.owner()` and `Path.group()` directly import and use the `pwd` and `grp` modules. Given these modules provide information about the *local* system, I believe these implementations should instead live in `pathlib._NormalAccessor

[issue39901] `pathlib.Path.owner()` and `group()` use `pwd` and `grp` modules directly

Change by Barney Gale : -- keywords: +patch pull_requests: +18201 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18844 ___ Python tracker <https://bugs.python.org/issu

[issue39899] `pathlib.Path.expanduser()` does not call `os.path.expanduser()`

Barney Gale added the comment: I see no reason for the duplication, and I can point to one concrete bug affecting your re-implementation of `expanduser` that doesn't affect the original, i.e. that a `KeyError` is raised on Windows when `"USERNAME"` is not present in `os.en

[issue39682] pathlib.Path objects can be used as context managers

Change by Barney Gale : -- keywords: +patch pull_requests: +18203 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18846 ___ Python tracker <https://bugs.python.org/issu

[issue39899] `pathlib.Path.expanduser()` does not call `os.path.expanduser()`

Barney Gale added the comment: The only design flaw mentioned in that thread is that `os.path.expanduser()` returns the input unchanged if expansion fails, which is not very pythonic. However, such a problem doesn't necessitate a rewrite of `os.path.expanduser()`. Checking `result[:1

[issue39906] pathlib.Path: add `follow_symlinks` argument to `stat()` and `chmod()`

New submission from Barney Gale : As of Python 3.3, `os.lstat()` and `os.lchmod()` are available as `os.stat(follow_symlinks=False)` and `os.chmod(follow_symlinks=False)`, but an equivalent change didn't make it into pathlib. I propose we add the `follow_symlinks` argument to `Path

[issue39906] pathlib.Path: add `follow_symlinks` argument to `stat()` and `chmod()`

Change by Barney Gale : -- keywords: +patch pull_requests: +18221 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18864 ___ Python tracker <https://bugs.python.org/issu

[issue7479] os.lchmod is not present

Change by Barney Gale : -- nosy: +barneygale nosy_count: 5.0 -> 6.0 pull_requests: +18222 pull_request: https://github.com/python/cpython/pull/18864 ___ Python tracker <https://bugs.python.org/iss

[issue39907] `pathlib.Path.iterdir()` wastes memory by using `os.listdir()` rather than `os.scandir()`

New submission from Barney Gale : `pathlib.Path.iterdir()` uses `os.listdir()` rather than `os.scandir()`. I think this has a small performance cost, per PEP 471: > It returns a generator instead of a list, so that scandir acts as a true > iterator instead of returning the ful

[issue39907] `pathlib.Path.iterdir()` wastes memory by using `os.listdir()` rather than `os.scandir()`

Change by Barney Gale : -- keywords: +patch pull_requests: +18223 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18865 ___ Python tracker <https://bugs.python.org/issu

[issue39907] `pathlib.Path.iterdir()` wastes memory by using `os.listdir()` rather than `os.scandir()`

Barney Gale added the comment: Ah, right you are! The globbing helpers call `list(os.scandir(...))` - perhaps we should do the same here? -- ___ Python tracker <https://bugs.python.org/issue39

[issue39907] `pathlib.Path.iterdir()` wastes memory by using `os.listdir()` rather than `os.scandir()`

Barney Gale added the comment: Less reliable how? Doesn't appear any slower: barney.gale@heilbron:~$ python3 -m timeit -s "import os; os.listdir('/usr/local')" 1 loops, best of 3: 0.0108 usec per loop barney.gale@heilbron:~$ python3 -m timeit -s "imp

[issue39907] `pathlib.Path.iterdir()` wastes memory by using `os.listdir()` rather than `os.scandir()`

Change by Barney Gale : -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue39907] `pathlib.Path.iterdir()` wastes memory by using `os.listdir()` rather than `os.scandir()`

Barney Gale added the comment: Thanks Rémi and Serhiy! Closing this ticket as the patch doesn't provide any sort of improvement. -- ___ Python tracker <https://bugs.python.org/is

[issue39900] `pathlib.Path.__bytes__()` calls `os.fsencode()` without using accessor

Barney Gale added the comment: Closing after @pitrou clarified the meaning of __fspath__() here: https://discuss.python.org/t/make-pathlib-extensible/3428/12?u=barneygale -- resolution: -> not a bug stage: patch review -> resolved status: open -&g

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

New submission from Barney Gale : Small bug report encompassing some related issues in `pathlib._NormalAccessor`: - `link_to()` should be named `link()` for consistency with other methods - `symlink()` doesn't need to guard against `os.symlink()` not accepting `target_is_directory` o

[issue39925] `pathlib.Path.link_to()` has the wrong argument order

New submission from Barney Gale : `mylink.symlink_to(target)` and `mylink.link_to(target)` should both create a link (soft or hard) at *mylink* that points to *target*. But `link_to()` does the opposite - it creates *target* and points it towards *mylink*. Correct behaviour from `symlink_to

[issue39925] `pathlib.Path.link_to()` has the wrong argument order

Barney Gale added the comment: I'm not sure how it can be fixed on the documentation side - it's difficult to explain that `a.link_to(b)` creates a link from B to A, and not vice-versa. We could introduce a new method that does the right thing? `Path.h

[issue39925] `pathlib.Path.link_to()` has the wrong argument order

Change by Barney Gale : -- keywords: +patch pull_requests: +18264 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18909 ___ Python tracker <https://bugs.python.org/issu

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Barney Gale added the comment: Good points! Do you know of an example of a community library that uses `_Accessor.link`? Thanks -- ___ Python tracker <https://bugs.python.org/issue39

[issue39291] "pathlib.Path.link_to()" and "pathlib.Path.symlink_to()" have reversed usage

Barney Gale added the comment: Per discussion on the mailing list, I'd like to request that this bug be re-opened. https://mail.python.org/archives/list/python-...@python.org/thread/7QPLYW36ZK6QTW4SV4FI6C343KYWCPAT/ -- nosy: +barne

[issue39950] Add pathlib.Path.hardlink_to()

New submission from Barney Gale : Per bpo-39291, the argument order for `pathlib.Path.link_to()` is inconsistent with `symlink_to()` and its own documentation. This ticket covers adding a new `hardlink_to()` method with the correct argument order, and deprecating `link_to()`. Discussion on

[issue39950] Add pathlib.Path.hardlink_to()

Change by Barney Gale : -- keywords: +patch pull_requests: +18321 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18909 ___ Python tracker <https://bugs.python.org/issu

[issue40038] pathlib: remove partial support for preserving accessor when modifying a path

New submission from Barney Gale : `pathlib.Path._init()` accepts a 'template' argument that pathlib uses - in some cases - to preserve the current accessor object when creating modified path objects. This works for `resolve()`, `absolute()` and `readlink()`, *but no other c

[issue39950] Add pathlib.Path.hardlink_to()

Barney Gale added the comment: A question: For my patch, I need to include a Python version where `Path.link_to()` will become unavailable. I'm not entirely sure how this should be determined. Some factors in play: - `link_to()` was added in Python 3.8 - On github, I found these

[issue24132] Direct sub-classing of pathlib.Path

Barney Gale added the comment: I'm taking another look at making `pathlib` extensible. There's some discussion here: https://discuss.python.org/t/make-pathlib-extensible/3428 List or preparatory bugfixes and tidy-ups: https://docs.google.com/spre

[issue40107] pathlib: make `_Accessor.open()` return a file object and not a file descriptor

New submission from Barney Gale : This is one of a series of bug reports / PRs that lay the groundwork for making pathlib extensible. See here for detail: https://discuss.python.org/t/make-pathlib-extensible/3428 Currently `_Accessor.open()` is expected to function like `os.open()` and

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Change by Barney Gale : -- pull_requests: +18582 pull_request: https://github.com/python/cpython/pull/19220 ___ Python tracker <https://bugs.python.org/issue39

[issue40038] pathlib: remove partial support for preserving accessor when modifying a path

Change by Barney Gale : -- keywords: +patch pull_requests: +18706 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19342 ___ Python tracker <https://bugs.python.org/issu

[issue39950] Add pathlib.Path.hardlink_to()

Barney Gale added the comment: Makes sense to me. Should I leave the documentation for `link_to` completely alone? With the addition of a similar function, I wonder if that may in itself cause confusion. -- ___ Python tracker <ht

[issue42998] pathlib.Path: add `username` argument to `home()`

New submission from Barney Gale : The `pathlib.Path.home()` function looks like: @classmethod def home(cls): """Return a new path pointing to the user's home directory (as returned by os.path.expanduser('~')). """

[issue42998] pathlib.Path: add `username` argument to `home()`

Barney Gale added the comment: I should add that this is part of a plan to spin out some `Path` methods into a new `UserPath` class. Notably, in this case, `UserPath.expanduser()` will call `self.home()` under-the-hood. This is done to reduce the surface area of abstract methods that

[issue42999] `pathlib.Path.link_to()` documentation is misleading

New submission from Barney Gale : Compare the documentation of `symlink_to()` and `link_to()`: .. method:: Path.symlink_to(target, target_is_directory=False) Make this path a symbolic link to *target*. .. method:: Path.link_to(target) Create a hard link pointing to a path named

[issue39950] Add pathlib.Path.hardlink_to()

Barney Gale added the comment: I've logged bpo-42999 to cover fixing the existing `link_to()` docs issues. PR incoming... -- ___ Python tracker <https://bugs.python.org/is

[issue42999] `pathlib.Path.link_to()` documentation is misleading

Change by Barney Gale : -- keywords: +patch pull_requests: +23116 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18909 ___ Python tracker <https://bugs.python.org/issu

[issue42999] `pathlib.Path.link_to()` documentation is misleading

Change by Barney Gale : -- pull_requests: +23117 pull_request: https://github.com/python/cpython/pull/24294 ___ Python tracker <https://bugs.python.org/issue42

[issue43012] Remove pathlib accessors

New submission from Barney Gale : Per Pitrou: > The original intent for the “accessor” thing was to have a variant that did > all accesses under a filesystem tree in a race condition-free way using > openat and friends. It turned out to be much too hairy to actually implement,

<    1   2