[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
[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
[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
[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
[issue37881] __text_signature__ parser doesn't handle globals in extension module
New submission from Antony Lee :
Starting from the custom2 example at
https://docs.python.org/3/extending/newtypes_tutorial.html#adding-data-and-methods-to-the-basic-example,
change the methods table to
static PyMethodDef Custom_methods[] = {
{"foo", (PyCFunction) Custom_foo, METH_VARARGS,
"foo(x=ONE)\n--\n\nFoos this."
},
{NULL} /* Sentinel */
};
and add a global ONE to the module dict:
PyModule_AddObject(m, "ONE", PyLong_FromLong(1));
Building and running e.g. pydoc on this module results in
Traceback (most recent call last):
File ".../lib/python3.7/inspect.py", line 2003, in wrap_value
value = eval(s, module_dict)
File "", line 1, in
NameError: name 'ONE' is not defined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File ".../lib/python3.7/inspect.py", line 2006, in wrap_value
value = eval(s, sys_module_dict)
File "", line 1, in
NameError: name 'ONE' is not defined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File ".../lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File ".../lib/python3.7/inspect.py", line 2008, in wrap_value
raise RuntimeError()
RuntimeError
I think the fix is fairly simple; one needs to replace
module_name = getattr(obj, '__module__', None)
in inspect.py::_signature_fromstr by
module_name = (getattr(obj, '__module__', None)
or getattr(getattr(obj, '__objclass__'), '__module__', None))
(This is a less general but simpler solution than
https://bugs.python.org/issue23967.)
--
components: Extension Modules
messages: 349919
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: __text_signature__ parser doesn't handle globals in extension module
___
Python tracker
<https://bugs.python.org/issue37881>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37743] How should contextmanager/ContextDecorator work with generators?
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue37743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38045] Flag instance creation is slow
New submission from Antony Lee :
Consider the following example
from enum import Flag
F = Flag("F", list("abcdefghijklm"))
for idx in range(2**len(F) - 1):
F(idx)
creating all possible combos of 13 flags, so 8192 instances (yes, I know the
instances are cached later, but the initial cost is still significant).
Locally, this takes over 4.5s to execute; profiling shows that ~30% of that
time is spent executing enum._is_power_of_two(!):
def _power_of_two(value):
if value < 1:
return False
return value == 2 ** _high_bit(value)
Indeed, replacing the implementation of _power_of_two by
import math
_powers_of_two = {
2 ** i for i in range(math.ceil(math.log2(sys.maxsize)) + 1)}
def _power_of_two(value):
return (value in _powers_of_two if value <= sys.maxsize
else value == 2 ** _high_bit(value))
shaves off ~30% of the runtime (obviously this won't help for huge
(>sys.maxsize) flag values, but these are rarer I would think).
An even better fix, I think, would be for Flag to cache `flags_to_check`
(updating it at the same time as `_value2member_map_`) instead of recomputing
it each time in _decompose
flags_to_check = [
(m, v)
for v, m in list(flag._value2member_map_.items())
if m.name is not None or _power_of_two(v)
]
as this actually needlessly introduces quadratic complexity when iterating over
all possible combos (because the size of _value2member_map_ is growing).
(Also, it's not actually clear to me how one can end up with unnamed
power-of-two instances in _value2member_map?)
--
messages: 351244
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Flag instance creation is slow
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38045>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38045] enum.Flag instance creation is slow
Antony Lee added the comment: Actually, microoptimizing _power_of_two is a red herring and the problem is the quadratic complexity of _decompose (_value2member_map_ becomes bigger and bigger at each iteration). Replacing the implementation of _decompose by the following fixes the performance issue (the original snippet executes in ~150ms, which may be even more optimizable but already a 30x improvement :)), and still passes test_enum.py (from cpython 3.7.4): def _decompose(flag, value): """Extract all members from the value.""" # _decompose is only called if the value is not named not_covered = value members = [] for member in flag: member_value = member.value if member_value and member_value & value == member_value: members.append(member) not_covered &= ~member_value if issubclass(flag, IntFlag) and value > 0: while not_covered: new_value = 2 ** _high_bit(not_covered) if new_value not in flag._value2member_map_: # construct singleton pseudo-members pseudo_member = int.__new__(flag, value) pseudo_member._name_ = None pseudo_member._value_ = value flag._value2member_map_.setdefault(value, pseudo_member) members.append(flag(new_value)) not_covered &= ~new_value if not members and value in flag._value2member_map_: members.append(flag._value2member_map_[value]) members.sort(key=lambda m: m._value_, reverse=True) if len(members) > 1 and members[0].value == value: # we have the breakdown, don't need the value member itself members.pop(0) return members, not_covered Checking for issubclass(flag, IntFlag) is a bit ugly but that's because Flag and IntFlag really need two separate implementations of _decompose -- the former wants to error out on uncovered values, the latter should create them on-the-fly. -- ___ Python tracker <https://bugs.python.org/issue38045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38603] inspect.getdoc could examine the __class__ cell for dynamically generated subclasses
New submission from Antony Lee : Currently, `inspect.getdoc()` fails to inherit docstrings in dynamically generated subclasses, such as ``` class Base: def method(self): "some docstring" def make_subclass(): class subclass(Base): def method(self): return super().method() return subclass subclass = make_subclass() inspect.getdoc(subclass.method) # => returns None ``` because `inspect._findclass()` tries to find the base class by parsing `subclass.method.__qualname__` which is `"make_subclass..subclass.method"` and chokes over `..`. In the case where the method does rely on `super()`, there is another way we can go back to the "owning" class of the method: by looking up the contents of the `__class__` cell (which is set up to make 0-arg super()). Perhaps a `__class__` cell could even be set up for *all* methods defined in dynamically created subclasses (i.e. whose `__qualname__` includes `..`), to help with introspection? -- components: Library (Lib) messages: 355472 nosy: Antony.Lee priority: normal severity: normal status: open title: inspect.getdoc could examine the __class__ cell for dynamically generated subclasses versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38603] inspect.getdoc could examine the __class__ cell for dynamically generated subclasses
Change by Antony Lee : -- keywords: +patch pull_requests: +16485 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16957 ___ Python tracker <https://bugs.python.org/issue38603> ___ ___ 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
New submission from Antony Lee :
property.{getter,setter,deleter} returns a new property with a new
{fget,fset,fdel}. This is documented at
https://docs.python.org/3/library/functions.html#property, and intended
behavior (see e.g. https://bugs.python.org/issue1620).
However the corresponding docstrings, e.g. `pydoc property.getter`, are
"Descriptor to change the getter (setter, deleter) on a property." This
wording suggests that no copy is being made and that the property is mutated
in-place.
--
assignee: docs@python
components: Documentation
messages: 390149
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Documentation of property.{getter,setter,deleter} fails to mention that
a *new* property is returned
___
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
[issue44019] operator.call/operator.__call__
New submission from Antony Lee : Adding a call/__call__ function to the operator module (where `operator.call(*args, **kwargs)(func) == func(*args, **kwargs)`, similarly to operator.methodcaller) seems consistent with the design with the rest of the operator module. An actual use case I had for such an operator was collecting a bunch of callables in a list and wanting to dispatch them to concurrent.futures.Executor.map, i.e. something like `executor.map(operator.call, funcs)` (to get the parallelized version of `[func() for func in funcs]`). -- components: Library (Lib) messages: 392809 nosy: Antony.Lee priority: normal severity: normal status: open title: operator.call/operator.__call__ versions: Python 3.11 ___ 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
[issue44189] multiprocessing AF_PIPE name format is slightly confusing in the docs
New submission from Antony Lee :
https://docs.python.org/3/library/multiprocessing.html#address-formats
currently states
> An 'AF_PIPE' address is a string of the form r'\.\pipe{PipeName}'. To use
> Client() to connect to a named pipe on a remote computer called ServerName
> one should use an address of the form r'\ServerName\pipe{PipeName}' instead.
which suggests that if the pipe is named "foo", the string should be
r'\.\pipe{foo}' (especially given that the other substituted string,
ServerName, is given in italics... but actually the correct format is
r'\.\pipe\foo'.
Hence I would suggest fixing the markup to give name formats as
r'\.pipe\PipeName' where PipeName, is in italics, like ServerName.
--
assignee: docs@python
components: Documentation
messages: 394020
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: multiprocessing AF_PIPE name format is slightly confusing in the docs
___
Python tracker
<https://bugs.python.org/issue44189>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34389] CPython may fail to build in the presence of a ~/.pydistutils.cfg
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue34389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20012] Re: Allow Path.relative_to() to accept non-ancestor paths
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue20012> ___ ___ 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
[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
[issue38956] argparse.BooleanOptionalAction should not add the default value to the help string by default
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue38956> ___ ___ 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 : -- keywords: +patch pull_requests: +26342 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27888 ___ 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
[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
[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
Antony Lee added the comment: You are correct as to the meaning of "convert". The alternative approach you suggest would also work, but that seems to go much more against the design of pathlib to me. OTOH I guess it is up to Antoine to rule on that. -- ___ 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
Antony Lee added the comment: Despite the now well-known security limitations of pickle, it is still used as a simple way (from the user PoV) to exchange arbitrary Python objects (see e.g. https://joblib.readthedocs.io/en/latest/persistence.html). Such objects can sometimes include Paths as attributes, and it seems unfortunate that the presence of a Path makes the entire object (which may include many more things than just the Path) impossible to unpickle on a different OS (especially if unpickling into a PurePath keeps all the functionality that makes sense on that other OS). -- ___ 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
Antony Lee added the comment: I guess I could instead add some OS-dependent entries for Path classes into _compat_pickle (to do the remapping at load time) if you prefer? I don't have a strong preference either-way. -- ___ 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
[issue44019] operator.call/operator.__call__
Antony Lee added the comment:
Python2's apply has different semantics: it takes non-unpacked arguments, i.e.
def apply(f, args, kwargs={}): return f(*args, **kwargs)
rather than
def call(f, *args, **kwargs): return f(*args, **kwargs)
I agree that both functions can be written in two (or one) line, but the same
can be said of most functions in the operator module (def add(x, y): return x +
y); from the module's doc ("efficient functions corresponding to the intrinsic
operators"), I would argue that the criteria for inclusion are efficiency
(operator.call is indeed fast, see the linked PR) and intrinsicness (I don't
know if there's a hard definition, but function calling certainly seems
intrinsic).
--
___
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__
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
[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
[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
[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
[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
[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
[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
[issue38956] argparse.BooleanOptionalAction should not add the default value to the help string by default
New submission from Antony Lee :
https://bugs.python.org/issue8538 recently added to Py3.9 a much welcome
addition to argparse, namely the capability to generate --foo/--no-foo flag
pairs. A small issue with the implementation is that it *always* appends the
default value to the help string (if any):
if help is not None and default is not None:
help += f" (default: {default})"
This is inconsistent with other action classes, and results in the defaults
being printed twice if using ArgumentsDefaultHelpFormatter (which is the
documented way to include the defaults in the help text):
from argparse import *
parser = ArgumentParser(formatter_class=ArgumentDefaultsHelpFormatter)
parser.add_argument("--foo", action=BooleanOptionalAction, help="Whether to
foo it", default=True)
parser.add_argument("--quux", help="Set the quux", default=42)
print(parser.parse_args())
yields
usage: foo.py [-h] [--foo | --no-foo] [--quux QUUX]
optional arguments:
-h, --help show this help message and exit
--foo, --no-foo Whether to foo it (default: True) (default: True) #
<--- HERE
--quux QUUX Set the quux (default: 42)
I think the fix is just a matter of not adding the default value to the help
string.
--
components: Library (Lib)
messages: 357733
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: argparse.BooleanOptionalAction should not add the default value to the
help string by default
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue38956>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39461] os.environ does not support Path-like values, but subprocess(..., env=...) does
New submission from Antony Lee :
As of Py3.8/Linux:
In [1]: os.environ["foo"] = Path("bar")
---
TypeError Traceback (most recent call last)
in
> 1 os.environ["foo"] = Path("bar")
~/miniconda3/envs/default/lib/python3.8/os.py in __setitem__(self, key,
value)
676 def __setitem__(self, key, value):
677 key = self.encodekey(key)
--> 678 value = self.encodevalue(value)
679 self.putenv(key, value)
680 self._data[key] = value
~/miniconda3/envs/default/lib/python3.8/os.py in encode(value)
746 def encode(value):
747 if not isinstance(value, str):
--> 748 raise TypeError("str expected, not %s" %
type(value).__name__)
749 return value.encode(encoding, 'surrogateescape')
750 def decode(value):
TypeError: str expected, not PosixPath
In [2]: subprocess.run('echo "$foo"', env={**os.environ, "foo":
Path("bar")}, shell=True)
bar
Out[2]: CompletedProcess(args='echo "$foo"', returncode=0)
I guess it would be nice if it was possible to set os.environ entries to
Path-like values, but most importantly, it seems a bit inconsistent that doing
so is not possible on os.environ, but works when setting the `env` of a
subprocess call.
--
components: Library (Lib)
messages: 360750
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: os.environ does not support Path-like values, but subprocess(...,
env=...) does
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39461>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)
Antony Lee added the comment: FWIW, I'm actually fine with not supporting Path objects in os.environ, as long as the behavior is *consistent* with the env kwarg to subprocess.run() -- note that the original title of the thread only pointed out to the inconsistency, and did not strongly request that os.environ support Paths. -- ___ Python tracker <https://bugs.python.org/issue39461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39716] argparse.ArgumentParser does not raise on duplicated subparsers, even though it does on duplicated flags
New submission from Antony Lee :
If one tries to add twice the same flag to an ArgumentParser, one gets a
helpful exception:
from argparse import ArgumentParser
p = ArgumentParser()
p.add_argument("--foo")
p.add_argument("--foo")
results in
argparse.ArgumentError: argument --foo: conflicting option string: --foo
However, adding twice the same subparser raises no exception:
from argparse import ArgumentParser
p = ArgumentParser()
sp = p.add_subparsers()
sp.add_parser("foo")
sp.add_parser("foo")
even though the two subparsers shadow one another in the same way as two
identical flags.
--
components: Library (Lib)
messages: 362421
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser does not raise on duplicated subparsers, even
though it does on duplicated flags
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39716>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39716] argparse.ArgumentParser does not raise on duplicated subparsers, even though it does on duplicated flags
Change by Antony Lee : -- keywords: +patch pull_requests: +17971 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18605 ___ Python tracker <https://bugs.python.org/issue39716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39716] argparse.ArgumentParser does not raise on duplicated subparsers, even though it does on duplicated flags
Antony Lee added the comment: Sure, https://github.com/python/cpython/pull/18605 it is. -- ___ Python tracker <https://bugs.python.org/issue39716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23080] BoundArguments.arguments should be unordered
Antony Lee added the comment: Done in bugs.python.org/issue36350 / https://github.com/python/cpython/pull/12412. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue23080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39775] inspect.Signature.parameters should be an OrderedDict, not a plain dict
New submission from Antony Lee : https://bugs.python.org/issue36350 / https://github.com/python/cpython/pull/12412 changed Signature.parameters and BoundArguments.arguments to be plain dicts, not OrderedDicts (for Py3.9a4). Even though I agree for BoundArguments.arguments (in fact I argued for this behavior in https://bugs.python.org/issue23080), I think Signature.parameters should remain OrderedDicts. Otherwise, one would get >>> inspect.signature(lambda x, y: None).parameters == inspect.signature(lambda y, x: None).parameters True which seems plain wrong (comparing the signature objects themselves still correctly return False because __eq__ explicitly considers parameter order, but one may e.g. want to compare parameters for equality while ignoring the return annotation). -- components: Library (Lib) messages: 362800 nosy: Antony.Lee priority: normal severity: normal status: open title: inspect.Signature.parameters should be an OrderedDict, not a plain dict versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39775] inspect.Signature.parameters should be an OrderedDict, not a plain dict
Antony Lee added the comment: It looks good to me, thanks. -- ___ Python tracker <https://bugs.python.org/issue39775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39783] Optimize construction of Path from other Paths by just returning the same object?
New submission from Antony Lee :
Many functions which take a path-like object typically also accept strings
(sorry, no hard numbers here). This means that if the function plans to call
Path methods on the object, it needs to first call Path() on the arguments to
convert them, well, to Paths. This adds an unnecessary cost in the case where
the argument is *already* a Path object (which should become more and more
common as the use of pathlib spreads), as Path instantiation is not exactly
cheap (it's on the order of microseconds).
Instead, given that Paths are immutable, `Path(path)` could just return the
exact same path instance, completely bypassing instance creation (after
checking that the argument's type exactly matches whatever we need and is not,
say, PureWindowsPath when we want to instantiate a PosixPath, etc.). Note that
there is prior art for doing so in CPython: creating a frozenset from another
frozenset just returns the same instance:
```
In [1]: s = frozenset({1}); id(s) == id(frozenset(s)) == id(s.copy())
Out[1]: True
```
--
components: Library (Lib)
messages: 362874
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Optimize construction of Path from other Paths by just returning the
same object?
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39783>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39783] Optimize construction of Path from other Paths by just returning the same object?
Antony Lee added the comment: Decorating __new__ with lru_cache would likely run into memory leakage problems? (one would need a "weak lru_cache", I guess). I didn't know about the _closed attribute. From a quick look it appears to only be settable by using the path (not the actual file) as a context manager, and only serves to block further filesystem methods, but I'm not even sure why? (for example, it doesn't block fspath, so it won't prevent operations via os.path functions anyways...) -- ___ Python tracker <https://bugs.python.org/issue39783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39682] pathlib.Path objects can be used as context managers
Antony Lee added the comment:
A problem of having this bit of state in paths is that it violates assumptions
based on immutability/hashability, e.g. with
from pathlib import Path
p = Path("foo")
q = Path("foo")
with p: pass
unique_paths = {p, q}
print(len(unique_paths)) # == 1, as p == q
for path in unique_paths:
print(path.resolve()) # Fails if the path is closed.
The last line fails with `unique_paths = {p, q}` as p has been closed (and
apparently sets keep the first element when multiple "equal" elements are
passed in), but not with `unique_paths = {q, p}`.
It would also prevent optimizations based on immutability as proposed in
https://bugs.python.org/issue39783.
--
nosy: +Antony.Lee
___
Python tracker
<https://bugs.python.org/issue39682>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39775] inspect.Signature.parameters should be an OrderedDict, not a plain dict
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue39775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23080] BoundArguments.arguments should be unordered
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue23080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39682] pathlib.Path objects can be used as context managers
Antony Lee added the comment: Immutability and hashability are listed first among "general properties" of paths (https://docs.python.org/3/library/pathlib.html#general-properties), and in the PEP proposing pathlib (https://www.python.org/dev/peps/pep-0428/#immutability). Looking at it again I *guess* the docs version could be read as only guaranteeing this for PurePaths (because that's in the PurePath section) rather than Path, but the PEP version clearly implies that this is true for both PurePaths and concrete Paths. It may be tricky to check usage in third-party packages, given that one would need to look for `with : ...` rather than, say, a method name which can be grepped. Do you have any suggestions here? -- ___ Python tracker <https://bugs.python.org/issue39682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25024] Allow passing "delete=False" to TemporaryDirectory
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue25024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39682] pathlib.Path objects can be used as context managers
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue39682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40313] bytes.hex(sep, bytes_per_sep) is many times slower than manually inserting the separators
New submission from Antony Lee :
Consider the following example, linewrapping 10^4 bytes in hex form to 128
characters per line, on Py 3.8.2 (Arch Linux repo package):
In [1]: import numpy as np, math
In [2]: data = np.random.randint(0, 256, (100, 100),
dtype=np.uint8).tobytes()
In [3]: %timeit data.hex("\n", -64)
123 µs ± 5.8 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)
In [4]: %timeit h = data.hex(); "\n".join([h[n * 128 : (n+1) * 128] for n
in range(math.ceil(len(h) / 128))])
45.4 µs ± 746 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)
In [5]: h = data.hex(); "\n".join([h[n * 128 : (n+1) * 128] for n in
range(math.ceil(len(h) / 128))]) == data.hex("\n", -64)
Out[5]: True
(the last line checks the validity of the code.)
It appears that a naive manual wrap is nearly 3x faster than the builtin
functionality.
--
components: Library (Lib)
messages: 366678
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: bytes.hex(sep, bytes_per_sep) is many times slower than manually
inserting the separators
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue40313>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40470] Make inspect.signature able to parse format strings.
New submission from Antony Lee :
It would be nice if inspect.signature was able to understand bound str.format
methods, e.g. `inspect.signature("{a} {b}".format) == inspect.signature(lambda
*args, a, b, **kwargs: None)` (`*args, **kwargs` are there because str.format
ignores additional arguments). Right now I believe the only way to parse
format strings is string.Formatter, which is slightly less discoverable and
harder to use (although it certainly also provides more info, e.g.
inspect.signature wouldn't be able to tell about format specifiers, but that's
fine).
--
messages: 367852
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Make inspect.signature able to parse format strings.
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40470>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40624] add support for != (not-equals) in ElementTree XPath
New submission from Antony Lee : It would be a small usability improvement if ElementTree's XPath support also supported the != (not-equals) operator. I am specifically mentioning only != and not >/ <https://bugs.python.org/issue40624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40625] Autogenerate signature for METH_NOARGS and perhaps METH_O extension functions
New submission from Antony Lee : It would be nice if METH_NOARGS extension methods had an autogenerated signature (or rather, autogenerated __text_signature__ that gets picked up by inspect.signature). After all, the signature is trivially known at compile time. The same *could* possibly be done for METH_O methods, for which the effective signature is known too. The *name* of the sole parameter is not known, but given that the parameter is (I believe?) positional only, that name "shouldn't" really matter (in the sense, e.g., that whether `signature.bind()` succeeds or not doesn't depend on the parameter name). -- components: C API messages: 368830 nosy: Antony.Lee priority: normal severity: normal status: open title: Autogenerate signature for METH_NOARGS and perhaps METH_O extension functions versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38045] enum.Flag instance creation is slow
Antony Lee added the comment: Now fixed, I believe. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42451] Indicate in the docs that PyTuple_GetItem does not support negative indices
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue42451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42520] add_dll_directory only accepts absolute paths
New submission from Antony Lee : os.add_dll_directory appears to only accept absolute paths, inheriting this restriction from AddDllDirectory. That's absolutely fine, but could perhaps be mentioned in the docs (https://docs.python.org/3/library/os.html#os.add_dll_directory), especially considering that the docs do mention the parallel with `sys.path`, which *does* support relative paths. -- assignee: docs@python components: Documentation messages: 382228 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: add_dll_directory only accepts absolute paths versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does
Antony Lee added the comment: Thanks! -- ___ Python tracker <https://bugs.python.org/issue34750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue34750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name
Antony Lee added the comment: Thanks for implementing! -- ___ Python tracker <https://bugs.python.org/issue42385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue42385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42684] Improvements to documentation for PyUnicode_FS{Converter, Decoder}
New submission from Antony Lee :
The docs for PyUnicode_FSConverter and PyUnicode_FSDecoder could be improved on
two points:
- The functions also reject str/bytes that contain null bytes (one can easily
verify that there's a specific check for them in the C implementations).
Currently the docs only say that the converters use
PyUnicode_EncodeFSDefault/PyUnicode_DecodeFSDefaultAndSize, but those don't
check for null bytes.
- The functions only ever return 1 or 0 (indicating success or failures), which
means that one can just use e.g. `if (!PyUnicode_FSConverter(foo, &bar)) { goto
error; } ...` (this pattern occurs repeatedly in the CPython codebase). In
theory, given that the functions are only documented as being "O&"-converters,
they could also be returning Py_CLEANUP_SUPPORTED in which case they'd need to
be called a second time on failure to release allocated memory.
--
assignee: docs@python
components: C API, Documentation
messages: 383378
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Improvements to documentation for PyUnicode_FS{Converter,Decoder}
___
Python tracker
<https://bugs.python.org/issue42684>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42976] __text_signature__ parser silently drops arguments with certain unsupported default forms
New submission from Antony Lee : Starting from the keyword-arguments example at https://docs.python.org/3/extending/extending.html#keyword-parameters-for-extension-functions, change the docstring of `parrot` to "parrot(voltage, state, action, type=1<<5)\n--\n\n" (yes, the documented default value for type does not correspond to the actual implementation, but that's irrelevant here). Compiling the extension module and running pydoc on it yields the following parsed signature for `parrot`: `parrot(voltage, state, action)` i.e. the `type` parameter got silently dropped. (Note that `1<<5` can legitimately occur, e.g. as a bitmask flag, especially given that one currently cannot refer to globals in __text_signature__ (https://bugs.python.org/issue37881).) -- components: Extension Modules messages: 385335 nosy: Antony.Lee priority: normal severity: normal status: open title: __text_signature__ parser silently drops arguments with certain unsupported default forms ___ Python tracker <https://bugs.python.org/issue42976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43286] Clarify that Popen.returncode does not get auto-set when the process terminates
New submission from Antony Lee :
Currently, the documentation for Popen.returncode states
The child return code, set by poll() and wait() (and indirectly by
communicate()). A None value indicates that the process hasn’t terminated yet.
A negative value -N indicates that the child was terminated by signal N
(POSIX only).
As far back as https://bugs.python.org/issue1727024 it had been suggested that
this fails to emphasize an important piece of information, namely that this
attribute can be outdated (it is *only* set if poll() or wait() are called;
this is not obvious, e.g. returncode could have beeen implemented as a property
that auto-calls poll()). I do realize that a strict reading of the docs does
suggest the actual behavior, but a bit of explicitness won't hurt...
The wording suggested in https://bugs.python.org/issue1727024 seems clearer to
me ("Note: The value stored in returncode may be out-of-date. Use poll() to
reliably find the current return code.").
--
assignee: docs@python
components: Documentation
messages: 387463
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Clarify that Popen.returncode does not get auto-set when the process
terminates
versions: Python 3.10
___
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
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue31254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39783] Optimize construction of Path from other Paths by just returning the same object?
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue39783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does
Antony Lee added the comment:
To be honest, I don't really remember what exact use case I had in my mind 2
years ago (as I probably worked around it in one way or another). However, one
example that I can think of (and that I have actually implemented before) is
auto-conversion of C #defines from a C header file to a Python-level enum (e.g.
for semi-automatic generation of a ctypes wrapper):
# A general header parser (untested, just an example)
def parse_defines(header_file):
d = {}
for line in header_file:
if line.startswith("#define"):
_, k, v = line.split()
d[k] = int(v)
return d
# Now wrapping a specific C library
foo_defines = parse_defines("foo.h")
class Foo(Enum):
locals().update({k: v for k, v in foo_defines.items() if
k.startswith("FOO_")})
def some_method(self):
...
# e.g. call a C function that takes a FOO_* as parameter.
Obviously I could always just replace the method by a free function, but that's
true for (nearly) all methods. In other words, it seems a bit "unfair" that it
is easy to define methods on enums where all options are explicitly listed, but
very hard(?) to do so on enums with programatically defined options.
--
___
Python tracker
<https://bugs.python.org/issue34750>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24970] Make distutils.Command an ABC
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue24970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27320] ./setup.py --help-commands should sort extra commands
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue27320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40624] add support for != (not-equals) in ElementTree XPath
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue40624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42385] Should enum.auto's behavior be adjusted for StrEnum to return the enum name?
New submission from Antony Lee : Currently, enum.auto doesn't work with the new (Py3.10) StrEnum: `class E(enum.StrEnum): a = enum.auto()` results in `TypeError: 1 is not a string`. I would guess that the most reasonable behavior for auto() in a StrEnum would be to return the name itself, as implemented in the AutoName example at https://docs.python.org/3.10/library/enum.html#using-automatic-values. I believe that this may just be a matter of copying the corresponding `_generate_next_value_` implementation into the definition of StrEnum? -- components: Library (Lib) messages: 381220 nosy: Antony.Lee priority: normal severity: normal status: open title: Should enum.auto's behavior be adjusted for StrEnum to return the enum name? versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42451] Indicate in the docs that PyTuple_GetItem does not support negative indices
New submission from Antony Lee :
Unlike `PySequence_GetItem`, `PyTuple_GetItem` does not support negative
indices ("indexing from the end"). That is fine, but warrants a notice in the
docs (as that behavior is certainly not obvious).
The same wording as for `PyList_GetItem` (changing "list" to "tuple") should be
good enough (`PyList_GetItem` currently states: "The position must be
non-negative; indexing from the end of the list is not supported. If index is
out of bounds (<0 or >=len(list)), return NULL and set an IndexError
exception.")
--
assignee: docs@python
components: C API, Documentation
messages: 381716
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Indicate in the docs that PyTuple_GetItem does not support negative
indices
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42451>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37109] Inacurrate documentation regarding return type of math.factorial
New submission from Antony Lee : https://docs.python.org/3/library/math.html says The following functions are provided by this module. Except when explicitly noted otherwise, all return values are floats. and math.factorial(x) Return x factorial. Raises ValueError if x is not integral or is negative. but math.factorial returns an int (which is perfectly reasonable and just needs to be documented): In [3]: math.factorial(5) Out[3]: 120 -- assignee: docs@python components: Documentation messages: 344039 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: Inacurrate documentation regarding return type of math.factorial versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37109] Inacurrate documentation regarding return type of math.factorial
Antony Lee added the comment: oops, missed that, thanks for pointing that out. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37109] Inacurrate documentation regarding return type of math.factorial
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue37109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31006] typing.NamedTuple should add annotations to its constructor (__new__) parameters.
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue31006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37743] How should contextmanager/ContextDecorator work with generators?
New submission from Antony Lee :
The docs for ContextDecorator (of which contextmanager is a case) describe its
semantics as:
... for any construct of the following form:
def f():
with cm():
# Do stuff
ContextDecorator lets you instead write:
@cm()
def f():
# Do stuff
However, when decorating a generator, the equivalence is broken:
from contextlib import contextmanager
@contextmanager
def cm():
print("start")
yield
print("stop")
def gen_using_with():
with cm():
yield from map(print, range(2))
@cm()
def gen_using_decorator():
yield from map(print, range(2))
print("using with")
list(gen_using_with())
print("==")
print("using decorator")
list(gen_using_decorator())
results in
using with
start
0
1
stop
==
using decorator
start
stop
0
1
i.e., when used as a decorator, the entire contextmanager is executed first
before iterating over the generator (which is unsurprising given the
implementation of ContextDecorator: ContextDecorator returns a function that
executes the context manager and returns the generator, which is only iterated
over later).
Should this be considered as a bug in ContextDecorator, and should
ContextDecorator instead detect when it is used to decorate a generator (e.g.
with inspect.isgeneratorfunction), and switch its implementation accordingly in
that case?
--
components: Library (Lib)
messages: 348878
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: How should contextmanager/ContextDecorator work with generators?
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue37743>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.
New submission from Antony Lee: Python 3.6.1, virtualenv 15.1.0 (Arch Linux, distro packages) ``` export PIP_CONFIG_FILE=/dev/null # just to be sure # python -mvirtualenv outer-env # using /usr/bin/python(3) python2 -mvirtualenv outer-env # using /usr/bin/python(3) source outer-env/bin/activate python -mvenv inner-env # using outer-env's python source inner-env/bin/activate python -minspect -d pip ``` The last step outputs ``` Target: pip Origin: /tmp/inner-env/lib/python3.6/site-packages/pip/__init__.py Cached: /tmp/inner-env/lib/python3.6/site-packages/pip/__pycache__/__init__.cpython-36.pyc Loader: <_frozen_importlib_external.SourceFileLoader object at 0x7f27c019c710> Submodule search path: ['/tmp/inner-env/lib/python3.6/site-packages/pip'] ``` i.e., the outer environment's pip leaks into the inner environment; the inner environment does not have its own pip installed. Trying to use that pip from the inner environment (from inner-env, `python -mpip install ...`) results in the package being installed in the outer environment rather than the inner one. Now this may all seem very academic, but for example Travis uses virtualenvs as toplevel containers for their Python projects, so this bug makes it difficult to test, say, projects that set up venvs as part of their workflow. -- components: Library (Lib) messages: 297365 nosy: Antony.Lee priority: normal severity: normal status: open title: A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own. versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.
Antony Lee added the comment: Sorry, that was a sloppy report. This is a better repro: $ export PIP_CONFIG_FILE=/dev/null # just to be sure python -mvirtualenv outer-env # using /usr/bin/python(3) source outer-env/bin/activate python -mvenv inner-env # using outer-env's python source inner-env/bin/activate python -minspect -d pip Using base prefix '/usr' New python executable in /tmp/outer-env/bin/python Installing setuptools, pip, wheel...done. Target: pip Origin: /tmp/outer-env/lib/python3.6/site-packages/pip/__init__.py Cached: /tmp/outer-env/lib/python3.6/site-packages/pip/__pycache__/__init__.cpython-36.pyc Loader: <_frozen_importlib_external.SourceFileLoader object at 0x7f92e00e03c8> Submodule search path: ['/tmp/outer-env/lib/python3.6/site-packages/pip'] -- ___ Python tracker <http://bugs.python.org/issue30811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes
Changes by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <http://bugs.python.org/issue19896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31006] typing.NamedTuple should add annotations to its constructor (__new__) parameters.
New submission from Antony Lee: Currently, the fields, types and defaults used to define a typing.NamedTuple need to be retrieved from three different attributes: `_fields`, `_field_types`, and `_field_defaults` (the first two are combined in `__annotations__`, but that still misses the defaults). However, there is a place where all this information can be naturally combined: in the Signature of the constructor (as returned by `inspect.signature(cls)`). Currently, the Parameter objects in the signature have the information about the parameter names and defaults, but their annotation is not set. Thus, I would like to propose setting the annotation of the Parameters in the Signature object as well. -- components: Library (Lib) messages: 298937 nosy: Antony.Lee priority: normal severity: normal status: open title: typing.NamedTuple should add annotations to its constructor (__new__) parameters. versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue31006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument
Antony Lee added the comment: For cross-referencing purposes: I have proposed in http://bugs.python.org/issue25293 to allow passing a Thread/Process subclass as argument instead of an initializer function, which would both handle Mark Dickinson's comment (http://bugs.python.org/issue21423#msg218040) about passing the thread object as argument, and also allow for finalization. -- nosy: +Antony.Lee ___ Python tracker <http://bugs.python.org/issue21423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31006] typing.NamedTuple should add annotations to its constructor (__new__) parameters.
Antony Lee added the comment: I'll just repost the issue there for now (https://github.com/python/typing/issues/454). May work on a patch at some point (looks relatively simple) but no guarantees, so if someone else wants to take over feel free to do so. -- ___ Python tracker <http://bugs.python.org/issue31006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
New submission from Antony Lee:
The following example, which raises a KeyError, shows that in a
WeakKeyDictionary subclass that defines __missing__, that method doesn't get
called.
from weakref import WeakKeyDictionary
class WeakKeyDictionaryWithMissing(WeakKeyDictionary):
__missing__ = lambda: print("hello")
class C: pass
d = WeakKeyDictionaryWithMissing()
d[C()]
This behavior is technically OK, as object.__missing__ is only documented in
the datamodel to be called for dict subclasses, and WeakKeyDictionary is
actually not a subclass of dict, but of MutableMapping.
Still, it would seem preferable if either WeakKeyDictionary did use
__missing__, or perhaps, more reasonably, Mapping.__getitem__ did so. (Or, at
least, if the WeakKeyDictionary class clearly stated that it does not inherit
from dict. Note that the docs start with "Mapping class that references keys
weakly. Entries in the *dictionary* etc." (emphasis mine))
--
components: Library (Lib)
messages: 300671
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: WeakKeyDictionary/Mapping doesn't call __missing__
versions: Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue31254>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
Antony Lee added the comment: The use case is to generate a mapping of weakly-held objects to unique ids, with something like id_map = WeakKeyDictionaryWithMissing(lambda *, _counter=itertools.count(): next(_counter)) Of course, as always when using defaultdict, it is easy enough to instead implement this by manually checking if the key is present and store a new id in this case -- but this is as well an argument for not having defaultdict in the first place. -- ___ Python tracker <http://bugs.python.org/issue31254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
Antony Lee added the comment: The original example did not cover the use case and was only there to show the current behavior. The real use case is more something like obj = (get obj as argument to function, caller has a hard reference to it) uid = d[obj] -- ___ Python tracker <http://bugs.python.org/issue31254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
Antony Lee added the comment: For my use case, it was easy enough to wrap the `uid = d[obj]` in a try... catch... plus locking. Using setdefault would cause the counter to be incremented every time. In truth, here I did not care about having consecutive uids, so that would have worked just as well. In real truth, it later turned out that I didn't really need numeric uids anyways; I could just use weakrefs to the object themselves instead. -- ___ Python tracker <http://bugs.python.org/issue31254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31254] WeakKeyDictionary/Mapping doesn't call __missing__
Antony Lee added the comment: Thanks for the clarification! "at least if the original key is not `obj` but some other object equal to `obj`" does not apply in my case so I'm fine, but the example shows that this is tricky to get right... -- ___ Python tracker <http://bugs.python.org/issue31254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31295] typo in __hash__ docs
New submission from Antony Lee: In https://docs.python.org/3.7/reference/datamodel.html#object.__hash__ I think x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y). should be x.__hash__() returns an appropriate value such that x == y and x is y both imply that hash(x) == hash(y). right? -- assignee: docs@python components: Documentation messages: 300961 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: typo in __hash__ docs versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31330] argparse.RawTextHelpFormatter does not maintain lines separated by more than one newline
New submission from Antony Lee: The doc for argparse.RawTextHelpFormatter states that it "maintains whitespace for all sorts of help text, including argument descriptions." But the following example (which outputs "Foo", "Bar", and "Baz", each separated by exactly one empty line) shows that paragraphs separated by more than one empty line will only be separated in the output text by a single empty line. import argparse parser = argparse.ArgumentParser( prog='PROG', formatter_class=argparse.RawTextHelpFormatter, description='''\ Foo Bar Baz''') parser.print_help() -- components: Library (Lib) messages: 301158 nosy: Antony.Lee priority: normal severity: normal status: open title: argparse.RawTextHelpFormatter does not maintain lines separated by more than one newline versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue31330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31542] pth files in site-packages of venvs are executed twice
New submission from Antony Lee: All's in the title: "pth files in site-packages of venvs are executed twice". For example, the following code sample prints "1" twice. python -mvenv /tmp/tmpenv echo 'import os; print(1)' >/tmp/tmpenv/lib/python3.6/site-packages/foo.pth source activate /tmp/tmpenv python This behavior is different from the one for a pth file in a non-venv site-packages (either the syswide prefix, or the user prefix), which is only executed once. -- components: Library (Lib) messages: 302678 nosy: Antony.Lee priority: normal severity: normal status: open title: pth files in site-packages of venvs are executed twice versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue31542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35874] Clarify that the (...) convertor to PyArg_ParseTuple... accepts any sequence.
New submission from Antony Lee : The documentation for the accepted types for each format unit in PyArg_ParseTuple (and its variants) is usually quite detailed; compare for example y* (bytes-like object) [Py_buffer] This variant on s* doesn’t accept Unicode objects, only bytes-like objects. This is the recommended way to accept binary data. and S (bytes) [PyBytesObject *] Requires that the Python object is a bytes object, without attempting any conversion. Raises TypeError if the object is not a bytes object. The C variable may also be declared as PyObject*. There, the type in parenthesis (which is explained as "the entry in (round) parentheses is the Python object type that matches the format unit") differentiates between "bytes-like object" and "bytes". However, the documentation for "(...)" is a bit more confusing: (items) (tuple) [matching-items] The object must be a Python sequence whose length is the number of format units in items. The C arguments must correspond to the individual format units in items. Format units for sequences may be nested. The type in parenthesis is "tuple" (exactly), but the paragraph says "sequence". The actual behavior appears indeed to be that any sequence (e.g., list, numpy array) is accepted, so I'd suggest changing the type in the parenthesis to "sequence". -- assignee: docs@python components: Documentation messages: 334660 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: Clarify that the (...) convertor to PyArg_ParseTuple... accepts any sequence. ___ Python tracker <https://bugs.python.org/issue35874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36277] pdb's recursive debug command is not listed in the docs
New submission from Antony Lee : pdb's recursive debug command (mentioned e.g. in https://bugs.python.org/issue35931) is not listed in https://docs.python.org/3/library/pdb.html#debugger-commands. (I haven't checked whether any other command is missing.) -- assignee: docs@python components: Documentation messages: 337828 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: pdb's recursive debug command is not listed in the docs ___ Python tracker <https://bugs.python.org/issue36277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36277] pdb's recursive debug command is not listed in the docs
Antony Lee added the comment: I'll pass on that for now. -- ___ Python tracker <https://bugs.python.org/issue36277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35232] Add `module`/`qualname` arguments to make_dataclass for picklability
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue35232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36277] pdb's recursive debug command is not listed in the docs
Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker <https://bugs.python.org/issue36277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
