Mailman 3 July 2019 - Python-Dev

Comparing dict.values()
by Kristian Klette 30 Jul '19

30 Jul '19

Hi! During the sprints after EuroPython, I made an attempt at adding support for comparing the results from `.values()` of two dicts. Currently the following works as expected: ``` d = {'a': 1234} d.keys() == d.keys() d.items() == d.items() ``` but `d.values() == d.values()` does not return the expected results. It always returns `False`. The symmetry is a bit off. In the bug trackers[0] and the Github PR[1], I was asked to raise the issue on the python-dev mailing list to find a consensus on what comparing `.values()` should do. I'd argue that Python should compare the values as expected here, or if we don't want to encourage that behaviour, maybe we should consider raising an exception. Returning just `False` seems a bit misleading. What are your thoughts on the issue? Best regards, Kristian Klette [0]: https://bugs.python.org/issue37585 [1]: https://github.com/python/cpython/pull/14737

21 58

[RELEASE] Python 3.8.0b3 is now available for testing
by Łukasz Langa 30 Jul '19

30 Jul '19

This time without delays, I present you Python 3.8.0b3: https://www.python.org/downloads/release/python-380b3/ <https://www.python.org/downloads/release/python-380b3/> This release is the third of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0b4, the last beta release, currently scheduled for 2019-08-26. Call to action We strongly encourage maintainers of third-party Python projects to test with 3.8 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and no code changes after 3.8.0rc1, the release candidate. To achieve that, it will be extremely important to get as much exposure for 3.8 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Last beta coming Beta 4 can only be released if all “Release blocker” and “Deferred blocker” issues on bugs.python.org <http://bugs.python.org/> for 3.8.0 are resolved. Please prioritize those for the next four weeks. Acknowledgements Thanks to our binary builders, Ned and Steve, who were very quick today to get the macOS and Windows installers ready. The Windows story in particular got pretty magical, it’s now really fully automatic end-to-end. Thanks to Victor for vastly improving the reliability of multiprocessing tests since Beta 2. Thanks to Pablo for keeping the buildbots green. - Ł

2 1

🍝 New keyword in bpo: `newcomer friendly`
by Mariatta 29 Jul '19

29 Jul '19

🍝 copy-pasta from core-mentorship mailing list. There is now a “newcomer friendly” keyword in bpo. My hope is that going forward, we can tag issues that are suitable for first time contributors with this keyword. It would be great for experienced contributors already familiar with our workflow to not work on issues tagged with newcomer friendly and leave that to new contributors. I’ve added the keyword to Devguide’s Triaging section, with additional guideline of what can be tagged as newcomer friendly. Typically it should be straightforward, well-defined issue, and low-risk. https://devguide.python.org/triaging.html#keywords Thanks. ᐧ

8 13

Summary of Python tracker Issues
by Python tracker 26 Jul '19

26 Jul '19

