[issue27175] Unpickling Path objects
Antony Lee added the comment: It means the Path/PurePath that would be constructed with the same single str parameter, or equivalently that has the same os.fspath(). -- ___ Python tracker <https://bugs.python.org/issue27175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27175] Unpickling Path objects
Change by Antony Lee : -- keywords: +patch pull_requests: +26526 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28083 ___ Python tracker <https://bugs.python.org/issue27175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44850] Could operator.methodcaller be optimized using LOAD_METHOD?
Change by Antony Lee : -- keywords: +patch pull_requests: +26252 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27782 ___ Python tracker <https://bugs.python.org/issue44850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44019] operator.call/operator.__call__
Antony Lee added the comment: Actually, upon further thought, the semantics I suggested above should go into `operator.caller` (cf. `operator.methodcaller`), and `operator.call`/`operator.__call__` should instead be defined as `operator.call(f, *args, **kwargs) == f(*args, **kwargs)`, so that the general rule `operator.opname(a, b) == a.__opname__(b)` (modulo dunder lookup rules) remains applicable. -- ___ Python tracker <https://bugs.python.org/issue44019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44850] Could operator.methodcaller be optimized using LOAD_METHOD?
New submission from Antony Lee :
Currently, methodcaller is not faster than a plain lambda:
```
In [1]: class T:
...: a = 1
...: def f(self): pass
...:
In [2]: from operator import *
In [3]: %%timeit t = T(); mc = methodcaller("f")
...: mc(t)
...:
...:
83.1 ns ± 0.862 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
In [4]: %%timeit t = T(); mc = lambda x: x.f()
...: mc(t)
...:
...:
81.4 ns ± 0.0508 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```
(on some machines, I find that it is even slower).
Compare with attrgetter, which *is* faster:
```
In [5]: %%timeit t = T(); ag = attrgetter("a")
...: ag(t)
...:
...:
33.7 ns ± 0.0407 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
In [6]: %%timeit t = T(); ag = lambda x: x.a
...: ag(t)
...:
...:
50.1 ns ± 0.057 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```
Given that the operator module explicitly advertises itself as being
"efficient"/"fast", it seems reasonable to try to optimize methodcaller.
Looking at its C implementation, methodcaller currently uses PyObject_GetAttr
followed by PyObject_Call; I wonder whether this can be optimized using a
LOAD_METHOD-style approach to avoid the construction of the bound method (when
applicable)?
--
components: Library (Lib)
messages: 399066
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Could operator.methodcaller be optimized using LOAD_METHOD?
___
Python tracker
<https://bugs.python.org/issue44850>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44019] operator.call/operator.__call__
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue44019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44019] operator.call/operator.__call__
Antony Lee added the comment: > I'm not convinced that operator.caller() would be useful to me. To be clear, as noted above, I have realized that the semantics I initially proposed (now known as "caller") are not particularly useful; the semantics I am proposing (and implementing in the linked PR) are `call(f, *args, **kwargs) == f(*args, **kwargs)`. > I don't see how operator.caller() implements an existing "intrinsic operators > of Python". Agreed; on the other hand function calling is much more intrinsic(?!) > Can't you use functools.partial() for that? How do you propose to do that? Perhaps I am missing an easy solution... -- ___ Python tracker <https://bugs.python.org/issue44019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27161] Confusing exception in Path().with_name
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue27161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33581] Document "optional components that are commonly included in Python distributions."
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue33581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43286] [doc] Clarify that Popen.returncode does not get auto-set when the process terminates
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue43286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23991] ZipFile sanity checks
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue23991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25477] text mode for pkgutil.get_data
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue25477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45962] Clarify that PyModule_AddString{Constant, Macro} use utf-8
New submission from Antony Lee :
The documentation for PyModule_AddString{Constant,Macro} does not specify the
encoding used. Checking the source shows that these simply call
PyUnicode_FromString and thus use utf8, but perhaps this could be made explicit.
--
assignee: docs@python
components: C API, Documentation
messages: 407518
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Clarify that PyModule_AddString{Constant,Macro} use utf-8
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue45962>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26120] pydoc: move __future__ imports out of the DATA block
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue26120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24253] pydoc for namespace packages indicates FILE as built-in
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue24253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46785] On Windows, os.stat() can fail if called while another process is creating or deleting the file
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue46785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46785] On Windows, os.stat() can fail if called while another process is creating or deleting the file
New submission from Antony Lee :
In a first Python process, repeatedly create and delete a file:
from pathlib import Path
while True:
Path("foo").touch(); Path("foo").unlink()
In another process, repeatedly check for the path's existence:
from pathlib import Path
while True: print(Path("foo").exists())
On Linux, the second process prints a random series of True and False. On
Windows, it quickly fails after a few dozen iterations (likely
machine-dependent) with
PermissionError: [WinError 5] Access is denied: 'foo'
which is actually raised by the stat() call.
I would suggest that this is not really desirable behavior?
--
components: Windows
messages: 413468
nosy: Antony.Lee, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: On Windows, os.stat() can fail if called while another process is
creating or deleting the file
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26792] docstrings of runpy.run_{module,path} are rather sparse
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue26792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43721] Documentation of property.{getter, setter, deleter} fails to mention that a *new* property is returned
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue43721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
