[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
[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
[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
[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
[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
[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
[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] 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] 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
[issue30837] Mac OS High Sierra Beta - Python Crash
New submission from Joshua: Process: Python [13106] Path: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Identifier:Python Version: 2.7.10 (2.7.10) Code Type: X86-64 (Native) Parent Process:Python [13070] Responsible: Python [13106] User ID: 501 Date/Time: 2017-07-03 10:28:23.591 -0400 OS Version:Mac OS X 10.13 (17A291m) Report Version:12 Anonymous UUID:C76645A8-C44A-EAB5-D937-2BD69A20A0A9 Time Awake Since Boot: 18000 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Reason:Namespace OBJC, Code 0x1 Application Specific Information: crashed on child side of fork pre-exec objc[13106]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fffbded33d6 __abort_with_payload + 10 1 libsystem_kernel.dylib 0x7fffbdecdf71 abort_with_payload_wrapper_internal + 89 2 libsystem_kernel.dylib 0x7fffbdecdf18 abort_with_reason + 22 3 libobjc.A.dylib 0x7fffbd1a99f2 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 108 4 libobjc.A.dylib 0x7fffbd1a98a4 _objc_fatal(char const*, ...) + 135 5 libobjc.A.dylib 0x7fffbd1aa4cb performForkChildInitialize(objc_class*, objc_class*) + 341 6 libobjc.A.dylib 0x7fffbd19ae8f lookUpImpOrForward + 228 7 libobjc.A.dylib 0x7fffbd19a914 _objc_msgSend_uncached + 68 8 com.apple.CoreFoundation0x7fff96aa2a92 CFDateCreate + 34 9 com.apple.CoreFoundation0x7fff96aa0168 __CFBinaryPlistCreateObjectFiltered + 1608 10 com.apple.CoreFoundation0x7fff96aa1947 __CFBinaryPlistCreateObjectFiltered + 7719 11 com.apple.CoreFoundation0x7fff96a86b1b __CFTryParseBinaryPlist + 187 12 com.apple.CoreFoundation0x7fff96a864b1 _CFPropertyListCreateWithData + 97 13 com.apple.CoreFoundation0x7fff96a863a0 CFPropertyListCreateWithData + 80 14 com.apple.CoreFoundation0x7fff96a9f08b -[CFPrefsPlistSource handleReply:toRequestNewDataMessage:onConnection:retryCount:error:] + 683 15 com.apple.CoreFoundation0x7fff96a9edb3 __93-[CFPrefsSearchListSource handleReply:toRequestNewDataMessage:onConnection:retryCount:error:]_block_invoke + 147 16 libxpc.dylib0x7fffbe040d71 xpc_array_apply + 57 17 com.apple.CoreFoundation0x7fff96a9ecec -[CFPrefsSearchListSource handleReply:toRequestNewDataMessage:onConnection:retryCount:error:] + 300 18 com.apple.CoreFoundation0x7fff96c2644c __80-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:]_block_invoke_3.139 + 76 19 com.apple.CoreFoundation0x7fff96c4d3e4 -[_CFXPreferences withConnectionForRole:performBlock:] + 36 20 com.apple.CoreFoundation0x7fff96c263f5 __80-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:]_block_invoke_2.138 + 117 21 libsystem_trace.dylib 0x7fffbe01f1ab _os_activity_initiate_impl + 53 22 com.apple.CoreFoundation0x7fff96c26352 __80-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:]_block_invoke.136 + 114 23 com.apple.CoreFoundation0x7fff96c25c97 CFPREFERENCES_IS_WAITING_FOR_USER_CFPREFSD + 39 24 com.apple.CoreFoundation0x7fff96c25eec -[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:] + 348 25 com.apple.CoreFoundation0x7fff96a9d476 -[CFPrefsSearchListSource alreadylocked_copyDictionary] + 326 26 com.apple.CoreFoundation0x7fff96a9cff3 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 67 27 com.apple.CoreFoundation0x7fff96be1465 -[CFPrefsSource copyValueForKey:] + 53 28 com.apple.CoreFoundation0x7fff96c4c040 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 32 29 com.apple.CoreFoundation0x7fff96c2730f __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke + 287 30 com.apple.CoreFoundation0x7fff96c27185 -[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:] + 341 31
[issue30902] Python-Redmine plugin not seeing python install MacOS
New submission from Joshua: trying to install the following on macos sierra 10.12.5. I am trying to install the python-redmine module. i ran the following: sudo easy_install pip pip install python-redmine i get the following output when trying to run a python script: Joshuas-MacBook-Pro:~ joshuaayes$ ./changelog.py Traceback (most recent call last): File "./changelog.py", line 2, in from redmine import Redmine ImportError: No module named redmine Joshuas-MacBook-Pro:~ joshuaayes$ pip install python-redmine Requirement already satisfied: python-redmine in /Library/Python/2.7/site-packages Joshuas-MacBook-Pro:~ joshuaayes$ anyone have any insight why this is not working? -- components: Extension Modules messages: 298149 nosy: ayesjm priority: normal severity: normal status: open title: Python-Redmine plugin not seeing python install MacOS versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue30902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18133] Modulus not calculating properly?
New submission from Joshua: The Modulus doesn't seem to pull the proper remainder from simple calculations. Look at the difference below between the remainder of a regular division calculation and the modulus: Am I missing something??? >>> print (str(10.2 / 2)) 5.1 >>> print (str(10.2 % 2)) 0.1993 >>> -- components: Windows messages: 190606 nosy: pccreator25 priority: normal severity: normal status: open title: Modulus not calculating properly? type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18133> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18133] Modulus not calculating properly?
Joshua added the comment: never mind, long day sorry! -- resolution: -> works for me status: open -> closed ___ Python tracker <http://bugs.python.org/issue18133> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27478] Python Can't run
New submission from Joshua: I am using the book, Beginning Programming with Python For Dummies and I am stuck. On chapter 10 of the book, there is a dialog box that says"Changing the current python directory". Inside the dialog box there is an instruction on how to change directory, which I followed. I typed: "os.chdir(C:\the python root directory) and press enter and my problem started. The application can't run anything again. When I try to run, I get this message "IDLE's subprocess didn't make connection. Either IDLE cant start a subprocess or personal firewall software is blocking the connection". I have re-installed many times, tried google to see if i can find anything but none has helped. I am new in programming and I will really appreciate your assistant. -- components: IDLE messages: 270146 nosy: Keboku priority: normal severity: normal status: open title: Python Can't run type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27478> ___ ___ 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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[issue13035] "maintainer" value clear the "author" value when registering
New submission from Joshua Bronson : This issue was originally opened in the PyPI tracker but was dismissed on the theory that it's a bug in Python: https://sourceforge.net/tracker/index.php?func=detail&aid=3396924&group_id=66150&atid=513503 """ If in one package's setup.py I provide maintainer (with email) and author (whith email) after the "python setup.py register ... upload" I create a new package where I see the maintainer as a creator. If I manually fix it through the pypi user interface it works, so seems that this is only a bug in the register procedure. """ -- messages: 14 nosy: jab priority: normal severity: normal status: open title: "maintainer" value clear the "author" value when registering ___ Python tracker <http://bugs.python.org/issue13035> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13271] When -h is used with argparse, default values that fail should not matter
New submission from Joshua Chia :
What steps will reproduce the problem?
1. Make a script containing this code:
parser = argparse.ArgumentParser()
parser.add_argument('-i', '--input-base-directory',
type=argparse.FileType('r'),
default='/home')
parser.parse_args()
2. Run the script with '-h'.
3. See it complain that '/home' is a directory
Detailed explanation:
With '-h', we just need to print the help message. We shouldn't fail on a
default value that's wrong or else the help message will not get printed and
the user will have no idea what the problem is. This is a valid use case as I
want to provide a default location, but I can't guarantee that the location
works on the user's machine. I end up doing my own checking.
--
components: Library (Lib)
messages: 146458
nosy: Joshua.Chia
priority: normal
severity: normal
status: open
title: When -h is used with argparse, default values that fail should not matter
type: feature request
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13271>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13343] Lambda keyword-only argument not updating co_freevars
New submission from Joshua Landau : When setting defaults to keyword-only arguments in lambdas which are inside non-global scopes, cPython doesn't push the name to it's closure's co_freevars. EXAMPLE: global_variable = None (lambda: (lambda *, keyword_only=global_variable: None))() Because the inner lambda hasn't told the outer lambda to put global_variable in co_freevars, it fails to create the default to keyword_only. This only happens if the inner function is a lambda and you are setting a keyword_only variable. It does not cause a crash if global_variable is local to the outer lambda, as the opcode LOAD_FAST is still created properly (as opposed to LOAD_NAME). It does not crash if global_variable is used elsewhere in the outer function as co_freevars will be updated with it, allowing LOAD_NAME to retrieve it. I've never done a bug here before and I'm unsure what to say, so please be nice and correct me if I'm doing it wrong. -- components: Interpreter Core messages: 147026 nosy: Joshua.Landau priority: normal severity: normal status: open title: Lambda keyword-only argument not updating co_freevars type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue13343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13343] Lambda keyword-only argument not updating co_freevars
Joshua Landau added the comment: Glad to help :) It's made my day. I get to boast at school now! -- ___ Python tracker <http://bugs.python.org/issue13343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
Joshua Root added the comment: The fix that was committed doesn't work if CC is a full path like /usr/bin/clang. -- nosy: +jmr ___ Python tracker <http://bugs.python.org/issue11149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13658] Extra clause in class grammar documentation
New submission from Joshua Landau :
Inside the grammar for classes[1], the documentation states that the
inheritance list can be of type:
"(" [argument_list [","] | comprehension] ")"
The "comprehension" part seems to be superfluous, especially as it is valid
grammar without the clause.
The 2.7 docs state just "[expression list]", so either the addition should be
justified or the extra clause removed.
[1]
http://docs.python.org/py3k/reference/compound_stmts.html#grammar-token-classdef
Please see
http://mail.python.org/pipermail/python-list/2011-December/1284989.html for
discussion.
--
assignee: docs@python
components: Documentation
messages: 150169
nosy: Joshua.Landau, docs@python
priority: normal
severity: normal
status: open
title: Extra clause in class grammar documentation
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13658>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7734] discuss mark-as-invalid trick in heapq docs
Joshua Bronson added the comment: Thanks for the great additions. -- ___ Python tracker <http://bugs.python.org/issue7734> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6941] Socket error when launching IDLE
Joshua Purcell added the comment: Sorry I've not replied to anyones thoughts until now but nothing seems to fix it -- components: +Windows -IDLE resolution: works for me -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue6941> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10426] The whole thing is NOT good
New submission from Joshua Purcell : There is a complete FAIL in this versionand all other versions like 3.* THEY ALL FREEZE UP MY SYSTEM (Windows) HELP -- components: Windows messages: 121227 nosy: 08jpurcell priority: normal severity: normal status: open title: The whole thing is NOT good type: crash versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue10426> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11434] Python 3.2 input() does not remove "\r" at the end of returned string.
New submission from Joshua Logan :
Hello,
It is mentioned in the documentation for input() (
http://docs.python.org/py3k/library/functions.html#input ) that the newline is
stripped from the end of the returned string. However, on Windows, it used to
trim '\r\n'. Now it no longer trims '\r'.
See output below:
C:\>python
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32
>>> name = input("What's your name? ")
What's your name? Josh
>>> print(name)
Josh
>>> print(list(name))
['J', 'o', 's', 'h', '\r']
--
components: Windows
messages: 130265
nosy: jaylogan
priority: normal
severity: normal
status: open
title: Python 3.2 input() does not remove "\r" at the end of returned string.
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue11434>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
Changes by Joshua Lock : -- nosy: +joshual ___ Python tracker <http://bugs.python.org/issue8194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10988] Descriptor protocol documentation for super bindings is incorrect
New submission from Joshua Arnold : In 'Doc/reference/datamodel.rst', the 'Invoking Descriptors' documentation specifies the following behavior for super objects: [snip] Super Binding If ``a`` is an instance of :class:`super`, then the binding ``super(B, obj).m()`` searches ``obj.__class__.__mro__`` for the base class ``A`` immediately preceding ``B`` and then invokes the descriptor with the call: ``A.__dict__['m'].__get__(obj, A)``. [snip] In the above paragrah, the call: A.__dict__['m'].__get__(obj, A) is incorrect. In reality, the descriptor is invoked via: A.__dict__['m'].__get__(obj, obj.__class__) Loosely speaking, the 'owner' argument is set to the subclass associated with the super object, not the superclass. There is a similar error in the 'Descriptor HowTo Guide' under 'Invoking Descriptors' (Strictly speaking, the specification is inaccurate on some other points. It assumes obj is not a class and doesn't state that the entire mro preceding 'B' is searched for 'm'. But those may be considered simplifications for the sake of brevity) I considered reporting this as a bug in the implementation rather than the specification. But I think the implementation's algorithm is the correct one. In particular, it yields the desired behavior for classmethods In any case, the current behavior has been around for a while (it was the fix for issue #535444, dating back to 2.2) Code demonstrating the current behavior: class Desc(object): def __get__(self, instance, owner): return owner class A(object): attr = Desc() class B(A): pass class C(B): pass instance = C() assert super(B,instance).attr == C assert super(B,C).attr == C #According to the specification, the assertions should be: #assert super(B,instance).attr == A #assert super(B,C).attr == A -- assignee: docs@python components: Documentation messages: 126895 nosy: Joshua.Arnold, docs@python priority: normal severity: normal status: open title: Descriptor protocol documentation for super bindings is incorrect versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10988> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11007] stack tracebacks should give the relevant class name
New submission from Joshua Blount : When I get a stack traceback, it would be very handy if the traceback gave me the relevant class name (along with all the current information). -- components: Interpreter Core messages: 127015 nosy: stickwithjosh priority: normal severity: normal status: open title: stack tracebacks should give the relevant class name type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue11007> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11007] stack tracebacks should give the relevant class name
Joshua Blount added the comment: Yes! -- ___ Python tracker <http://bugs.python.org/issue11007> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Add a factorial function
Joshua Uziel <[EMAIL PROTECTED]> added the comment: Or slightly better: from operator import mul def factorial(num): return reduce(mul, range(2, num+1), 1) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2138> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Add a factorial function
Joshua Uziel <[EMAIL PROTECTED]> added the comment: It's a simplified version, but why not something like this: import operator def factorial(num): return reduce(operator.mul, range(1, num+1)) A product() function could also be done similarly. -- nosy: +uzi ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2138> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3384] Documentation for re.findall and re.finditer lacks "ordering" information
New submission from Joshua Kugler <[EMAIL PROTECTED]>: According to a discussion on comp.lang.python, re.findall and re.finditer scan strings from left to right, and returns them in the order it found them. It would be nice to note that in documentation. -- assignee: georg.brandl components: Documentation messages: 69815 nosy: georg.brandl, jkugler severity: normal status: open title: Documentation for re.findall and re.finditer lacks "ordering" information type: feature request versions: Python 2.5, Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3384> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3384] Documentation for re.findall and re.finditer lacks "ordering" information
Joshua Kugler <[EMAIL PROTECTED]> added the comment: That looks good. Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3384> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3742] Parsing XML file with Unicode characters causes problem
New submission from Joshua Logan <[EMAIL PROTECTED]>: Python 3.0b2 will not parse the XML file located at http://rubyquiz.com/SongLibrary.xml.gz It complains of a UnicodeEncodeError 'charmap' codec can't encode character '\xc8' in position 45: ch aracter maps to I included a sample program, just in case I was doing something wrong while coding. Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. -- components: XML files: read_song_xml.py messages: 72211 nosy: jaylogan severity: normal status: open title: Parsing XML file with Unicode characters causes problem type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11319/read_song_xml.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3742> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7734] discuss mark-as-invalid trick in heapq docs
New submission from Joshua Bronson : Though the heapq module does not support changing the priority of a particular element of the heap (a necessary operation for the A* search family of algorithms), such an element can be marked as invalid and a new element can be added with different priority. Any element marked as invalid that makes it to the top of the heap can simply be popped off and ignored. Users who haven't seen this trick before might mistakenly think the heapq module does not provide sufficient operations to implement A* search. Please see the recent thread on comp.lang.python for more background: http://groups.google.com/group/comp.lang.python/browse_frm/thread/8adc3ce8d2219647 -- assignee: georg.brandl components: Documentation messages: 98034 nosy: georg.brandl, jab, rhettinger severity: normal status: open title: discuss mark-as-invalid trick in heapq docs versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7734> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5220] os.makedirs' mode argument has bad default value
New submission from Joshua Bronson : os.makedirs' mode argument defaults to a hardcoded value of 511 (0777 in octal). This forces the caller to either pass in a different hardcoded value (commonly 0750), or to implement a workaround that calculates the expected mode based on the process owner's umask: umask, _ = subprocess.Popen(['sh', '-c', 'umask'], stdout=subprocess.PIPE).communicate() umask = int(umask, 8) mode = 0777 ^ umask os.makedirs(dir, mode) Preferred behavior would be to have the mode default to the value which takes the umask into account rather than the hardcoded value 0777, so that directories would be created with the same permissions as e.g. files created via open(..). N.B. I'm guessing the above workaround won't work on Windows (please excuse my poor Windows knowledge). All the more reason to have os.makedirs calculate the mode properly if none is given. -- messages: 81666 nosy: jab severity: normal status: open title: os.makedirs' mode argument has bad default value versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5220] os.makedirs' mode argument has bad default value
Joshua Bronson added the comment: Ah, I was misunderstanding the behavior of mkdir, thank you for the explanation. My misunderstanding stemmed from recently coming across two widely-used packages which both pass mode=0750 to os.makedirs. I have no idea why they would be doing this (as it effectively throws away part of the umask), unless they too are misunderstanding the mode parameter. My suspicion is that the mode parameter is widely misunderstood to mean the desired permissions of the created directory. I have filed tickets in the packages in which I came across this to make sure they're doing what they intend. Could the __doc__ for os.mkdir and os.makedirs be expanded to make this clearer? ___ Python tracker <http://bugs.python.org/issue5220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5220] os.makedirs' mode argument has bad default value
Joshua Bronson added the comment: > My suspicion is that people setting explicit file permissions > typically know what they are doing, and that you will find that > your tickets get closed as invalid, explaining to you that this > mode usage is fully intentional. For what it's worth, I asked Mike Bayer (author of Beaker and Mako, the packages in question) what the intention was, and the 0750 seems to have been an error: Apparently HTML::Mason (what Myghty was based on) may have originally used 0750 but has since changed it to 0775 (search for "0775" in http://svn.urth.org/filedetails.php? repname=Mason&path=%2Ftrunk%2Flib%2FHTML%2FMason%2FInterp.pm&rev=0&sc=0) . The 0750 propagated from Myghty into Mako and Beaker, but has no apparent reason to be there. For what else it's worth, I've run this by a few other programmers I consider quite smart and experienced (including Ian Bicking), and none of them realized the meaning of the mode parameter either. (If they had I never would have filed this ticket, as I checked with them first!) I agree that knowledge of relative paths should be assumed, but I'm convinced that the mode behavior is widely misunderstood enough to warrant at least one-line "gotcha" in the docstring. ___ Python tracker <http://bugs.python.org/issue5220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
[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
[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
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
[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
[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
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
[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
[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
[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
[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
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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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] 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] 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:
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
[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
[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
[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