ACTIVITY SUMMARY (2019-07-19 - 2019-07-26) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7127 (+16) closed 42314 (+42) total 49441 (+58) Open issues with patches: 2882 Issues opened (40) ================== #37633: Py_CompileString and PyParser_SimpleParseString not exported i https://bugs.python.org/issue37633 opened by pyscripter #37634: doc: "module" of a warning might be its filename https://bugs.python.org/issue37634 opened by blueyed #37635: Using constant for whence arg in seek() https://bugs.python.org/issue37635 opened by aeros167 #37636: Deprecate slicing and ordering operations on sys.version https://bugs.python.org/issue37636 opened by ncoghlan #37637: multiprocessing numpy.ndarray not transmitted properly https://bugs.python.org/issue37637 opened by 2xB #37638: Having issues following build instructions https://bugs.python.org/issue37638 opened by Tianming Zhuang #37640: telnetlib crash in Python3 while receiving un-printable charac https://bugs.python.org/issue37640 opened by hoang nguyen #37641: Embeddable distribution pyc filenames show build machine locat https://bugs.python.org/issue37641 opened by Bill Collins #37642: timezone allows no offset from range (23:59, 24:00) https://bugs.python.org/issue37642 opened by joernheissler #37645: Replace PyEval_GetFuncName/PyEval_GetFuncDesc https://bugs.python.org/issue37645 opened by jdemeyer #37646: eval() in a list comprehension https://bugs.python.org/issue37646 opened by Grzegorz Krasoń #37648: Fix minor inconsistency in the order of == operands https://bugs.python.org/issue37648 opened by serhiy.storchaka #37649: calculate_init fails to check that EXEC_PREFIX was decoded https://bugs.python.org/issue37649 opened by orivej #37650: TemporaryDirectory objects should LOCK_SH to avoid being delet https://bugs.python.org/issue37650 opened by refi64 #37651: Change of inheritance of asyncio.CancelledError needs document https://bugs.python.org/issue37651 opened by garyvdm #37652: Multiprocessing shared_memory ValueError on race with Shareabl https://bugs.python.org/issue37652 opened by bjs #37654: 2to3 no-ops on embeddable distribution https://bugs.python.org/issue37654 opened by Bill Collins #37657: ERROR: grip 4.5.2 requires docopt>=0.4.0, which is not install https://bugs.python.org/issue37657 opened by Dima.Tisnek #37658: In some cases asyncio.wait_for can lead to socket leak. https://bugs.python.org/issue37658 opened by Nikita Ilyasov #37659: subprocess.list2cmdline() should not escape wrapping single/do https://bugs.python.org/issue37659 opened by kejxu #37660: Drop support for Aspen magic directories in venv's activate sc https://bugs.python.org/issue37660 opened by brett.cannon #37661: venv activation scripts erroneously check if __VENV_PROMPT__ i https://bugs.python.org/issue37661 opened by brett.cannon #37662: Document venv.EnvBuilder.upgrade_dependencies() https://bugs.python.org/issue37662 opened by brett.cannon #37663: Making venv activation script prompts consistent https://bugs.python.org/issue37663 opened by brett.cannon #37664: Update bundled pip and setuptools https://bugs.python.org/issue37664 opened by steve.dower #37665: threading.TIMEOUT_MAX integer overflow on 32-bit builds with t https://bugs.python.org/issue37665 opened by Arun Sharma #37666: urllib.requests.urlopen doesn't support cadata= https://bugs.python.org/issue37666 opened by gregory.p.smith #37668: Allow individual test to be specified by "#" or "." https://bugs.python.org/issue37668 opened by Hasan Diwan #37669: Make mock_open return per-file content https://bugs.python.org/issue37669 opened by Anvil #37673: Tkinter won't create 5000 check boxes, stops at 1309. https://bugs.python.org/issue37673 opened by Loupz #37674: Is imp module deprecated or pending deprecation? https://bugs.python.org/issue37674 opened by Mariatta #37677: Seg Fault on OSX when multiprocessing https://bugs.python.org/issue37677 opened by alvis #37678: Incorrect behaviour for user@password URI pattern in urlparse https://bugs.python.org/issue37678 opened by Sean.Wang #37680: distutils appends LDFLAGS environment variable before object f https://bugs.python.org/issue37680 opened by ozars #37681: warning: ‘no_sanitize_thread’ https://bugs.python.org/issue37681 opened by shihai1991 #37683: Use importlib.resources in venv https://bugs.python.org/issue37683 opened by brett.cannon #37685: Fix equality checks for some types https://bugs.python.org/issue37685 opened by serhiy.storchaka #37688: The results from os.path.isdir(...) an Path(...).is_dir() are https://bugs.python.org/issue37688 opened by godaygo #37689: Add Path.is_relative_to() https://bugs.python.org/issue37689 opened by pitrou #37690: Simplify linking of shared libraries on the AIX OS https://bugs.python.org/issue37690 opened by ericvw Most recent 15 issues with no replies (15) ========================================== #37690: Simplify linking of shared libraries on the AIX OS https://bugs.python.org/issue37690 #37683: Use importlib.resources in venv https://bugs.python.org/issue37683 #37681: warning: ‘no_sanitize_thread’ https://bugs.python.org/issue37681 #37678: Incorrect behaviour for user@password URI pattern in urlparse https://bugs.python.org/issue37678 #37673: Tkinter won't create 5000 check boxes, stops at 1309. https://bugs.python.org/issue37673 #37669: Make mock_open return per-file content https://bugs.python.org/issue37669 #37663: Making venv activation script prompts consistent https://bugs.python.org/issue37663 #37662: Document venv.EnvBuilder.upgrade_dependencies() https://bugs.python.org/issue37662 #37654: 2to3 no-ops on embeddable distribution https://bugs.python.org/issue37654 #37651: Change of inheritance of asyncio.CancelledError needs document https://bugs.python.org/issue37651 #37650: TemporaryDirectory objects should LOCK_SH to avoid being delet https://bugs.python.org/issue37650 #37649: calculate_init fails to check that EXEC_PREFIX was decoded https://bugs.python.org/issue37649 #37648: Fix minor inconsistency in the order of == operands https://bugs.python.org/issue37648 #37640: telnetlib crash in Python3 while receiving un-printable charac https://bugs.python.org/issue37640 #37638: Having issues following build instructions https://bugs.python.org/issue37638 Most recent 15 issues waiting for review (15) ============================================= #37690: Simplify linking of shared libraries on the AIX OS https://bugs.python.org/issue37690 #37685: Fix equality checks for some types https://bugs.python.org/issue37685 #37669: Make mock_open return per-file content https://bugs.python.org/issue37669 #37664: Update bundled pip and setuptools https://bugs.python.org/issue37664 #37663: Making venv activation script prompts consistent https://bugs.python.org/issue37663 #37661: venv activation scripts erroneously check if __VENV_PROMPT__ i https://bugs.python.org/issue37661 #37650: TemporaryDirectory objects should LOCK_SH to avoid being delet https://bugs.python.org/issue37650 #37648: Fix minor inconsistency in the order of == operands https://bugs.python.org/issue37648 #37645: Replace PyEval_GetFuncName/PyEval_GetFuncDesc https://bugs.python.org/issue37645 #37642: timezone allows no offset from range (23:59, 24:00) https://bugs.python.org/issue37642 #37641: Embeddable distribution pyc filenames show build machine locat https://bugs.python.org/issue37641 #37640: telnetlib crash in Python3 while receiving un-printable charac https://bugs.python.org/issue37640 #37628: IDLE: Fix Font sample (config dialog) geometry https://bugs.python.org/issue37628 #37627: Minor improvements to IDLE's "Run Customized" https://bugs.python.org/issue37627 #37621: Line continuation of blank line emits NEWLINE https://bugs.python.org/issue37621 Top 10 most discussed issues (10) ================================= #37664: Update bundled pip and setuptools https://bugs.python.org/issue37664 14 msgs #32912: Raise non-silent warning for invalid escape sequences https://bugs.python.org/issue32912 10 msgs #37635: Using constant for whence arg in seek() https://bugs.python.org/issue37635 8 msgs #37636: Deprecate slicing and ordering operations on sys.version https://bugs.python.org/issue37636 7 msgs #30550: Document order-preserving dictionary output in json https://bugs.python.org/issue30550 6 msgs #37627: Minor improvements to IDLE's "Run Customized" https://bugs.python.org/issue37627 6 msgs #37646: eval() in a list comprehension https://bugs.python.org/issue37646 5 msgs #37688: The results from os.path.isdir(...) an Path(...).is_dir() are https://bugs.python.org/issue37688 5 msgs #36044: PROFILE_TASK for PGO build is not a good workload https://bugs.python.org/issue36044 4 msgs #37628: IDLE: Fix Font sample (config dialog) geometry https://bugs.python.org/issue37628 4 msgs Issues closed (39) ================== #12989: Consistently handle path separator in Py_GetPath on Windows https://bugs.python.org/issue12989 closed by steve.dower #17535: IDLE editor line numbers https://bugs.python.org/issue17535 closed by taleinat #29446: Improve tkinter 'import *' situation https://bugs.python.org/issue29446 closed by terry.reedy #30237: Access violation due to CancelSynchronousIo of console read https://bugs.python.org/issue30237 closed by steve.dower #30685: Multiprocessing Send to Manager Fails for Large Payload https://bugs.python.org/issue30685 closed by pitrou #31546: PyOS_InputHook is not called when waiting for input() in Windo https://bugs.python.org/issue31546 closed by steve.dower #33467: Python 3.7: profile-opt build errors because a test seems to h https://bugs.python.org/issue33467 closed by ned.deily #35476: _imp_create_dynamic_impl() does not clear error. https://bugs.python.org/issue35476 closed by eric.snow #35625: Comprehension doc doesn't mention buggy class scope behavior https://bugs.python.org/issue35625 closed by serhiy.storchaka #36279: os.wait3() leaks some uninitialized stack when no processes ex https://bugs.python.org/issue36279 closed by dw #36529: Python from WindowsStore: can't install package using "-m pip" https://bugs.python.org/issue36529 closed by steve.dower #36564: Infinite loop with short maximum line lengths in EmailPolicy https://bugs.python.org/issue36564 closed by ned.deily #37340: remove free_list for bound method objects https://bugs.python.org/issue37340 closed by inada.naoki #37399: XML text behaviour change if there are comments https://bugs.python.org/issue37399 closed by scoder #37451: Remove redudant test code in _testcapimodule.c https://bugs.python.org/issue37451 closed by xiang.zhang #37476: Adding tests for PyUnicode_AsUTF8 and PyUnicode_AsUTF8AndSize https://bugs.python.org/issue37476 closed by xiang.zhang #37502: Fix default argument handling for buffers argument in pickle.l https://bugs.python.org/issue37502 closed by pitrou #37620: str.split(sep=None, maxsplit=-1,any=False) https://bugs.python.org/issue37620 closed by rhettinger #37622: Signature of SHA256 HMAC digest not matching with the signatur https://bugs.python.org/issue37622 closed by benjamin.peterson #37623: namedtuple integration for importlib.abc.Loader https://bugs.python.org/issue37623 closed by captain-kark #37632: generator expression doesn't find subclass https://bugs.python.org/issue37632 closed by serhiy.storchaka #37639: What happened to StreamReaderProtocol? https://bugs.python.org/issue37639 closed by aymeric.augustin #37643: Except clause https://bugs.python.org/issue37643 closed by eric.smith #37644: Sphinx (Travis doc build) is blocking merging https://bugs.python.org/issue37644 closed by ned.deily #37647: Wrong lineno in traceback when formatting strings with % and m https://bugs.python.org/issue37647 closed by serhiy.storchaka #37653: make install fails https://bugs.python.org/issue37653 closed by ned.deily #37655: Set subset operator docs https://bugs.python.org/issue37655 closed by rhettinger #37656: Can't pip install because of bisect_left https://bugs.python.org/issue37656 closed by brett.cannon #37667: test.regrtest is now only running 40 tests https://bugs.python.org/issue37667 closed by gregory.p.smith #37670: Description of UserDict is misleading https://bugs.python.org/issue37670 closed by rhettinger #37671: itertools.combinations could be lazier https://bugs.python.org/issue37671 closed by rhettinger #37672: Switch Windows Store package to use pip.ini for user mode https://bugs.python.org/issue37672 closed by steve.dower #37675: 2to3 doesn't work when run from a zipfile https://bugs.python.org/issue37675 closed by benjamin.peterson #37676: cmath.phase array support https://bugs.python.org/issue37676 closed by mark.dickinson #37679: test_with_pip fails on FreeBSD 10 bot https://bugs.python.org/issue37679 closed by koobs #37682: random.sample should support iterators https://bugs.python.org/issue37682 closed by rhettinger #37684: list.extend docs inaccurate https://bugs.python.org/issue37684 closed by rhettinger #37686: No error message in joining two root directories https://bugs.python.org/issue37686 closed by eryksun #37687: Invalid regexp should rise exception https://bugs.python.org/issue37687 closed by mrabarnett

