[Python-Dev] Preserve keyword argument order in unittest.mock call repr output
>From Python 3.6 the order of keyword arguments to a function is preserved. In >https://bugs.python.org/issue21256 the order of keyword arguments for >unittest.mock's repr were sorted to return deterministic output for usage in >doctest and other use cases. This currently gives little inconsistent output >where the keyword argument order in below mock call is (b=2, a=1) but it's >sorted in the error message and mock_calls list to give (a=1, b=2). I have opened https://bugs.python.org/issue37212 to preserve the order. It was recommended in the issue 21256 too at https://bugs.python.org/issue21256#msg216512 . The drawback is that it's backwards incompatible where tests that assert error messages might have used the sorted order. Due to equality implementation call(a=1, b=2) == call(b=2, a=1) is still True so assertions are not affected. There are no test failures in mock test suite except the test in the original issue where sorted output is asserted. Sorting the keyword arguments was also not documented. I propose removing this sorted order in 3.9 and to preserve the original order. The change is straightforward and I can add a PR if this change is accepted. >>> from unittest.mock import Mock, call >>> m = Mock(name='m') >>> m(b=2, a=1) >>> call(a=1, b=2) == call(b=2, a=1) True >>> m.mock_calls [call(a=1, b=2)] >>> m.assert_called_with(c=1) Traceback (most recent call last): File "", line 1, in File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 870, in assert_called_with raise AssertionError(_error_message()) from cause AssertionError: expected call not found. Expected: m(c=1) Actual: m(a=1, b=2) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6F2NGCERZLZ2CDGYIAR5QOHMGAAE5VHE/
[Python-Dev] Re: Preserve keyword argument order in unittest.mock call repr output
Sent from my iPhone > On 22 Jun 2019, at 08:15, Karthikeyan Singaravelan > wrote: > > From Python 3.6 the order of keyword arguments to a function is preserved. In > https://bugs.python.org/issue21256 the order of keyword arguments for > unittest.mock's repr were sorted to return deterministic output for usage in > doctest and other use cases. This currently gives little inconsistent output > where the keyword argument order in below mock call is (b=2, a=1) but it's > sorted in the error message and mock_calls list to give (a=1, b=2). > > I have opened https://bugs.python.org/issue37212 to preserve the order. It > was recommended in the issue 21256 too at > https://bugs.python.org/issue21256#msg216512 . The drawback is that it's > backwards incompatible where tests that assert error messages might have used > the sorted order. Due to equality implementation call(a=1, b=2) == call(b=2, > a=1) is still True so assertions are not affected. There are no test failures > in mock test suite except the test in the original issue where sorted output > is asserted. Sorting the keyword arguments was also not documented. I propose > removing this sorted order in 3.9 and to preserve the original order. The > change is straightforward and I can add a PR if this change is accepted. +1 go ahead. The test that will fail was synthetic for the sorting and it won't cause real tests to fail. Michael > from unittest.mock import Mock, call m = Mock(name='m') m(b=2, a=1) > call(a=1, b=2) == call(b=2, a=1) > True m.mock_calls > [call(a=1, b=2)] m.assert_called_with(c=1) > Traceback (most recent call last): > File "", line 1, in > File > "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", > line 870, in assert_called_with >raise AssertionError(_error_message()) from cause > AssertionError: expected call not found. > Expected: m(c=1) > Actual: m(a=1, b=2) > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/6F2NGCERZLZ2CDGYIAR5QOHMGAAE5VHE/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JWPDLKNM5X27FRWJG7UOAFXHNRUGH44S/
[Python-Dev] v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())
The implementation of issue 36085 breaks PyQt on Windows as it relies on PATH to find the Qt DLLs. The problem is that PyQt is built using the stable ABI and a single wheel is supposed to support all versions of Python starting with v3.5. On the assumption (perhaps naive) that using the stable ABI would avoid future compatibility issues, the existing PyPI wheels have long been tagged with cp38. Was this issue considered at the time? What is the official view? Thanks, Phil ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YFNKFRJGNM25VUGDJ5PVCQM4WPLZU6J7/
[Python-Dev] Re: v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())
On 22Jun.2019 1404, Phil Thompson wrote: > The implementation of issue 36085 breaks PyQt on Windows as it relies on > PATH to find the Qt DLLs. The problem is that PyQt is built using the > stable ABI and a single wheel is supposed to support all versions of > Python starting with v3.5. On the assumption (perhaps naive) that using > the stable ABI would avoid future compatibility issues, the existing > PyPI wheels have long been tagged with cp38. > > Was this issue considered at the time? What is the official view? The official view is that using PATH to locate DLL dependencies is a security risk and has been deprecated by Windows. The new Store package already ignores PATH when resolving DLLs, and the change to 3.8 brings all deployments of Python on Windows into line, as well as adding the os.add_dll_directory() function that your package can use to add *only* the directory it needs. I'm sorry we didn't promote the change widely enough for you to hear about it prior to 3.8.0b1 being released, but it was made deliberately. As far as I'm aware, there are no interactions with the stable ABI here. The compatibility issue is that Windows is (slowly) dropping support for the search path you were relying on, and ultimately there is no way around that. Rather than having to tell some subset of end-users that your package won't work for them, we decided to aim for consistency and provide package developers with the means to fix it themselves. Developers from numpy, scipy and Anaconda were involved in the discussion. The section of the porting notes dealing with this issue is https://docs.python.org/3.8/whatsnew/3.8.html#bpo-36085-whatsnew Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R5RIBKDOH3J5ZBI22J3VHQWD4PEUTGWK/
[Python-Dev] Re: v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())
Hi Phil, Thanks for trying the beta. Please file this as an issue at bugs.python.org. Doing so would be helpful for folks who can look into the issue. Thanks, Carol On 6/22/19 2:04 PM, Phil Thompson wrote: The implementation of issue 36085 breaks PyQt on Windows as it relies on PATH to find the Qt DLLs. The problem is that PyQt is built using the stable ABI and a single wheel is supposed to support all versions of Python starting with v3.5. On the assumption (perhaps naive) that using the stable ABI would avoid future compatibility issues, the existing PyPI wheels have long been tagged with cp38. Was this issue considered at the time? What is the official view? Thanks, Phil ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YFNKFRJGNM25VUGDJ5PVCQM4WPLZU6J7/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NOATCX6I2HR3ZR5FQUPWXPVBYRJ6BKMZ/
