[issue36684] codecov.io code coverage has not updated since 2019-04-13

Inada Naoki added the comment: FYI, https://github.com/python/cpython/pull/7773#issuecomment-398262396 -- nosy: +inada.naoki ___ Python tracker ___

[issue36799] Typo in ctypes documentation

sehnsucht13 added the comment: I have made a PR for this. The only delay is that my CLA needs to be approved. -- nosy: +sehnsucht13 ___ Python tracker ___

[issue36799] Typo in ctypes documentation

Change by sehnsucht13 : -- keywords: +patch pull_requests: +13016 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36809] Crash for test test_importlib

Furzoom added the comment: Thread 1 (Thread 0x2b2679113e00 (LWP 22373)): #0 0x2b2679c56c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x2b2679c5a028 in __GI_abort () at abort.c:89 #2 0x004571ef in fatal_error

[issue36809] Crash for test test_importlib

New submission from Furzoom : 0:06:04 load avg: 0.73 [185/416] test_importlib Fatal Python error: Segmentation fault Current thread 0x2b774411ee40 (most recent call first): File "/home/mn/Downloads/Python-3.7.3/Lib/test/support/__init__.py", line 1543 in gc_collect File

[issue36789] Unicode HOWTO incorrectly states that UTF-8 contains no zero bytes

Change by Ezio Melotti : -- nosy: +ezio.melotti type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36807] IDLE doesn't call os.fsync()

Guido van Rossum added the comment: If/when you accept this we should also backport it as far as we can. -- ___ Python tracker ___

[issue36808] Understanding "cannot import name" exception

Eryk Sun added the comment: The issue tracker is not the right forum for questions about Python development or CPython internals. You can ask for help on the python-list mailing list. -- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed

[issue36808] Understanding "cannot import name" exception

New submission from Arthur Goldberg : I'm attempting to better understand an ImportError: cannot import name '' error by reading the cpython source. But I cannot find this error in the source. The closest I find is in cpython/Python/ceval.c, lines 5060 & 5068, but they both say:

[issue36789] Unicode HOWTO incorrectly states that UTF-8 contains no zero bytes

Josh Rosenberg added the comment: Minor bikeshed: If updating the documentation, refer to U+ as "the null character" or "NUL", not "NULL". Using "NULL" allows for confusion with NULL pointers; "the null character" (the name used in the Unicode standard) or "NUL" (the official three

[issue36781] Optimize sum() for bools

Change by Josh Rosenberg : -- nosy: +josh.r ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36793] Do not define unneeded __str__ equal to __repr__

Josh Rosenberg added the comment: I like this. Always annoying to explicitly override both __repr__ and __str__ on subclasses of stuff like int when they should be the same. Patch looks good to me; I was originally wondering why some classes were replacing: __str__ = __repr__ with:

[issue33725] Python crashes on macOS after fork with no exec

Barry A. Warsaw added the comment: On May 5, 2019, at 11:44, Davin Potts wrote: > > Victor raises an important question: should the *default* start behavior be > made consistent across platforms? Yes, I think it should. The pros of consistency and correctness outweigh the breaking

[issue36807] IDLE doesn't call os.fsync()

New submission from Guido van Rossum : This came up during today's final PyCon keynote -- IDLE was called out as one of the two editors *not* to use when live-coding on Adafruit's Circuit Playground Express (https://www.adafruit.com/product/). I *think* that the problem referred to is that

[issue36807] IDLE doesn't call os.fsync()

Change by Guido van Rossum : -- keywords: +patch pull_requests: +13015 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36806] Forbid creating of stream objects outside of asyncio

Change by Andrew Svetlov : -- keywords: +patch pull_requests: +13014 stage: -> patch review ___ Python tracker ___ ___

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Jeremy Kloth added the comment: Related to issue bpo-36319 -- nosy: +jkloth ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36806] Forbid creating of stream objects outside of asyncio