1 0

Fwd: Re: Comparing dict.values()
by David Mertz 26 Jul '19

26 Jul '19

On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin <encukou(a)gmail.com> wrote: > It's not the equality operator that errors: `==` means element-wise > comparison in Numpy. The error would come from a conversion of the array > to bool: > > >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4]) > array([ True, False, False]) > > >>> if numpy.array([ True, False, False]): > ... print('Same!') > ... > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ValueError: The truth value of an array with more than one element is > ambiguous. Use a.any() or a.all() > This is true of course. I was being overly concise, but `arr1 == arr2` does not itself (currently) raise any exception. It's only `if arr1==arr2` that does. But what NumPy does is return a "special" object that has some methods to convert it into a boolean in different ways. We COULD do that with `d1.values() == d2.values()` in principle. This "DictValuesComparison" object could have methods like `.equal_as_set()` and `.equal_as_list()`. However, that's a lot of machinery for very little gain. In contrast, a NumPy boolean array is useful for lots of purposes, and it is something we want independently to have around. Mostly it's a great way of indexing into another list of numeric elements. But it also can be used in some less common, but not uncommon ways. A hypothetical DictValuesComparison object would have nearly no use other than avoiding wrapping d.values() in list(), which we can already do fine. Sure, maybe that rare case could be made a little faster with this custom machinery, but it doesn't feel worthwhile to me. Therefore, I think the exception with guidance in the message should happen at actual equality (or inequality) comparison time, not when casting to a boolean context. Numpy currently returns False when `==` “doesn't make sense”, but > apparently has plans to change that: > > >>> numpy.array([1, 2, 3]) == numpy.array([1, 2]) > __main__:1: DeprecationWarning: elementwise comparison failed; this will > raise an error in the future. > False > > >>> numpy.array([1, 2, 3]) == numpy.array(['a', 'b']) > __main__:1: FutureWarning: elementwise comparison failed; returning > scalar instead, but in the future will perform elementwise comparison > False > This is very interesting! I did not know about this planned change. That NumPy will start raising exceptions on equality comparison adds a little bit of support for my suggestion, I think. > > So, a helpful error message including something like "Cannot compare > > dict.values directly, consider converting to sets / lists / sorted > > lists before comparing" ? > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

