[issue46771] Add some form of cancel scopes
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45670] New .mapping attribute is broken for some existing uses of dict views
Joshua Bronson added the comment:
Thank you for confirming that ChainMap.__iter__() would be in the same boat as
bidict if a similar .mapping attribute were ever added to dict_keyiterators.
The specifics of this issue are interesting, but even more interesting to me is
whatever learnings we can generalize from this.
After testing that the performance impact would be significant, I created the
feature request you suggested in https://bugs.python.org/issue46713. Thanks for
suggesting that.
In the meantime, I've updated the relevant docstrings:
>>> help(b.keys)
keys() -> KeysView[~KT] method of bidict.bidict instance
A set-like object providing a view on the contained keys.
When *b._fwdm* is a :class:`dict`, *b.keys()* returns a
*dict_keys* object that behaves exactly the same as
*collections.abc.KeysView(b)*, except for
- offering better performance
- being reversible on Python 3.8+
- having a .mapping attribute in Python 3.10+
that exposes a mappingproxy to *b._fwdm*.
>>> help(b.values)
values() -> bidict.BidictKeysView[~VT] method of bidict.bidict instance
A set-like object providing a view on the contained values.
Since the values of a bidict are equivalent to the keys of its inverse,
this method returns a set-like object for this bidict's values
rather than just a collections.abc.ValuesView.
This object supports set operations like union and difference,
and constant- rather than linear-time containment checks,
and is no more expensive to provide than the less capable
collections.abc.ValuesView would be.
See :meth:`keys` for more information.
etc.
Regarding:
> The values() call unexpectedly returns an instance of dict_keys(). At first,
> I was surprised that this got past the type checker -- you can do set
> operations with KeysView but not with a ValuesView.
Check out https://github.com/jab/bidict/blob/82f931/bidict/_base.py#L38-L45:
```
class BidictKeysView(t.KeysView[KT], t.ValuesView[KT]):
"""Since the keys of a bidict are the values of its inverse (and vice
versa),
the ValuesView result of calling *bi.values()* is also a KeysView of
*bi.inverse*.
"""
dict_keys: t.Type[t.KeysView[t.Any]] = type({}.keys())
BidictKeysView.register(dict_keys)
```
See also https://github.com/python/typeshed/issues/4435 for a request that
typeshed use a Protocol (structural typing) here.
Thanks again for taking the time to look at my code and discuss so generously.
--
___
Python tracker
<https://bugs.python.org/issue45670>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46713] Provide a C implementation of collections.abc.KeysView and friends
New submission from Joshua Bronson :
As suggested by @rhettinger in https://bugs.python.org/msg409443, I'm creating
a feature request for C implementations of collections.abc.KeysView,
ValuesView, and ItemsView.
Because these do not currently benefit from C speedups, they're a lot slower
than their dict_keys, dict_values, and dict_items counterparts. As a result,
libraries that implement custom Mapping types that are backed by dicts are
incentivized to override the implementations of keys(), values(), and items()
they inherit from collections.abc.Mapping to instead return their backing
dicts' mapping views, causing a potential abstraction leak.
An example can be found in https://github.com/jab/bidict, which implements
bidirectional mapping types that wrap a forward and an inverse dict which are
kept in sync with one another.
>>> from bidict import *
>>> bi = bidict({1: 'one', 2: 'two'})
>>> bi.items() # Overridden for performance:
dict_items([(1, 'one'), (2, 'two')])
Ditto for OrderedBidict:
>>> OrderedBidict(bi).keys()
_OrderedBidictItemsView(OrderedBidict([(1, 'one'), (2, 'two')]))
(The _OrderedBidictItemsView is a custom view whose __iter__ uses the
implementation inherited by its collections.abc.ItemsView base class so that
the correct order is respected, but proxies other method calls through to the
backing dict's dict_items object:
https://github.com/jab/bidict/blob/2ab42a/bidict/_orderedbidict.py#L90-L150)
Here is a microbenchmark of calling __eq__ on an _OrderedBidictItemsView vs. a
collections.abc.ItemsView, to estimate the performance impact (using Python
3.10):
❯ set setup '
from collections.abc import ItemsView
from bidict import OrderedBidict
d = dict(zip(range(), range()))
ob = OrderedBidict(d)'
❯ python -m pyperf timeit -s $setup 'ob.items() == d.items()' -o 1.json
❯ python -m pyperf timeit -s $setup 'ItemsView(ob) == d.items()' -o 2.json
❯ pyperf compare_to 2.json 1.json
Mean +- std dev: [2] 4.21 ms +- 1.10 ms -> [1] 168 us +- 6 us: 25.13x faster
This demonstrates a potentially significant speedup. Similar microbenchmarks
for ItemsView vs. dict_items, as well as KeysView vs. both dict_keys and
_OrderedBidictKeysView, also indicate similarly significant potential.
Note that the performance benefits of this may propagate to other code as well.
For example, bidicts' __eq__ methods are implemented in terms of their
itemsviews (see
https://github.com/jab/bidict/blob/2ab42a/bidict/_base.py#L285-L286), so
speeding up bidict.items().__eq__ speeds up bidict.__eq__ commensurately.
--
messages: 413020
nosy: jab
priority: normal
severity: normal
status: open
title: Provide a C implementation of collections.abc.KeysView and friends
___
Python tracker
<https://bugs.python.org/issue46713>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46684] Expose frozenset._hash classmethod
Joshua Bronson added the comment: Thanks for the explanation, Raymond. Regarding: > Lastly, pure python hashable sets based on the ABC are not common This would have implications for other use cases though, that are perhaps more common. See, for example, the following code: https://github.com/jab/bidict/blob/ae9d06/bidict/_frozenbidict.py#L36-L38 This example demonstrates an implementation of a hashable, immutable Mapping type, whose __hash__ implementation returns collections.abc.ItemsView(self)._hash(). Since there are several other libraries I know of that implement hashable/immutable mapping types as well, I thought this might be beneficial enough to users to warrant consideration. -- ___ Python tracker <https://bugs.python.org/issue46684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46684] Expose frozenset._hash classmethod
New submission from Joshua Bronson : collections.abc.Set provides a _hash() method that includes the following in its docstring: """ Note that we don't define __hash__: not all sets are hashable. But if you define a hashable set type, its __hash__ should call this function. ... We match the algorithm used by the built-in frozenset type. """ Because Set._hash() is currently implemented in pure Python, users face having to make a potentially challenging decision between whether to trade off runtime efficiency vs. space efficiency: >>> hash(frozenset(x)) # Should I use this? >>> Set._hash(x)# Or this? The former requires O(n) memory to create the frozenset, merely to throw it immediately away, but on the other hand gets to use frozenset's __hash__ implementation, which is implemented in C. The latter requires only O(1) memory, but does not get the performance benefit of using the C implementation of this algorithm. Why not expose the C implementation via a frozenset._hash() classmethod, and change Set._hash() to merely call that? Then it would be much clearer that using Set._hash() is always the right answer. -- messages: 412856 nosy: jab priority: normal severity: normal status: open title: Expose frozenset._hash classmethod ___ Python tracker <https://bugs.python.org/issue46684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45670] New .mapping attribute is broken for some existing uses of dict views
Joshua Bronson added the comment:
Dear Raymond,
Thanks so much for the detailed response!
I wonder if you could explain how this case is different from the following:
>>> c = collections.ChainMap({1: 1}, {1: 2})
>>> iter(c)
>>> isinstance(c, dict) # it's fine, we <3 duck typing!
False
Now suppose a new .mapping attribute were added to dict_keyiterator objects in
a future version of Python, like the one that was added to dict view objects in
Python 3.10. Then, wouldn't ChainMap find itself in a similar predicament as
this issue is raising?
>>> iter(c).mapping
mappingproxy({1: None})
As in my example above, the {1: None} mapping here is an implementation detail
of ChainMap.__iter__() that was never intended to be leaked to users. (Ref:
<https://github.com/python/cpython/blob/e18d815/Lib/collections/__init__.py#L998-L1002>)
Note also that ChainMap.__iter__() returns a dict_keyiterator object even
though issubclass(ChainMap, dict) is False. We consider this just fine though,
because the dict_keyiterator object currently behaves exactly like the
generator object we would get if the code had done a `yield from d` rather than
a `return iter(d)`. Except for being faster.
This parallels the implementations of bidict.keys()/values()/items(), which
currently return dict_keys/dict_values/dict_items objects generated from
internal data, that behave exactly like KeysViews(b)/ValuesView(b)/ItemsView(b)
would*, except for being faster. And, as this issue is raising, except for this
new .mapping attribute in Python 3.10+ now leaking internal state.
* I even have the passing property-based tests to prove it:
<https://github.com/jab/bidict/pull/217/files#diff-995af13b14fe897c5d200fa97ed88fad03e401b2fc0cc167624d482ea512ba96R431-R459>
:)
(I also have counterpoints for your other feedback, but wanted to post this
part first. And sorry for my delay in responding – hope it's not too late! And
finally thanks so much again for considering this and for the time you took to
give feedback on bidict – there's literally no better-qualified person in the
world. I so appreciate it!)
--
___
Python tracker
<https://bugs.python.org/issue45670>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45863] tarfile zeroes ustar header fields unnecessarily
Joshua Root added the comment: PR has been marked stale; friendly ping. -- ___ Python tracker <https://bugs.python.org/issue45863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46144] math.log() returns improper output
Joshua Insel added the comment: The same problem occurs with the log function from the C standard library, which Python uses to implement its same-named function. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46144] math.log() returns improper output
New submission from Joshua Insel : math.log(536870912, 2) should return 29.0, because 2^29 = 536870912. However, it instead returns 29.004. -- messages: 408986 nosy: joshinsel priority: normal severity: normal status: open title: math.log() returns improper output type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45959] Teach pprint about dict views
Joshua Insel added the comment: According to the documentation for pprint, it is supposed to print objects on a single line if possible. See the second paragraph here: https://docs.python.org/3/library/pprint.html -- nosy: +joshinsel ___ Python tracker <https://bugs.python.org/issue45959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45863] tarfile zeroes ustar header fields unnecessarily
Change by Joshua Root : -- keywords: +patch pull_requests: +27931 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29693 ___ Python tracker <https://bugs.python.org/issue45863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45863] tarfile zeroes ustar header fields unnecessarily
New submission from Joshua Root : When using the pax format, tarfile will zero out the field in the ustar header for any values that are represented with a float, setting the correct value only in the pax header. This mainly seems to apply to the mtime. This behaviour doesn't cause problems when using an unarchiver that understands the pax header, but unarchivers that don't will extract incorrect metadata (most obviously all mtimes set to the epoch). Compatibility with such unarchivers can easily be achieved by rounding the float value to int for the ustar header only, thus at least giving mtimes that are accurate to the nearest second instead of nothing. -- components: Library (Lib) messages: 406744 nosy: jmr priority: normal severity: normal status: open title: tarfile zeroes ustar header fields unnecessarily type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40051] Give proper link in help(idlelib/turtledemo/tkinter.sub/test_*/?)
Joshua added the comment: I think that option 4 would work best but instead of putting any logic in (Lib/pydoc_data/topics.py)[https://github.com/python/cpython/blob/main/Lib/pydoc_data/topics.py] we could put the logic for working with private modules as well and other edge cases in (Lib/pydoc.py)[https://github.com/python/cpython/blob/main/Lib/pydoc.py]. It might make future changes easier. -- nosy: +Joshuah143 ___ Python tracker <https://bugs.python.org/issue40051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45717] Bad link to python docs in help(_hashlib)
New submission from Joshua : I was attempting to look through hashlib to try and understand more about python's built-in hash functions. As part of this, I ran 'help(_hashlib)' which returns this text: 'MODULE REFERENCE https://docs.python.org/3.11/library/_hashlib.html' This is an invalid link which has been an issue in all versions of the documentation I looked up. As an aside, where would I find the source for _hashlib? -- components: Library (Lib) messages: 405744 nosy: Joshuah143 priority: normal severity: normal status: open title: Bad link to python docs in help(_hashlib) type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45670] New .mapping attribute is broken for some existing uses of dict views
New submission from Joshua Bronson :
As of bpo-40890 (released in Python 3.10), dict views now provide a public
.mapping attribute, intended to allow users to recover a mappingproxy pointing
to the original mapping.
However, this new attribute can actually point to the wrong mapping for some
existing uses of dict views. And since the .mapping attribute is read-only,
these existing uses have no way to set it to the correct value.
My bidict library (see https://github.com/jab/bidict) provides an example of
this.
A bidict implements a bidirectional mapping by building on top of two dicts
(i.e. regular old one-directional mappings) internally -- one for the forward
direction, and one for the inverse. When you call e.g. keys() or values() on a
bidict, you get back a dict_keys view from one of the backing dicts, because
this is a much more optimized implementation of these views than
collections.abc.KeysView would be:
>>> import bidict
>>> b = bidict.bidict(one=1, two=2)
>>> b
bidict({'one': 1, 'two': 2})
>>> b.keys()
dict_keys(['one', 'two'])
>>> b.values()
dict_keys([1, 2])
However, now that these built-in dict_keys objects provide a .mapping attribute
in Python 3.10, it points to one of the internal, backing dicts in this case,
which is an implementation detail, rather than to the bidict instance:
>>> b.keys().mapping # wrong
mappingproxy({'one': 1, 'two': 2})
>>> b.values().mapping # wrong
mappingproxy({1: 'one', 2: 'two'})
Instead of the above, you should get:
>>> b.keys().mapping # corrected:
mappingproxy(bidict({'one': 1, 'two': 2}))
>>> b.values().mapping # corrected:
mappingproxy(bidict({'one': 1, 'two': 2}))
Since the .mapping attribute is read-only, there's no way for bidict to both
keep exposing the optimized dict_keys implementations, which up till now have
been perfectly correct, while now exposing a correct .mapping attribute for
users of Python 3.10+.
(Other bidict types demonstrate this problem more by exposing even more
obviously-unintended implementation details via this new .mapping attribute:
>>> f = bidict.FrozenOrderedBidict(b)
>>> f
FrozenOrderedBidict([('one', 1), ('two', 2)])
>>> f.keys().mapping # ouch
mappingproxy({'one': _Node(prv=..., self=..., nxt=...), 'two': _Node(prv=...,
self=..., nxt=...)})
Those internal _Node objects were never meant to be exposed to consumers,
they're an implementation detail.)
It looks like cases like this were not considered when discussing bpo-40890,
and if they had been, I wonder if the implementation would have been accepted
as-is.
Here are some potential directions for how to improve things for the future:
1. Expose a way for dict view users like bidict to continue to use optimized
dict view implementations while opting out of the new .mapping attribute
2. Make the .mapping attribute no longer read-only, so libraries like bidict
can set it correctly before exposing it to users
3. Merely update the documentation in
https://docs.python.org/3/library/stdtypes.html#:~:text=dictview.mapping,in%20version%203.10.
to mention that, because the .mapping attribute is read-only, it may not point
to the original, intended mapping, but rather some internal mapping that the
user was not intended to be exposed to.
Looking forward to hearing your thoughts, and thanks for your consideration.
--
components: Interpreter Core
messages: 405317
nosy: jab, rhettinger
priority: normal
severity: normal
status: open
title: New .mapping attribute is broken for some existing uses of dict views
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue45670>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40890] Dict views should be introspectable
Change by Joshua Bronson : -- nosy: +jab nosy_count: 6.0 -> 7.0 pull_requests: +27187 pull_request: https://github.com/python/cpython/pull/28892 ___ Python tracker <https://bugs.python.org/issue40890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45394] pip install numpy not working in 3.11.0a on macOS 11.6
New submission from Joshua :
pip3.11 install numpy failed on a fresh install of python 3.11.0a on macOS 11.6.
pip3.11 install numpy
Collecting numpy
Downloading numpy-1.21.1.zip (10.3 MB)
|| 10.3 MB 14.1 MB/s
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing wheel metadata ... done
Building wheels for collected packages: numpy
Building wheel for numpy (PEP 517) ... error
ERROR: Command errored out with exit status 1:
command: /Library/Frameworks/Python.framework/Versions/3.11/bin/python3.11
/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/pip/_vendor/pep517/in_process/_in_process.py
build_wheel /var/folders/js/z0nzng056v5b32z5_jfxwj_rgn/T/tmpiixoj1ei
cwd:
/private/var/folders/js/z0nzng056v5b32z5_jfxwj_rgn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e
Complete output (936 lines):
setup.py:63: RuntimeWarning: NumPy 1.21.1 may not yet support Python 3.11.
warnings.warn(
Running from numpy source directory.
/private/var/folders/js/z0nzng056v5b32z5_jfxwj_rgn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/tools/cythonize.py:69:
DeprecationWarning: The distutils package is deprecated and slated for removal
in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils.version import LooseVersion
Processing numpy/random/_bounded_integers.pxd.in
Processing numpy/random/_philox.pyx
Processing numpy/random/_bounded_integers.pyx.in
Processing numpy/random/_sfc64.pyx
Processing numpy/random/_mt19937.pyx
Processing numpy/random/bit_generator.pyx
Processing numpy/random/mtrand.pyx
Processing numpy/random/_generator.pyx
Processing numpy/random/_pcg64.pyx
Processing numpy/random/_common.pyx
Cythonizing sources
blas_opt_info:
blas_mkl_info:
customize UnixCCompiler
libraries mkl_rt not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
blis_info:
libraries blis not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
openblas_info:
libraries openblas not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
accelerate_info:
libraries accelerate not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
Library accelerate was not found. Ignoring
libraries veclib not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
Library veclib was not found. Ignoring
FOUND:
extra_compile_args = ['-msse3',
'-I/System/Library/Frameworks/vecLib.framework/Headers']
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3), ('HAVE_CBLAS', None)]
FOUND:
extra_compile_args = ['-msse3',
'-I/System/Library/Frameworks/vecLib.framework/Headers']
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3), ('HAVE_CBLAS', None)]
non-existing path in 'numpy/distutils': 'site.cfg'
lapack_opt_info:
lapack_mkl_info:
libraries mkl_rt not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
openblas_lapack_info:
libraries openblas not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
openblas_clapack_info:
libraries openblas,lapack not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
flame_info:
libraries flame not found in
['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib',
'/usr/lib']
NOT AVAILABLE
FOUND:
extra_compile_args = ['-msse3',
'-I/System/Library/Frameworks/vecLib.framework/Headers']
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3), ('HAVE_CBLAS', None)]
Warning: attempted relative import with no known parent package
/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/distutils/dist.py:274:
UserWarning: Unknown distribution option: 'define_macros'
warnings.warn(msg)
running bdist_wheel
running build
running
[issue45142] Import error for Iterable in collections
Joshua added the comment: Update: I'm just dumb, should have used "from collections.abc import Iterable" -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45142] Import error for Iterable in collections
New submission from Joshua : Traceback: Traceback (most recent call last): File "/Users/user/PycharmProjects/phys2/main.py", line 5, in from collections import Iterable ImportError: cannot import name 'Iterable' from 'collections' (/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/collections/__init__.py) Done using a venv based on python 3.10.0rc1 running on Darwin/MacOS. I am new to adding bugs so I don't quite know what information I can provide that could be of use other than that this issue persists in REPL. -- components: Library (Lib) messages: 401425 nosy: Joshuah143 priority: normal severity: normal status: open title: Import error for Iterable in collections versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44963] anext_awaitable is not a collections.abc.Generator
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue44963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44853] 3.10.0rc1 published md5 and size do not match for source archives
Change by Joshua Root : -- title: 3.1.10rc1 published md5 and size do not match for source archives -> 3.10.0rc1 published md5 and size do not match for source archives ___ Python tracker <https://bugs.python.org/issue44853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44853] 3.1.10rc1 published md5 and size do not match for source archives
New submission from Joshua Root : The download page lists the following: Filenamemd5 size Python-3.10.0rc1.tgzc051bf7a52a45cb0ec2cefbe915417e1 40764776 Python-3.10.0rc1.tar.xz 2861cdd4cf71c6425fde1fedc14bb283 28197832 The downloaded files instead have these properties: Python-3.10.0rc1.tgzd23c2a8228705b17e8414f1660e4bb73 24955561 Python-3.10.0rc1.tar.xz edd2eb2f7f4a932ed59196cbe373e5fb 18680452 The gpg signatures do verify ok however. The md5 and size listed for the macOS installer seem to be correct. I didn't check the Windows installers. -- components: Installation messages: 399103 nosy: jmr, pablogsal priority: normal severity: normal status: open title: 3.1.10rc1 published md5 and size do not match for source archives type: security versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43468] functools.cached_property incorrectly locks the entire descriptor on class instead of per-instance locking
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue43468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43568] Drop support for Mac OS X < 10.3 module linking
Change by Joshua Root : -- pull_requests: +24654 pull_request: https://github.com/python/cpython/pull/26001 ___ Python tracker <https://bugs.python.org/issue43568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43568] Drop support for Mac OS X < 10.3 module linking
Joshua Root added the comment: The part that is a bug is that the whole version was checked, not just the major version--you couldn't target macOS 11.0 if your Python was built for 11.3, for example. MacPorts users getting an error in that situation was the original motivation for coming up with the distutils change. -- ___ Python tracker <https://bugs.python.org/issue43568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43568] Drop support for Mac OS X < 10.3 module linking
Joshua Root added the comment: Thanks Ned. Would it be OK to backport just the distutils change to 3.9? -- ___ Python tracker <https://bugs.python.org/issue43568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43751] await anext() returns None when default is given
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue43751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27815] Make SSL suppress_ragged_eofs default more secure
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue27815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43568] Drop support for Mac OS X < 10.3 module linking
Joshua Root added the comment: Here's the PR for pypa/distutils, which is just relaxing the MDT check since it has to work with older Python versions: https://github.com/pypa/distutils/pull/36 -- ___ Python tracker <https://bugs.python.org/issue43568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43568] Drop support for Mac OS X < 10.3 module linking
Change by Joshua Root : -- keywords: +patch pull_requests: +23702 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24941 ___ Python tracker <https://bugs.python.org/issue43568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43568] Drop support for Mac OS X < 10.3 module linking
New submission from Joshua Root : The `-undefined dynamic_lookup` option can only be used in LDSHARED on Mac OS X 10.3 and later. There is a fallback to explicitly linking with the framework for 10.2 and earlier. I'm pretty sure that currently supported Python versions don't build on 10.2 or older for several other reasons (I happen to know that even building on 10.5 requires a little patching.) So it's probably reasonable to just drop this code path. There is a closely related check in distutils, though you would only know it's related if you looked through the history as I did. It errors out if you try to build a module for an older MACOSX_DEPLOYMENT_TARGET than Python was configured with. The purpose of that is to prevent using the wrong LDSHARED flags for the target platform. If 10.2 support is dropped, that check can be removed entirely. I am aware that distutils is deprecated, going away, etc., and I am submitting a PR to setuptools as well. But setuptools does not yet override the stdlib distutils with its own by default, so bugs in the stdlib copy are still relevant. If it's decided to keep 10.2 support, the check in distutils should still be relaxed to error only if the current MDT is < 10.3 and the configured MDT is >= 10.3. I can easily put together a PR for that if needed. Either way, the approach taken in setuptools will depend on how LDSHARED is handled here. -- components: Build, Distutils, macOS messages: 389157 nosy: dstufft, eric.araujo, jmr, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Drop support for Mac OS X < 10.3 module linking type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43246] Dict copy optimization violates subclass invariant
New submission from Joshua Bronson :
If I understand correctly, it should be an invariant that in the code below,
for all "Parent" classes, for all "method"s, Child1.method should return the
same result as Child2.method:
```
class Parent:
def __init__(self, value):
self._value = value
def method(self):
return self._value
class Child1(Parent):
pass
c1 = Child1(42)
result = c1.method()
assert result == 42, result
class Child2(Parent):
def method(self):
return super().method()
c2 = Child2(42)
result = c2.method()
assert result == 42, result
```
But when "Parent" is "dict" and method is "__iter__", that is not the case:
```
SHOW_BUG = True
class ChildDict1(dict):
"""Simplification of werkzeug.datastructures.MultiDict."""
def __init__(self):
pass
if not SHOW_BUG:
def __iter__(self):
return super().__iter__()
def add(self, key, value):
self.setdefault(key, []).append(value)
def __setitem__(self, key, value):
"""Like add, but removes any existing key first."""
super().__setitem__(key, [value])
def getall(self, key) -> list:
return super().__getitem__(key)
def __getitem__(self, key):
"""Return the first value for this key."""
return self.getall(key)[0]
def items(self, multi=False):
for (key, values) in super().items():
if multi:
yield from ((key, value) for value in values)
else:
yield key, values[0]
def values(self):
return (values[0] for values in super().values())
# Remaining overridden implementations of methods
# inherited from dict are elided for brevity.
cd1 = ChildDict1()
assert dict(cd1) == {}
cd1[1] = "one"
cd1.add(1, "uno")
assert cd1.getall(1) == ["one", "uno"]
assert list(cd1.items()) == [(1, "one")]
assert list(cd1.values()) == [ "one"]
assert dict(cd1) == {1: "one"}, cd1 # XXX
```
If you run the above as-is, the line marked "XXX" will trigger an
AssertionError demonstrating the unexpected behavior. If you change SHOW_BUG to
False, it won’t.
Is it intended that toggling the value of SHOW_BUG in this code causes
different results?
You can visit https://repl.it/@jab/dict-subclass-copy-surprise to run the
examples above directly in your browser.
--
messages: 387191
nosy: jab
priority: normal
severity: normal
status: open
title: Dict copy optimization violates subclass invariant
type: behavior
___
Python tracker
<https://bugs.python.org/issue43246>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14757] INCA: Inline Caching meets Quickening in Python 3.3
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue14757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42692] Build fails on macOS when compiler doesn't define __has_builtin
Change by Joshua Root : -- keywords: +patch pull_requests: +22735 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23873 ___ Python tracker <https://bugs.python.org/issue42692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42692] Build fails on macOS when compiler doesn't define __has_builtin
New submission from Joshua Root : The line in posixmodule.c that checks for __builtin_available is rejected by compilers that don't have __has_builtin. The second check needs to be in a nested #if. -- components: Build, macOS messages: 383437 nosy: jmr, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Build fails on macOS when compiler doesn't define __has_builtin type: compile error versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions
Joshua Bronson added the comment: Please see https://github.com/python/cpython/pull/23847 for the C implementation of aiter and anext added to builtins, as requested. -- title: add aiter() and anext() functions to operator module -> add aiter() and anext() functions ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions to operator module
Change by Joshua Bronson : -- pull_requests: +22708 pull_request: https://github.com/python/cpython/pull/23847 ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41100] Support macOS 11 and Apple Silicon Macs
Joshua Root added the comment: Are there plans to backport PR 22855 to any branches older than 3.9? -- nosy: +jmr ___ Python tracker <https://bugs.python.org/issue41100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41617] __builtin_bswap16 is used without checking it is supported
Joshua Root added the comment: Confirmed fixed in 3.9.1 and 3.10.0a3. Thanks Victor! -- ___ Python tracker <https://bugs.python.org/issue41617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42598] Some configure checks rely on implicit function declaration
Change by Joshua Root : -- keywords: +patch pull_requests: +22558 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23690 ___ Python tracker <https://bugs.python.org/issue42598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42598] Some configure checks rely on implicit function declaration
New submission from Joshua Root : There are several cases in the configure script of exit being used without including stdlib.h, and one case of close being used without including unistd.h. A compiler that does not allow implicit function declaration, such as clang in Xcode 12, will error out due to this, which may cause the affected checks to give incorrect results. -- components: Build messages: 382726 nosy: jmr priority: normal severity: normal status: open title: Some configure checks rely on implicit function declaration type: compile error versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31601] Availability of utimensat, futimens not checked correctly on macOS
Joshua Root added the comment: Looks like this is fixed as of 3.9.1. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions to operator module
Joshua Bronson added the comment: Nice to see there is still interest in this from someone else! Thanks, John. Are any core developers still interested in this? If I can get a new PR together that adds C implementations of `aiter` and `anext` to builtins, would a committer still be interested in reviewing the patch? A week from Friday, I'll have a rare and precious opportunity to spend the day contributing to open source. I have a bunch of different things I could work on, but would work on this if there is still interest. Thanks and hope this finds you all well. -- ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42173] Drop Solaris support
Joshua M. Clulow added the comment: Hi! I'm a member of the illumos core team, and I'm also pretty keen for us to keep Python support! Some of our core OS build and packaging tooling is written in Python, and certainly applications like Synapse (Matrix) and Review Board are important to myself. We currently provide a virtual machine for builds to the Go project that is wired in to their official CI/CD. I expect we can help out with a similar thing here! I know some illumos distributions (OmniOS, OpenIndiana, anything with pkgsrc, etc) are maintaining some patches against the stock Python to fix failing tests, etc. Hopefully we can figure out how to get those things upstreamed and increase our participation there. -- nosy: +jclulow ___ Python tracker <https://bugs.python.org/issue42173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41979] PEG parser doesn't accept extended unpacking in with statement
New submission from Joshua Oreman : On Python 3.9.0 with the new PEG parser, the following statement produces a SyntaxError: with contextlib.nullcontext(range(1, 5)) as (first, *rest, last): print(first, rest, last) On 3.8.x, or 3.9.0 with -X oldparser, it succeeds and prints "1 [2, 3] 4" as expected. As I understand it, the thing after 'as' is an assignment target and should accept anything that can go on the LHS of an equals sign. -- components: Interpreter Core messages: 378305 nosy: Joshua Oreman priority: normal severity: normal status: open title: PEG parser doesn't accept extended unpacking in with statement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41617] __builtin_bswap16 is used without checking it is supported
Joshua Root added the comment: > I'm curious. Can I ask you on which platform do you use clang older than 3.2? Mac OS X 10.7 / Xcode 4.6.3. I'm not using it personally, but we have automated builds on that platform. Unfortunately the patch ultimately committed did not fix the build there. Clang reports its version as "Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)". __clang_major__ is 4 and __clang_minor__ is 2. Apple's versioning scheme is different to that of LLVM upstream, which is one reason why I preferred detecting features directly rather than inserting externally-derived knowledge about which versions provide which features. Apologies for not getting back to you about this sooner; the notifications appear to have gotten lost. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue41617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41617] __builtin_bswap16 is used without checking it is supported
Change by Joshua Root : -- pull_requests: +21053 pull_request: https://github.com/python/cpython/pull/21943 ___ Python tracker <https://bugs.python.org/issue41617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41617] __builtin_bswap16 is used without checking it is supported
Change by Joshua Root : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue41617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41617] __builtin_bswap16 is used without checking it is supported
Change by Joshua Root : -- keywords: +patch pull_requests: +21052 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21942 ___ Python tracker <https://bugs.python.org/issue41617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41617] __builtin_bswap16 is used without checking it is supported
New submission from Joshua Root : Older clang versions don't have __builtin_bswap16, but it's always used when compiling with clang, which means the build fails with those older versions. The code should use __has_builtin to check. -- components: Build messages: 375806 nosy: jmr priority: normal severity: normal status: open title: __builtin_bswap16 is used without checking it is supported type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by Joshua Merchant : -- nosy: +Joshua Merchant ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41530] zoneinfo: ZoneInfo raises IsADirectoryError instead of ZoneInfoNotFoundError
Joshua added the comment:
I'll reopen the PR with an attempted resolution of the OSError related
issues however. In my quick testing it seems at least on Linux
backports.zoneinfo segfaults when trying `ZoneInfo('__init__.py')` so that
might be a larger issue for Paul to look into.
--
___
Python tracker
<https://bugs.python.org/issue41530>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41530] zoneinfo: ZoneInfo raises IsADirectoryError instead of ZoneInfoNotFoundError
Joshua added the comment: I had opened a PR which just caught IsADirectoryError and PermissionError but closed it as you'd mentioned that handling PermissionError that way probably would not be the best, and I agree. I can reopen and modify to check path on OSerror if you'd like otherwise feel free to handle however you see fit. -- ___ Python tracker <https://bugs.python.org/issue41530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41530] Unhandled exceptions in zoneinfo.ZoneInfo constructor
Joshua added the comment:
tzdata was installed as an admin user, however this behaviour was
reproducible on a linux installation where for the ZoneInfo.('Pacific')
instance an IsADirectoryError would instead be raised.
On Wed, Aug 12, 2020 at 9:50 PM STINNER Victor
wrote:
>
> STINNER Victor added the comment:
>
> Hi. It seems like you are running Windows.
>
> About the permission error, how did you install tzdata? Did you install it
> as an admin user and do you run Python as a different user?
>
> --
> nosy: +vstinner
>
> ___
> Python tracker
> <https://bugs.python.org/issue41530>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue41530>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41530] Unhandled exceptions in zoneinfo.ZoneInfo constructor
New submission from Joshua :
Attempting to parse specific keys in zoneinfo.ZoneInfo with tzdata installed
will raise unhandled exceptions
e.g. on windows
>>> import zoneinfo
>>> zoneinfo.ZoneInfo('Pacific')
PermissionError: [Errno 13] Permission denied: 'C:\\Program
Files\\Python39\\lib\\site-packages\\tzdata\\zoneinfo\\Pacific'
>>> import zoneinfo
>>> zoneinfo.ZoneInfo('__init__.py')
ValueError: Invalid TZif file: magic not found
This happens when non TZif files or directories in the tzdata.zoneinfo module
are used as keys.
--
components: Library (Lib)
messages: 375225
nosy: josh.ja.butt
priority: normal
severity: normal
status: open
title: Unhandled exceptions in zoneinfo.ZoneInfo constructor
type: behavior
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41530>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33786] @asynccontextmanager doesn't work well with async generators
Joshua Oreman added the comment: This doesn't appear to have been backported to 3.7, even though it's in 3.6.6 and 3.8.0a0. -- nosy: +Joshua Oreman, lukasz.langa ___ Python tracker <https://bugs.python.org/issue33786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41303] perf_counter result does not count system sleep time in Mac OS
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue41303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41451] Cannot subclass typing.Generic with __weakref__ slot in Python 3.6
Joshua Bronson added the comment:
Thanks so much, @oremanj! Indeed, merely subscripting the class triggers the
bug, and your 'del slots' workaround does the trick!
For completeness, there is an updated (yet more minimal) repro below/attached.
"""Repro for Python 3.6 slots + weakref + typing.Generic subclass bug."""
from typing import Generic, TypeVar
from weakref import ref
T = TypeVar("T")
class MyGeneric(Generic[T]):
"""MyGeneric works as expected.
>>> example = MyGeneric()
>>> example
<__main__.MyGeneric object at ...>
>>> example._other
<__main__.MyGeneric object at ...>
>>> example._other._other
>>> from pickle import dumps, loads
>>> pickled = dumps(example)
>>> roundtripped = loads(pickled)
>>> roundtripped
<__main__.MyGeneric object at ...>
"""
__slots__ = ("_other", "__weakref__")
def __init__(self) -> None:
self._init_other()
def _init_other(self) -> None:
other = self.__class__.__new__(self.__class__)
other._other = ref(self)
self._other = other
def __getstate__(self) -> dict:
"""Needed to enable pickling due to use of __slots__ and weakrefs."""
return {}
def __setstate__(self, _) -> None:
"""Needed because use of __slots__ would prevent unpickling
otherwise."""
self._init_other()
# Merely the following is enough to trigger the bug on Python 3.6:
MyGeneric[T]
# This works around the issue if run first (thanks @oremanj):
del MyGeneric.__slots__ # does not actually 'unslot' the class
if __name__ == "__main__":
import doctest
doctest.testmod(optionflags=doctest.ELLIPSIS)
--
Added file: https://bugs.python.org/file49357/bpo41451-repro-min+workaround.py
___
Python tracker
<https://bugs.python.org/issue41451>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41451] Cannot subclass typing.Generic with __weakref__ slot in Python 3.6
Joshua Oreman added the comment: The problem appears to be occurring when the base class is subscripted, not when it's inherited. I can reproduce this issue on Python 3.6.10 by just evaluating Base[T]. 'del Base.__slots__' after Base is constructed seems to work around the issue, and allow Base[T] to be evaluated. Of course, Base is still slotted at this point, since __slots__ are consulted only when initially building the class. ------ nosy: +Joshua Oreman ___ Python tracker <https://bugs.python.org/issue41451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41451] Cannot subclass typing.Generic with __weakref__ slot in Python 3.6
Joshua Bronson added the comment:
Whittled this down to an even more minimal repro:
"""Repro for Python 3.6 slots + weakref + typing.Generic subclass bug."""
from typing import Generic, TypeVar
from weakref import ref
T = TypeVar("T")
class MyGeneric(Generic[T]):
"""MyGeneric works as expected.
>>> example = MyGeneric()
>>> from pickle import dumps, loads
>>> pickled = dumps(example)
>>> roundtripped = loads(pickled)
>>> roundtripped
<__main__.MyGeneric object at ...>
"""
__slots__ = ("_other", "__weakref__")
def __init__(self) -> None:
self._init_other()
def _init_other(self) -> None:
other = self.__class__.__new__(self.__class__)
other._other = self
self._other = ref(other)
def __getstate__(self) -> dict:
"""Needed to enable pickling due to use of __slots__ and weakrefs."""
return {}
def __setstate__(self, _) -> None:
"""Needed because use of __slots__ would prevent unpickling
otherwise."""
self._init_other()
# So far so good, but now let's make a subclass.
# The following class definition works on Python > 3.6, but fails on 3.6 with
# TypeError: __weakref__ slot disallowed: either we already got one, or
__itemsize__ != 0
class FailsInPy36(MyGeneric[T]):
"""Minimal repro.
>>> repro = FailsInPy36()
>>> repro
<__main__.FailsInPy36 object at ...>
"""
if __name__ == "__main__":
import doctest
doctest.testmod(optionflags=doctest.ELLIPSIS)
--
title: Class with __weakref__ slot cannot inherit from typing.Generic subclass
-> Cannot subclass typing.Generic with __weakref__ slot in Python 3.6
Added file: https://bugs.python.org/file49355/bpo41451-repro-min.py
___
Python tracker
<https://bugs.python.org/issue41451>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41451] Class with __weakref__ slot cannot inherit from typing.Generic subclass
Joshua Bronson added the comment: It turns out that this bug reproduces with any subclass of the generic type with a weakref slot, even without any multiple inheritance going on. For example: class Invertible2(Invertible[KT1, KT2]): pass is enough to trigger this bug along with the Invertible class in my previous example. Attaching the more minimal repro with this comment, and renaming the issue to remove the reference to multiple inheritance. -- title: Class with __weakref__ slot cannot inherit from multiple typing.Generic classes -> Class with __weakref__ slot cannot inherit from typing.Generic subclass Added file: https://bugs.python.org/file49353/bpo41451-repro.py ___ Python tracker <https://bugs.python.org/issue41451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41451] Class with __weakref__ slot cannot inherit from multiple typing.Generic classes
New submission from Joshua Bronson :
This appears to be a bug in Python 3.6 that I hit while trying to add type
hints to my bidirectional mapping library (https://bidict.rtfd.io).
Pasting a working, minimal repro below for easier inline viewing, and also
attaching for easier downloading and running.
Please let me know if there is a workaround that would allow me to continue to
support Python 3.6 after adding type hints without having to remove the use of
slots and weak references. I spent a while trying to find one first but was
then encouraged to report this by @ethanhs.
Thanks in advance for any pointers you may have.
#!/usr/bin/env python3
"""Repro for Python 3.6 slots + weakref + typing.Generic bug."""
from typing import Iterator, Mapping, MutableMapping, TypeVar
from weakref import ref
KT1 = TypeVar("KT1")
KT2 = TypeVar("KT2")
class Invertible(Mapping[KT1, KT2]):
"""A one-element mapping that is generic in two key types with a reference
to its inverse.
...which in turn holds a (weak) reference back to it.
>>> element = Invertible("H", 1)
>>> element
>>> element.inverse
>>> element.inverse.inverse
>>> element.inverse.inverse is element
True
>>> dict(element.items())
{'H': 1}
>>> dict(element.inverse.items())
{1: 'H'}
>>> list(element)
['H']
Uses the __slots__ optimization, and uses weakrefs for references in one
direction
to avoid strong reference cycles. And still manages to support pickling to
boot!
>>> from pickle import dumps, loads
>>> pickled = dumps(element)
>>> roundtripped = loads(pickled)
>>> roundtripped
"""
# Each instance has (either a strong or a weak) reference to its
# inverse instance, which has a (weak or strong) reference back.
__slots__ = ("_inverse_strong", "_inverse_weak", "__weakref__", "key1",
"key2")
def __init__(self, key1: KT1, key2: KT2) -> None:
self._inverse_weak = None
self._inverse_strong = inverse = self.__class__.__new__(self.__class__)
self.key1 = inverse.key2 = key1
self.key2 = inverse.key1 = key2
inverse._inverse_strong = None
inverse._inverse_weak = ref(self)
def __len__(self) -> int:
return 1
def __iter__(self) -> Iterator[KT1]:
yield self.key1
def __getitem__(self, key: KT1) -> KT2:
if key == self.key1:
return self.key2
raise KeyError(key)
def __repr__(self) -> str:
return f"<{self.__class__.__name__} key1={self.key1!r}
key2={self.key2!r}>"
@property
def inverse(self) -> "Invertible[KT2, KT1]":
"""The inverse instance."""
if self._inverse_strong is not None:
return self._inverse_strong
inverse = self._inverse_weak()
if inverse is not None:
return inverse
# Refcount of referent must have dropped to zero,
# as in `Invertible().inverse.inverse`, so init a new one.
self._inverse_weak = None
self._inverse_strong = inverse = self.__class__.__new__(self.__class__)
inverse.key2 = self.key1
inverse.key1 = self.key2
inverse._inverse_strong = None
inverse._inverse_weak = ref(self)
return inverse
def __getstate__(self) -> dict:
"""Needed to enable pickling due to use of __slots__ and weakrefs."""
state = {}
for cls in self.__class__.__mro__:
slots = getattr(cls, '__slots__', ())
for slot in slots:
if hasattr(self, slot):
state[slot] = getattr(self, slot)
# weakrefs can't be pickled.
state.pop('_inverse_weak', None) # Added back in __setstate__ below.
state.pop('__weakref__', None) # Not added back in __setstate__.
Python manages this one.
return state
def __setstate__(self, state) -> None:
"""Needed because use of __slots__ would prevent unpickling
otherwise."""
for slot, value in state.items():
setattr(self, slot, value)
self._inverse_weak = None
self._inverse_strong = inverse = self.__class__.__new__(self.__class__)
inverse.key2 = self.key1
inverse.key1 = self.key2
inverse._inverse_strong = None
inverse._inverse_weak = ref(self)
# So far so good, but now let's make a mutable version.
#
# The following class definition works on Python &g
[issue40816] Add missed AsyncContextDecorator to contextlib
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue40816> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22239] asyncio: nested event loop
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue22239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13322] The io module doesn't support non-blocking files
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue13322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32561] Add API to io objects for cache-only reads/writes
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue32561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32884] Adding the ability for getpass to print asterisks when password is typed
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue32884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40916] Proposed tweak to allow for per-task async generator semantics
New submission from Joshua Oreman : The current async generator finalization hooks are per-thread, but sometimes you want different async generator semantics in different async tasks in the same thread. This is currently challenging to implement using the thread-level hooks. I'm proposing a small backwards-compatible change to the existing async generator hook semantics in order to better support this use case. I'm seeking feedback on the proposal and also on how "major" it would be considered. Does it need a PEP? If not, does it need to wait for 3.10 or could it maybe still make 3.9 at this point? TL;DR: if the firstiter hook returns a callable, use that as the finalizer hook for this async generator instead of using the thread-level finalizer hook. == Why would you want this? == The use case that brought me here is trio-asyncio, a library that allows asyncio and Trio tasks to coexist in the same thread. Trio is working on adding async generator finalization support at the moment, which presents problems for trio-asyncio: it wouldn't work to finalize asyncio-flavored async generators as if they were Trio-flavored, or vice versa. It's easy to tell an async generator's flavor from the firstiter hook (just look at which flavor of task is running right now), but hard to ensure that the corresponding correct finalizer hook is called (more on this below). There are other possible uses as well. For example, one could imagine writing an async context manager that ensures all async generators firstiter'd within the context are aclose'd before exiting the context. This would be less verbose than guarding each individual use of an async generator, but still provide more deterministic cleanup behavior than leaving it up to GC. == Why is this challenging to implement currently? == Both of the above use cases want to provide a certain async generator firstiter/finalizer behavior, but only within a particular task or tasks. A task-local firstiter hook is easy: just install a thread-local hook that checks if you're in a task of interest, calls your custom logic if so or calls the previous hook if not. But a task-local finalizer hook is challenging, because finalization doesn't necessarily occur in the same context where the generator was being used. The firstiter hook would need to remember which finalizer hook to use for this async generator, but where could it store that information? Using the async generator iterator object as a key in a regular dictionary will prevent it from being finalized, and as a key in a WeakKeyDictionary will remove the information before the finalizer hook can look it up (because weakrefs are broken before finalizers are called). About the only solution I've found is to store it in the generator's f_locals dict, but that's not very ap pealing. == What's the proposed change? == My proposal is to allow the firstiter hook to return the finalizer hook that this async generator should use. If it does so, then when this async generator is finalized, it will call the returned finalizer hook instead of the thread-level one. If the firstiter hook returns None, then this async generator will use whatever the thread-level finalizer was just before firstiter was called, same as the current behavior. == How disruptive would this be? == Async generator objects already have an ag_finalizer field, so this would not change the object size. It's just providing a more flexible way to determine the value of ag_finalizer, which is currently not accessible from Python. There is a theoretical backwards compatibility concern if any existing firstiter hook returns a non-None value. There wouldn't be any reason to do so, though, and the number of different users of set_asyncgen_hooks() currently is likely extremely small. I searched all of Github and found only asyncio, curio, uvloop, async_generator, and my work-in-progress PR for Trio. All of these install either no firstiter hook or a firstiter hook that returns None. The implementation would likely only be a handful of lines change to genobject.c. -- components: asyncio messages: 371053 nosy: Joshua Oreman, asvetlov, njs, yselivanov priority: normal severity: normal status: open title: Proposed tweak to allow for per-task async generator semantics type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40773] DOC: Fix rendering for 'retval' on the pdb page
Joshua Walden added the comment: I am interesting in contributing and would like to claim this issue. -- nosy: +Joshua Walden ___ Python tracker <https://bugs.python.org/issue40773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38360] single-argument form of -isysroot should be supported
Joshua Root added the comment: That ValueError I mentioned causes build failures for extension modules whenever the CFLAGS in sysconfig contains an -isysroot flag in the single arg form. We ran into it a lot in MacPorts on Mojave and Catalina. So I would consider it a bug, and would prefer to backport to all branches that are open for bug fixes. -- ___ Python tracker <https://bugs.python.org/issue38360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide
Change by Joshua Merchant : -- nosy: +Joshua Merchant ___ Python tracker <https://bugs.python.org/issue36753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but is removed because it cannot be imported.
Joshua Y added the comment: It always a good idea to sleep on these things before I comment. Because I compiled SQLite3 under prefix /usr/local, I rebuilt Python 3.8.2 with `-L /usr/local/lib64` added to my LDFLAGS and now things are working fine (so far). -- ___ Python tracker <https://bugs.python.org/issue39410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but is removed because it cannot be imported.
Joshua Y added the comment: I am hitting a possibly related issue. System is running Centos6.9 and SQLite 3.10.0. Python 3.8.2 built successfully (using pyenv / python-build), and I can import the sqlite3 lib with seemingly no issue... % python3 Python 3.8.2 (default, Mar 21 2020, 20:15:25) [GCC 4.4.7 20120313 (Red Hat 4.4.7-18)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sqlite3 >>> from sqlite3.dbapi2 import * >>> from _sqlite3 import * >>> However, after I installed and ran jupyterhub, and attempted to log in, I hit the same 'undefined symbol' error [I 2020-03-21 21:42:52.465 JupyterHub spawner:1417] Spawning jupyterhub-singleuser --port=38433 Traceback (most recent call last): File "/opt/pyenv/versions/3.8.2/lib/python3.8/site-packages/notebook/services/sessions/sessionmanager.py", line 9, in import sqlite3 File "/opt/pyenv/versions/3.8.2/lib/python3.8/sqlite3/__init__.py", line 23, in from sqlite3.dbapi2 import * File "/opt/pyenv/versions/3.8.2/lib/python3.8/sqlite3/dbapi2.py", line 27, in from _sqlite3 import * ImportError: /opt/pyenv/versions/3.8.2/lib/python3.8/lib-dynload/_sqlite3.cpython-38-x86_64-linux-gnu.so: undefined symbol: sqlite3_close_v2 -- nosy: +Joshua Y ___ Python tracker <https://bugs.python.org/issue39410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39819] NULL pointer crash in Modules/_cursesmodule.c in PyInit__curses() on MIPS uclibc-ng and ncurses-6.2
New submission from Joshua Kinard :
Inside a MIPS O32 chroot, based on uclibc-ng-1.0.32, if python-27 or python-3.7
are built against ncurses-6.2, then after compilation, there is a crash in the
'_curses' module. Specific to Python-3.7, the crash is in
Modules/_cursesmodule.c:3482, PyInit__curses():
3477:{
3478:int key;
3479:char *key_n;
3480:char *key_n2;
3481:for (key=KEY_MIN;key < KEY_MAX; key++) {
3482:key_n = (char *)keyname(key);
3483:if (key_n == NULL || strcmp(key_n,"UNKNOWN KEY")==0)
3484:continue;
3485:if (strncmp(key_n,"KEY_F(",6)==0) {
3486:char *p1, *p2;
It looks like keyname() is casting to a NULL pointer and crashing when 'key' is
257. The issue is reproducible by running python and trying to import the
curses modules:
# python
Python 3.7.6 (default, Feb 29 2020, 22:51:27)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
Segmentation fault
Or:
# python -m curses
Segmentation fault
dmesg shows this on the main host:
[99297.243445] do_page_fault(): sending SIGSEGV to python for invalid read
access from
[99297.243459] epc = in python3.7m[40+1]
[99297.243483] ra = 76a68c6c in
_curses.cpython-37m-mips-linux-gnu.so[76a5+2]
I've been able to work out that the fault has something to do with ncurses
itself. There is no issue if built against ncurses-6.1, and even the later
datestamped patches appear to be okay. It seems like any ncurses AFTER
20190609 will exhibit the problem. ncurses-6.2 was recently released, and it,
too, causes this issue.
However, I am unable to get gdb to trace through any of the ncurses libraries.
The faulting code is in Python itself, so I assume it's something to do with a
macro definition or an include provided by ncurses-6.2 that introduces the
breakage.
This issue also only happens in a uclibc-ng-based root. I have had zero issues
building python-3.7 in multiple glibc-based roots and even a musl-1.1.24-based
root works fine. So I am not completely sure if the fault is truly with Python
itself, or the combination of uclibc-ng, ncurses-6.2, and Python.
As far as I know, the issue may also be specific to MIPS hardware, but I do not
have a similar chroot on any other architecture to verify this with. I'll
attach to this bug a gdb backtrace of Python built with -O0 and -gddb3. I have
a core file available if that will help, but will probably need to e-mail that
as I'll have to include the malfunctioning python binary and the separate debug
symbol files generated from my build.
--
components: Extension Modules
files: py37-gdb-bt-sigsegv-cursesmodule-uclibc-20200301.txt
messages: 363107
nosy: kumba
priority: normal
severity: normal
status: open
title: NULL pointer crash in Modules/_cursesmodule.c in PyInit__curses() on
MIPS uclibc-ng and ncurses-6.2
type: crash
versions: Python 2.7, Python 3.7
Added file:
https://bugs.python.org/file48942/py37-gdb-bt-sigsegv-cursesmodule-uclibc-20200301.txt
___
Python tracker
<https://bugs.python.org/issue39819>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38360] single-argument form of -isysroot should be supported
Joshua Root added the comment: Ping? -- ___ Python tracker <https://bugs.python.org/issue38360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38014] ./configure on recent macOS versions can fail with multiple "present but cannot be compiled" messages
Joshua Root added the comment: The crash reported by BMinas is reputedly related to the -fstack-check option, which is said to be on by default when MACOSX_DEPLOYMENT_TARGET=10.15. I've been unable to confirm whether there was just a bug in the beta, or if it's still a problem on the final Catalina release. -- nosy: +jmr ___ Python tracker <https://bugs.python.org/issue38014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38360] single-argument form of -isysroot should be supported
New submission from Joshua Root : The path associated with the -isysroot compiler flag can be supplied either as a separate argument or in the same argument as -isysroot itself. The places in library code that do special handling of this flag should support both forms, but currently only support the two separate arguments form. This means that the flag may not be removed when pointing to a nonexistent SDK or when a different SDK is specified in the user's CFLAGS, and at worst a ValueError is raised in compiler_fixup. -- components: Distutils, macOS messages: 353838 nosy: dstufft, eric.araujo, jmr, ned.deily, ronaldoussoren priority: normal pull_requests: 16146 severity: normal status: open title: single-argument form of -isysroot should be supported type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments
Joshua Cannon added the comment: Pretty much the same reason you would want to slice any other sequence. You want some range of values. top_most_3_dirs = myPath.parents[-3:] grandparents_and_beyond = myPath.parents[1:] The same goes for negative indexes. -- ___ Python tracker <https://bugs.python.org/issue35498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Joshua Cannon added the comment: > it may explain why negative indices or slices were initially not implemented: > It already looks like the result of a slice. Sure the values of the sequence could be thought of as being increasingly smaller slices of some other sequence, however I don't think it changes the fact that "parents" is a sequence, and sequences have well-defined semantics for negative indices and slices. Semantics which people expect, and have to find smelly workarounds for. -- ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36054] Way to detect CPU count inside docker container
Change by Joshua Bronson : -- nosy: +jab ___ Python tracker <https://bugs.python.org/issue36054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34652] never enable lchmod on Linux
Joshua Root added the comment: The follow-up fix (AC_CHECK_FUNC -> AC_CHECK_FUNCS) still needs to be backported to 2.7. Currently the lack of it causes lchmod to be disabled on all platforms, not just Linux. -- nosy: +jmr ___ Python tracker <https://bugs.python.org/issue34652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36184] [EASY] test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD
Joshua Jay Herman added the comment: So I changed 'pthread_cond_timedwait' to 'take_gil' and this didn't seem to have an effect on the unit test. I installed GDB 8.2 is that the same version you are using? -- ___ Python tracker <https://bugs.python.org/issue36184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36184] [EASY] test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD
Joshua Jay Herman added the comment: I was able to reproduce this on FreeBSD 12.0. -- ___ Python tracker <https://bugs.python.org/issue36184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36184] [EASY] test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD
Joshua Jay Herman added the comment: Hi, I would like to try to solve this issue. Does this occur on the latest version of FreeBSD? -- nosy: +zitterbewegung ___ Python tracker <https://bugs.python.org/issue36184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions to operator module
Joshua Bronson added the comment: If the deciders prefer to have these in the operator module for 3.8 (as Yury and Jelle requested above), my PR from a few months ago which implements this (https://github.com/python/cpython/pull/8895) can still be merged with no conflicts. I don't think any other changes to that patch are requested before it can be merged (i.e. it's only stalled on the decision whether to add these to builtins or operator), but I can still make time to address any new requested code changes if these are to go in operator. If these are to go in builtins instead, @nanjekyejoannah has volunteered to pick that up. So it seems like this can move forward one way or the other once we have a decision on operator vs. builtins. -- ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32810] Expose ags_gen and agt_gen in asynchronous generators
Joshua Oreman added the comment: I also ran into this. My workaround was to use gc.get_referents() on the async_generator_asend object, which returns a one-element list containing the async generator object. I don't know if this is guaranteed or just happened to work in the cases I was using it, but it might be good enough? -- nosy: +Joshua Oreman ___ Python tracker <https://bugs.python.org/issue32810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21041] pathlib.PurePath.parents rejects negative indexes
Joshua Cannon added the comment: I created issue35498 about .parents rejecting slices as well. (It was pointed out this discussion would probably decide that issue's fate) I think that .parents looking like a duck, but not quacking like one isn't very pythonic. Besides, the fact that p.parents[len(p.parents)-2] is allowed but p.parents[-2] is not just seems like extra steps. There's also list(p.parents)[-2], which is still not ideal. In either case, I'd imagine authors to put a comment like "PathLib .parents doesn't support negative indexes", which goes to show clients are expecting negative indices to work. I see that this issue is several years old. I'm happy to shepherd it if it needs further contributions. -- nosy: +thejcannon ___ Python tracker <https://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments
Joshua Cannon added the comment: If it is deemed a bug which needs to be fixed, I've gone ahead and attached the PR to fix it. CLA signage is pending approval at the company I work for, with most people out for the holidays (so it might be a day or two turnaround). -- ___ Python tracker <https://bugs.python.org/issue35498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments
Change by Joshua Cannon : -- keywords: +patch pull_requests: +10401 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments
New submission from Joshua Cannon : I would expect the following to work: ``` >>> import pathlib >>> pathlib.Path.cwd().parents[0:1] Traceback (most recent call last): File "", line 1, in File "...\Python36\lib\pathlib.py", line 593, in __getitem__ if idx < 0 or idx >= len(self): TypeError: '<' not supported between instances of 'slice' and 'int' ``` Since pathlib documents `parents` as a sequence-type, and slicing a sequence is pretty standard behavior. -- components: Library (Lib) messages: 331841 nosy: thejcannon priority: normal severity: normal status: open title: Parents objects in pathlib.Path don't support slices as __getitem__ arguments type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue35498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31601] Availability of utimensat, futimens not checked correctly on macOS
Joshua Root added the comment: This isn't just a cross-build issue, or rather (depending on how you look at it) cross-builds are increasingly the norm due to Apple only providing a newer SDK on older OS versions. For example the latest version of Xcode available for 10.12 only comes with the 10.13 SDK. -- ___ Python tracker <https://bugs.python.org/issue31601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35151] Python 2 xml.etree.ElementTree documentation tutorial uses undocumented arguments
New submission from Joshua Honeycutt : In python 2 documentation 19.7.1.6 (https://docs.python.org/2/library/xml.etree.elementtree.html#parsing-xml-with-namespaces) a second argument (ns) is passed to find and findall. However 19.7.3.2 (https://docs.python.org/2/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.find) only specifies the single match argument. If we compare the python 3 documentation the namespaces argument is included in the find method. (https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.find) Maybe the tutorial was created for python 3 version? I assume the function arguments are automatically generated, but I have not tested or tried these functions in python 2. I just stumbled on the docs while working with python 3. -- assignee: docs@python components: Documentation messages: 329174 nosy: docs@python, epakai priority: normal severity: normal status: open title: Python 2 xml.etree.ElementTree documentation tutorial uses undocumented arguments versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue35151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
Joshua Bronson added the comment: I spent a few minutes with git blame/checkout/show and so far have found https://bugs.python.org/issue1869 (via https://github.com/python/cpython/commit/e6a076d). Still reading -- looks like there were a number of different changes made to round() at the same time for various reasons -- so maybe changing from round_half_up to round_half_even was necessary for the other improvements, and it couldn't have been exposed as a separate function? Or maybe that was just never proposed? -- ___ Python tracker <https://bugs.python.org/issue32956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
Joshua Bronson added the comment: Thanks, Mark. Yes, I saw where Tim said round-half-even should be the default, but I didn't see any proposal to expose it as e.g. math.round_half_even() instead, nor a more complete look at what other languages do. That, along with the subject being 2.6 and not 3, made me think this change in Python 3 must have been discussed more fully elsewhere. Was it not? And I agree -- nowhere have I been proposing changing "round" again. My proposals have been: 1. Update the round() docs to make the documentation of this behavior less buried, 2. include a (brief) justification (possibly even just a link to http://wiki.c2.com/?BankersRounding or some more-authoritative document), and 3. link to where else this change in Python 3 was discussed more, if anywhere, or else confirm this change was made based on no additional analysis that we can find written down. It'd also be interesting to hear if this is something we wish we'd done differently now, but that shouldn't distract from 1, 2, and 3. -- ___ Python tracker <https://bugs.python.org/issue32956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
Joshua Bronson added the comment: Thanks Serhiy, I read the Python-Dev thread you linked to, but that doesn't resolve the issues: - Its topic is Python 2.6 (where this behavior does not occur) rather than Python 3 (where it does). - A few messages into the thread Guido does address Python 3, but in fact says "I think the consensus is against round-to-even in 3.0" (see https://mail.python.org/pipermail/python-dev/2008-January/075897.html). - There is no discussion of the fact that this behavior differs from the function named "round" in all the other programming languages I mentioned, and whether it would therefore be better exposed as an additional function (e.g. "round_to_even" or "round_unbiased", and in the math or statistics package rather than builtins). Surprisingly, Excel is the only other programming environment I saw discussed in the thread. (And round(2.5) == 3 there.) So that all suggests there must be some other thread or issue where this change for Python 3 have been discussed, but I looked again and could not find it. The C "rint" example you gave just seems to prove the point that this behavior should have a distinct name from "round". Regarding: > It is a common knowledge that rounding half-to-even is what users want in > most cases I don't think that's common knowledge; seems like citation needed? Based on all the other languages where this differs (not to mention Python 2), it's not clear users would want Python 3 to be the only different one. And this is definitely a surprise for the majority of programmers, whose experience with "round" is how it works everywhere else. (This is making it into pywat after all: https://github.com/cosmologicon/pywat/pull/40) I can submit a PR for at least updating the docs about this (as per my previous comment) if that would be welcomed. -- ___ Python tracker <https://bugs.python.org/issue32956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32956] python 3 round bug
Joshua Bronson added the comment:
This was so surprising to me that I had to check some other languages that I
had handy. It turns out that not one of JavaScript, Ruby, Perl, C++, Java, Go,
or Rust agrees with Python. In fact they all agreed with one another that 2.5
should round to 3. Examples below.
I understand from
https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259 that "to
always round up... can theoretically skew the data" but it's not clear why
that's a good enough reason to differ from the "round" function in all these
other languages (as opposed to e.g. offering this alternative behavior in some
additional "round_unskewed" function).
I assume the rationale for having Python 3's "round" differ from that of so
many other languages was written down when this decision was made, but I
searched and couldn't find it. Could anyone link to it in a comment here?
And would it be worth including rationale and a larger callout in the
https://docs.python.org/3/library/functions.html#round docs? The documentation
of this behavior is a bit buried among other things, and the rationale for it
is missing entirely.
$ node -e 'console.log(Math.round(2.5))'
3
$ ruby -e 'puts (2.5).round()'
3
$ perl -e 'use Math::Round; print round(2.5)'
3
$ cat test_round.cpp
#include
#include
int main(void) {
printf("%f\n", round(2.5));
}
$ g++ test_round.cpp && ./a.out
3.00
$ cat TestRound.java
class TestRound {
public static void main(String[] args) {
System.out.println(Math.round(2.5));
}
}
$ javac TestRound.java && java TestRound
3
$ cat test_round.go
package main
import "fmt"
import "math"
func main() {
fmt.Println(math.Round(2.5))
}
$ go build test_round.go && ./test_round
3
$ cat test_round.rs
fn main() {
println!("{}", (2.5_f64).round());
}
$ rustc test_round.rs && ./test_round
3
--
nosy: +jab
___
Python tracker
<https://bugs.python.org/issue32956>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions to operator module
Joshua Bronson added the comment: Interesting, thanks Yury! I only saw the discussion here which implied these wouldn't go directly into builtins for 3.8 (and I searched here and in GitHub, and couldn't find the PR you mentioned either), so I'm curious if that was tracked somewhere. It'd be unfortunate if the work I did on that PR couldn't be used, but I'd be even happier to have these as builtins. Thanks again for reviewing when you're back, and have a wonderful vacation in the meantime! -- ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions to operator module
Joshua Bronson added the comment: Updating the issue title to reflect the decision to add these to the operator module rather than to built-ins. Submitted a PR here: https://github.com/python/cpython/pull/8895 -- title: aiter() and anext() built-in functions -> add aiter() and anext() functions to operator module ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