New submission from Andrew Svetlov : They were intended to be used by asyncio factories like open_connection from the very beginning but internals was leaked into asyncio top-level namespace. The idea is: 1. provide `_asyncio_internal` keyword-only parameter to leaked classes constructor

[issue36798] f-strings do not support top-level :=

Eric V. Smith added the comment: I agree with Serhiy about the need to update PEP 572 to mention this. -- keywords: +easy stage: -> needs patch ___ Python tracker ___

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Charlie Clark added the comment: winver tells me I have 1809. I'm only using Windows in a VM so I'm not that familiar with its innards. Also get the error with WinPython 3.6: Windows fatal exception: code 0xc374 Current thread 0x10c0 (most recent call first): File

[issue36798] f-strings do not support top-level :=

Serhiy Storchaka added the comment: And I think that PEP 572 should be updated too. This is a corner case that was omitted at initial consideration of the PEP. -- ___ Python tracker

[issue36800] Invalid coding error hidden on Windows

Eryk Sun added the comment: > Note I am aware the actual problem is "utf8" vs "utf-8". That shouldn't be an issue since "utf8" is an alias. The fact that your test file has LF line endings is an issue. It should be fixed in 3.7.4. See issue 20844. -- nosy: +eryksun resolution:

[issue36805] Don't close subprocess stream if it's stdin is closed

New submission from Andrew Svetlov : Closing stdin FD by child stream is a legal operation, there is no reason to close entire subprocess transport immediately. -- components: asyncio messages: 341467 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title:

[issue36798] f-strings do not support top-level :=

Eric V. Smith added the comment: Because of the backward compatibility issues, I'm not going to change the f-string parser for this. We'll just need to document the requirements for using parens if you want to use :=. This is similar to the existing documentation about lambdas and f-strings

[issue36774] f-strings: Add a !d conversion for ease of debugging

Change by Eric V. Smith : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36801] Wait for connection_lost in StreamWriter.drain

Change by Andrew Svetlov : -- versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36804] Python for Windows installer Repair option does not repair PIP

New submission from Mark Green : After installing Python for Windows using the standard installer, run "pip install --upgrade pip", which will damage pip as a result of running through pip.exe rather than python.exe. Both pip and python -m pip will now fail. Rerunning the Python Installer

[issue36804] Python for Windows installer Repair option does not repair PIP

Change by Mark Green : -- components: +Installation, Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware title: Pythonr fo -> Python for Windows installer Repair option does not repair PIP versions: +Python 3.7 ___ Python tracker

[issue36804] Pythonr fo

Change by Mark Green : -- nosy: Mark Green priority: normal severity: normal status: open title: Pythonr fo ___ Python tracker ___

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Manjusaka added the comment: copy that I will reset my locale setting to figure it out -- ___ Python tracker ___ ___

[issue36798] f-strings do not support top-level :=

Stefan Behnel added the comment: FWIW, I think it's equally reasonable to allow assignment expressions directly in f-strings, as it is to require parentheses with a reference to the invalidity of top-level expressions. That makes me lean towards adding a parse-time error message that

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Dominik Geldmacher added the comment: Enterprise 1809 and Professional 1803 (german localized) both reproduce the issue -- ___ Python tracker ___

[issue36798] f-strings do not support top-level :=

Emily Morehouse added the comment: Ah yes, that's what I meant. I was thinking about the confusion between f-strings (evaluated immediately and stored as a string) vs other versions of string formatting which are evaluated when used. I've seen the mix of the two confuse people when

[issue23041] csv needs more quoting rules

tegdev added the comment: The correct handling of None values belongs to the csv module. There is a use case to migrate a DB2 database to PostgreSQL. DB2 has a command line tool "db2 export ..." which produces csv-files. A row ['Hello', null, 'world'] is exported to "Hello,,"world". I

[issue36800] Invalid coding error hidden on Windows

Tim Golden added the comment: Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32 I can't reproduce this on Windows. And it does seem an unlikely combination of effect and cause. Do I take it that if you take out all the "logging..." lines, the