2 2

Python 3.7.4, Visual Studio versions for building modules from source
by Kacvinsky, Tom 23 Jul '19

23 Jul '19

HI, Not sure if this is the right place to ask, but I am trying to build pywin32-224 from source for Python 3.7.4. I think this might be the right list as this seems to be a generic problem I am having, but I want to focus on one particular module. First, I know I could get this via 'pip install', but I want to build from source to see what it takes in terms of the Windows SDK and Visual Studio versions for some other work I am doing. I am using Python 3.7.4, and I have Visual Studio 2017 15.9 (released July of this year). I see this when running 'python setup.y build': <bunch of stuff elided> error: Microsoft Visual C++ 14.1 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/ I have tried various compilers from that link (VS 2015, VS 2017, and even VS 2019), but no joy. I also have the Windows SDK 8.1 and 10 installed (pywin32 wants the 8.1 SDK) Does anyone have any ideas as to what I am doing wrong, or if there is some weird underlying issue with setuptools and/or distutils? Thanks, Tom

3 4

Replacing 4 underscores with a $ sign, idea for a PEP
by karld＠beholdingeye.com 23 Jul '19

23 Jul '19

Hello good people of Python Dev! My name is Karl and I have been a Python user since 2010, professionally since 2015. I belong to the "novice, non-technical" group of users, having got my start with programming in the 1990s using HyperTalk, possibly the easiest language of all, with the most English-like syntax. My move to Python in 2010 resulted from my move to Linux at that time. The "easy syntax, almost like pseudo code" assessment that is often repeated about Python was a big factor in choosing the language for the tools I wanted to build then. I've come a long way since those early days, but I will not forget how I got started. However... To this day, I am bothered by the convention of certain names using 4 underscores - "__class__", "__init__", "__add__", etc. I find them foreboding and difficult to type. They are also difficult to debug because in many editors there is no space between two underscores, and it may not be immediately obvious whether there is one underscore or two, or even three. I am lucky enough to have no disabilities, but I imagine there are segments of the "novice, non-technical" user group who would struggle to a greater degree than me. Given the focus of the Steering Council on improving inclusiveness and access in the Python community, I am hopeful that my message will be heard and my suggestion for improvement considered. I understand how this naming convention came about, no problems there. I do think it is a case of too much linear thinking though, progressing from the convention of one underscore to two, then to four. I believe by the time we get to four, it is time to say "Stop, is there not a better way?" Looking at the non-alphanumeric symbols in ASCII and considering their existing use in Python and other languages, the dollar sign "$" presents itself as the best option: "main.$class", "$init", "$add", etc. Of course, the old convention would remain for backward compatibility, but new code would be easier to type and debug with this new symbol. Perhaps this solution or something like it has already been considered and rejected. In that case, no big deal, this post shall vanish into oblivion with no harm done. On the other hand, if my idea is new and has potential, then I am hoping that a core dev will step up, say something encouraging, and I will write up a PEP. Thank you for reading and I look forward to your replies. Karl

7 8

The order of operands in the comparison
by Serhiy Storchaka 22 Jul '19

22 Jul '19

Usually the order of operands of the == operator does not matter. bool(a == b) should return the same as bool(b == a). Correct __eq__ should look like: def __eq__(self, other): if not know how to compare with other: return NotImplemented return the result of comparison But we work with non-perfect code written by non-perfect people. __eq__() can return False instead of NotImplemented for comparison with different type (it is not the worst case, in worst case it raises AttributeError or TypeError). So the order of operands can matter. See https://bugs.python.org/issue37555 as an example of a real world issue. The typical implementation of the __contains__ method looks like: def __contains__(self, needle): for item in self: if item == needle: # or needle == item return True return False The question is where the needle should be: at the right or at the left side of ==? In __contains__ implementations in list, tuple and general iterators (see PySequence_Contains) the needle is at the right side. But in count(), index() and remove() it is at the left side. In array it is effectively always at the left side since its __eq__ is not invoked. The question is whether we should unify implementations and always use the needle at some particular side and what this side should be.

5 6

Sphinx is blocking merges
by Terry Reedy 21 Jul '19

21 Jul '19

One of the required CI tests is a Travis doc build, even if a PR does not touch any doc file. The following failure appears to be deterministic on master and 3.8. A 3.7 backport passed. It has happened multiple times on multiple PRs today. Example: https://travis-ci.org/python/cpython/jobs/561700698 The failure is ''' Warning, treated as error: [distutils/examples:267] "`" found in "This is the description of the ``foobar`` package." ''' See https://bugs.python.org/issue37644 -- Terry Jan Reedy

2 1

Long-term deprecation policy
by Jeroen Demeyer 20 Jul '19

20 Jul '19

I have seen multiple discussions where somebody wants to deprecate a useless function but somebody else complains that we cannot do that because the function in question cannot be removed (because of backwards compatibility). See https://bugs.python.org/issue29548 for an example. We currently have a deprecation policy saying that functions deprecated in version N cannot be removed before version N+2. That's a reasonable policy but some deprecation purists insist that it MUST (instead of MAY) be removed in version N+2. Following this reasoning, we cannot deprecate something that we cannot remove. Personally, I think that this reasoning is flawed: even if we cannot *remove* a function, we can still *deprecate* it. That way, we send a message that the function shouldn't be used anymore. And it makes it easier to remove it in the (far) future: if the function was deprecated for a while, we have a valid reason to remove it. The longer it was deprecated, the less likely it is to be still used, which makes it easier to remove eventually. So I suggest to embrace such long-term deprecations, where we deprecate something without planning in advance when it will be removed. This is actually how most other open source projects that I know handle deprecations. I'd like to know the opinion of the Python core devs here. Cheers, Jeroen.

4 7