[issue36798] f-strings do not support top-level :=

Serhiy Storchaka added the comment: f-strings are defined and used at the same place, as any other expression. You can not save an f-string to a variable, as you can not save a multiplication. But you can save a string which is a result of the f-string evaluation. Perhaps you were fooled by

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Manjusaka added the comment: Hi Dominik Geldmacher May I get your system version? 1809 or 1903? I guess maybe it's microsoft error -- ___ Python tracker ___

[issue36793] Do not define unneeded __str__ equal to __repr__

Change by Gregory P. Smith : -- type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36793] Do not define unneeded __str__ equal to __repr__

Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Dominik Geldmacher added the comment: I can reproduce it on Python 3.7.3 german Windows10 enterprise Windows fatal exception: code 0xc374 Current thread 0x3bc8 (most recent call first): File "C:\Python37\lib\zipfile.py", line 1757 in writestr -- nosy: +Dominik Geldmacher

[issue34556] Add --upgrade to venv module

Change by Cooper Lees : -- keywords: +patch pull_requests: +13013 stage: -> patch review ___ Python tracker ___ ___

[issue33725] Python crashes on macOS after fork with no exec

Davin Potts added the comment: Victor raises an important question: should the *default* start behavior be made consistent across platforms? Assuming we change it on MacOS, the default start behavior on Windows and MacOS will be spawn but the default start behavior on Linux and FreeBSD

[issue36798] f-strings do not support top-level :=

Emily Morehouse added the comment: My initial reaction is that named expressions should not be valid in f-strings and should instead raise an exception, the same way that using `a := 10` does. >>> a := 10 File "", line 1 a := 10 ^ SyntaxError: invalid syntax It could be expected

[issue36803] Getting a lot of runtime misaligned address error while building python 2.7.6 with UBSAN

New submission from dibya ranjan mishra : I downloaded python 2.7.6 source and am trying to build with UBSAN flag following the instructions https://devguide.python.org/clang/. But I am getting a lot of misaligned address errors when I run make or make test command. Below is an example:

[issue33725] Python crashes on macOS after fork with no exec

Davin Potts added the comment: I believe we must change the default behavior on MacOS to use spawn instead of fork. Encouraging people to use fork by default on MacOS is encouraging them to create something that effectively will not work. Keeping fork as the default behavior when we have

[issue36798] f-strings do not support top-level :=

Change by Eric V. Smith : -- title: := breaks f-strings -> f-strings do not support top-level := ___ Python tracker ___ ___

[issue36798] := breaks f-strings

Eric V. Smith added the comment: The fact that adding := support could break existing working code does give me pause to make any change here, and does suggest that a deprecation period would be needed in order to modify the f-string expression scanning behavior. One concern I have is that

[issue36802] Revert back StreamWriter awrite/aclose but provide await writer.write() and await writer.close()

Change by Andrew Svetlov : -- keywords: +patch pull_requests: +13012 stage: -> patch review ___ Python tracker ___ ___

[issue36802] Revert back StreamWriter awrite/aclose but provide await writer.write() and await writer.close()

New submission from Andrew Svetlov : Yuri and I decided that `writer.awrite()` and `writer.aclose()` look ugly. Instead, we return awaitable object from these methods to allow both `writer.write(b'data')` and `await writer.write(b'data')` for the method. The same for `writer.close()` call.

[issue36801] Wait for connection_lost in StreamWriter.drain

Change by Andrew Svetlov : -- keywords: +patch pull_requests: +13011 stage: -> patch review ___ Python tracker ___ ___

[issue36684] codecov.io code coverage has not updated since 2019-04-13

Gordon P. Hemsley added the comment: It seems the primary cause of the problem is simply that testing crossed the boundary of maximum execution time allotted by Travis CI. I'm experimenting now with ways to speed up testing without losing granularity. However, given how long code coverage

[issue36654] Add example to tokenize.tokenize

Serhiy Storchaka added the comment: I do not think a new example is needed. The existing example already demonstrates the use of file's readline method. If you need an example for opening a file, the tokenize module documentation is not an appropriate place for this. -- nosy:

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Gordon P. Hemsley added the comment: It seems the final open question on this is whether the mismatch between the Python and C implementations is enough to bypass PendingDeprecationWarning for copy() in favor of jumping straight to DeprecationWarning. --

[issue36772] Let lru_cache be used as a decorator with no arguments

Serhiy Storchaka added the comment: To clarify, I am not opposing this feature. I had doubts because if the memory does not betray me similar propositions for lru_cache or other decorator fabrics were rejected in past. But times change. -- ___

[issue36801] Wait for connection_lost in StreamWriter.drain

New submission from Andrew Svetlov : Now `await writer.drain()` performs `await sleep(0)` if underlying transport is closing. It works well only for plain sockets. SSL transport needs more context switches to shut down the SSL connection. Drain wakes up too early to check if the transport is

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Charlie Clark added the comment: That's what we thought when we looked at it, but as I said, I couldn't reproduce it with just the `time` call or the `ZInfo` instantiation, so something odd is happening. I do have a German version of Windows as I suspect the original reporter does. You'd

[issue36798] := breaks f-strings

Larry Hastings added the comment: I'm not sure why Guido's preferences would be relevant. f-strings support expressions, := is a valid expression, f-strings therefore must support it. f-strings expressions are not top-level statements and therefore will not require parentheses around :=.

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Manjusaka added the comment: Same environment. But I still can not reproduce this exception. I guess maybe it's about the local time or timezone problem. I will find a way to figure it out -- ___ Python tracker

[issue36781] Optimize sum() for bools

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +13010 stage: -> patch review ___ Python tracker ___ ___

[issue36799] Typo in ctypes documentation

Karthikeyan Singaravelan added the comment: No problem, I have tagged it as easy and hope someone makes GitHub PR for the same. Thank you for the report. -- ___ Python tracker

[issue36799] Typo in ctypes documentation

Reuben Thomas added the comment: No, as I'm not an active Python contributor, do not aspire to be one, and don't really want to have to learn yet another contribution system to a major project just to fix a trivial typo. Sorry! -- ___ Python

[issue36799] Typo in ctypes documentation

Karthikeyan Singaravelan added the comment: Reuben, would you like to make a PR for this change? The change needs to be done in https://github.com/python/cpython/blob/master/Doc/library/ctypes.rst ➜ cpython git:(master) ✗ rg 'It is possible to defined' Doc/library/ctypes.rst 2379: It is

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Charlie Clark added the comment: Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 21:26:53) [MSC v.1916 32 bit (Intel)] on win32 -- ___ Python tracker ___

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Manjusaka added the comment: Or would you share the Exception with us ? I guess it's caused by system setting -- ___ Python tracker ___

[issue36798] := breaks f-strings

Serhiy Storchaka added the comment: Note that Guido prefers to use parentheses around the assignment operator even if the grammar does nor require this. He used this style in What's New. -- ___ Python tracker

[issue36792] zipfile.writestr causes a Python crash on Windows if the locale is set

Manjusaka added the comment: I can't reproduce this error on my system by using the same code. Could you share the system info with us? -- nosy: +Manjusaka ___ Python tracker

[issue36798] := breaks f-strings

Karthikeyan Singaravelan added the comment: There was a note on PEP 572 (https://www.python.org/dev/peps/pep-0572/#exceptional-cases) to prohibit as a top level expression and a discussion on the issue also didn't agree with it https://bugs.python.org/issue35224#msg339098 . It might cause

[issue36798] := breaks f-strings

Serhiy Storchaka added the comment: Allowing it at the top level is a breaking change. It should not be done without deprecation. And I think that it is better to use parenthesis around the assignment operator (or better do not use it in f-strings at all) that deprecate the "=" alignment.

[issue36798] := breaks f-strings

Eric V. Smith added the comment: Correct about the parens. I'm just going to fix it a the top level, without parens. There's no reason it shouldn't work, the fact that it doesn't work now is just an accident of implementation. I'll fix it by adding a special test, the same way that != has a

[issue36773] Race condition during pickle.load()

Serhiy Storchaka added the comment: It should be fixed in 3.7.3. https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-3-release-candidate-1 -- nosy: +serhiy.storchaka ___ Python tracker

[issue36791] sum() relies on C signed overflow behaviour

Serhiy Storchaka added the comment: New changeset 29500737d45cbca9604d9ce845fb2acc3f531401 by Serhiy Storchaka in branch 'master': bpo-36791: Safer detection of integer overflow in sum(). (GH-13080) https://github.com/python/cpython/commit/29500737d45cbca9604d9ce845fb2acc3f531401

[issue36798] := breaks f-strings

Serhiy Storchaka added the comment: You can use it in parenthesis: >>> f'{(x:=10)}' '10' It should be explicitly documented, that what looks like the assignment operator is not always the assignment operator in f-strings. >>> x = 10 >>> f'{x:=10}' '10' -- nosy:

[issue36798] := breaks f-strings

Eric V. Smith added the comment: f-strings are not going to take a position on what a "good" expression is, and what is and isn't allowed. If it's a Python expression that could possibly be parsed in the f-string context, f-strings will allow it. This is clearly a bug in 3.8. I'll have a PR

[issue33530] Implement Happy Eyeball in asyncio

Change by Andrew Svetlov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33530] Implement Happy Eyeball in asyncio

miss-islington added the comment: New changeset 88f07a804a0adc0b6ee87687b59d8416113c7331 by Miss Islington (bot) (twisteroid ambassador) in branch 'master': bpo-33530: Implement Happy Eyeballs in asyncio, v2 (GH-7237)

[issue36798] := breaks f-strings

SilentGhost added the comment: > The point is that := is valid expression syntax in Python 3.8, but you can't > use it in an f-string. Good? Allowing walrus operator in the f-strings will just lead to the debugging hell. -- ___ Python tracker

[issue36798] := breaks f-strings

Larry Hastings added the comment: The point is that := is valid expression syntax in Python 3.8, but you can't use it in an f-string. The fact that the error is the same in 3.6 and 3.7 is irrelevant because := was not valid syntax in those versions. --

[issue36773] Race condition during pickle.load()

papad added the comment: In what version should this be fixed? I see https://bugs.python.org/issue34572 says the fix is in version 3.7, while I'm experiencing this on python 3.7.3, which version should I check? -- ___ Python tracker

[issue36798] := breaks f-strings

SilentGhost added the comment: This doesn't seem at all related to walrus operator, I can reproduce this error on 3.6.7 and 3.7.3, given that format call returns exactly the same error, it seems like '=' is simply not a valid alignment for strings. I'm not saying that walrus operator did

[issue36800] Invalid coding error hidden on Windows

Change by SilentGhost : -- type: compile error -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34915] LWPCookieJar.save() creates *.lwp file in 644 mode

Karthikeyan Singaravelan added the comment: Martin, any thoughts on this change? -- nosy: +martin.panter ___ Python tracker ___

[issue36800] Invalid coding error hidden on Windows

Yuval Greenfield added the comment: Note I am aware the actual problem is "utf8" vs "utf-8". But for some reason on Windows the exception does not reflect that. -- ___ Python tracker

[issue36800] Invalid coding error hidden on Windows

New submission from Yuval Greenfield : These lines fail on Windows in a surprising way: # -*- coding: utf8 -*- import threading print("threading %s" % threading) Normally they would throw this: ```File

[issue36799] Typo in ctypes documentation

New submission from Reuben Thomas : "It is possible to defined" → "It is possible to define" -- assignee: docs@python components: Documentation messages: 341419 nosy: docs@python, rrt priority: normal severity: normal status: open title: Typo in ctypes documentation versions: Python 3.8