[issue38319] shutil.copyfile(): os.sendfile() fails with OverflowError on 32-bit system

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Looks like it worked:
https://buildbot.python.org/all/#/builders/176/builds/1383

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38319] shutil.copyfile(): os.sendfile() fails with OverflowError on 32-bit system

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[Guido van Rossum]

Guido van Rossum  added the comment:

Even if this not desirable for the source code, it still makes sense to add the 
types to the docs, at least when they are simple and compact. The proposed 
notation from PEP 604 ('|' for unions) might help with compactness. Many docs 
are unnecessarily vague about types.

--
assignee: gvanrossum -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: docs@python -> gvanrossum
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I believe there was an explicit decision not to do this.  For the time being, 
optional typing is still optional.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38333] add type signatures to library function docs

[paul rubin]

New submission from paul rubin :

It would be nice if the library reference manual had type signatures for all 
the stdlib functions at some point.  It might be possible to extract a lot of 
them automatically from typeshed and semi-automatically paste them into the doc 
files.  It might also be ok to do this gradually.  I can help with this but 
wouldn't want to take on the entire task.

--
assignee: docs@python
components: Documentation
messages: 353634
nosy: docs@python, phr
priority: normal
severity: normal
status: open
title: add type signatures to library function docs
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38319] shutil.copyfile(): os.sendfile() fails with OverflowError on 32-bit system

[miss-islington]

Change by miss-islington :


--
pull_requests: +16093
pull_request: https://github.com/python/cpython/pull/16506

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38319] shutil.copyfile(): os.sendfile() fails with OverflowError on 32-bit system

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:


New changeset 94e165096fd65e8237e60de570fb609604ab94c9 by Giampaolo Rodola in 
branch 'master':
bpo-38319: Fix shutil._fastcopy_sendfile(): set sendfile() max block size 
(GH-16491)
https://github.com/python/cpython/commit/94e165096fd65e8237e60de570fb609604ab94c9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38329] macOS python.org installers only add or modify framework Versions/Current symlink for Python 2.x installs, not Python 3.x

[Ned Deily]

Ned Deily  added the comment:

Thanks for the reminder.  Unfortunately, the macOS installer is working as 
designed.  As discussed at length in Issue18117 (and elsewhere), building using 
the -framework Python, either directly in compiler calls or indirectly through 
Xcode is problematic because python.org Python installers install all versions, 
2.x and 3.x, into the same framework location, 
/Library/Frameworks/Python.framework.  Since it was common especially in the 
early days of Python 3 to install both Python 2 and Python 3, the decision was 
made to only have Python 2.x installs add or modify the Current symlink.  As 
also noted, it was probably a mistake back then to not install Python 3.x 
versions to a differently-names framework so you can be sure whether you are 
attempting to link with Python 2 or Python 3 but that ship has sailed.  However 
now that Python 2 is about to enter end-of-life, we should reconsider that 
behavior.

In the meantime, there should be a simple workaround: just create the symlink 
yourself after installing a new Python 3.x version.  So something like:

sudo sh
umask 022
cd /Library/Frameworks/Python.framework/Versions
rm -f Current
ln -s 3.7 Current
exit

--
assignee:  -> ned.deily
title: Top level symlinks are broken in the Python 3.7.4 framework for macOS. 
-> macOS python.org installers only add or modify framework Versions/Current 
symlink for Python 2.x installs, not Python 3.x
versions: +Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I worked some on trying to create a unit test this evening.  Attached is my 
best result so far (gc_weakref_bug_demo.py).  It requires that you enable the 
'xx' module so we have a container object without tp_traverse.  We should 
probably add one to _testcapi for the real unit test so we have it.

I can make the weakref callback run from within delete_garbage().  I haven't 
been able to make tp_clear for the function execute before the callback and I 
think that is needed to replicate the crash in this bug report.

--
Added file: https://bugs.python.org/file48633/gc_weakref_bug_demo.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32689] shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory

[Guido van Rossum]

Guido van Rossum  added the comment:

3.9 only!

--
nosy: +gvanrossum
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38332] invalid content-transfer-encoding in encoded-word causes KeyError

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Hello,

I am not a email expert, but according to RFC 1342 the enconding can be either 
"B" or "Q". So, I think is reasonable that when a not correct enconding is set, 
should be raise an exception


I think that we can improve the message raising a more specific Exception

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32689] shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory

[miss-islington]

miss-islington  added the comment:


New changeset cf57cabef82c4689ce9796bb1fcdb125fa05efcb by Miss Islington (bot) 
(Maxwell A McKinnon) in branch 'master':
bpo-32689: Updates shutil.move to allow for Path objects to be used as source 
arg (GH-15326)
https://github.com/python/cpython/commit/cf57cabef82c4689ce9796bb1fcdb125fa05efcb


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38325] [Windows] test_winconsoleio failures

[Eryk Sun]

Eryk Sun  added the comment:

Does test_partial_reads fail for you when run separately? If so, it's for a 
different reason. Otherwise, there may have been text left in the input buffer 
from test_input that led to the failure, which is a separate problem that needs 
to be addressed via FlushConsoleInputBuffer.

> Until a fix is found, can we mark the tests as "known to fail" on a 
> specific Windows version? (So test_winconsoleio doesn't fail anymore.)

Maybe also split out the non-BMP case in test_input to a separate 
test_non_bmp_input case that's skipped or expected to fail if 
sys.getwindowsversion() >= (10, 0, 18362).

As to a fix, there's nothing we can do in Python. An issue can be opened at 
github.com/microsoft/terminal. I wouldn't expect ReadConsoleOutputW to be 
fixed. But they should be able to fix ReadConsoleW and 
ReadConsoleOutputCharacterW.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[Ma Lin]

Ma Lin  added the comment:

Other warnings:

c:\vstinner\python\master\objects\longobject.c(420): warning C4244: 'function': 
conversion from 'unsigned __int64' to 'sdigit', possible loss of data

c:\vstinner\python\master\objects\longobject.c(428): warning C4267: 'function': 
conversion from 'size_t' to 'sdigit', possible loss of data
-
These warnings only appear in master branch, I will fix it at some point.
(https://bugs.python.org/issue35696#msg352903)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38332] invalid content-transfer-encoding in encoded-word causes KeyError

[Emmanuel Arias]

Change by Emmanuel Arias :


--
nosy: +eamanu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[Ma Lin]

Ma Lin  added the comment:

On my Windows, some non-ASCII characters cause this warning:

d:\dev\cpython\modules\expat\xmltok.c : warning C4819: 
The file contains a character that cannot be represented in
the current code page (936). Save the file in Unicode format
to prevent data loss.

This patch fixes the warnings, it's applicable to master/3.8 branches.
https://github.com/animalize/cpython/commit/daced7575ec70ef1f888c6854760e230cda5ea64

Maybe this trivial problem is not worth a new commit, it can be fixed along 
with other warnings.

--
nosy: +Ma Lin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38332] invalid content-transfer-encoding in encoded-word causes KeyError

[Andrei Troie]

New submission from Andrei Troie :

The following will cause a KeyError on email.message.get()

import email
import email.policy

text = "Subject: =?us-ascii?X?somevalue?="
eml = email.message_from_string(text, policy=email.policy.default)
eml.get('Subject')

This is caused by the fact that the code in _encoded_words.py assumes the 
content-transfer-encoding of an encoded-word is always 'q' or 'b' (after 
lowercasing): 
https://github.com/python/cpython/blob/aca8c406ada3bb547765b262bed3ac0cc6be8dd3/Lib/email/_encoded_words.py#L178

I realise it's probably a silly edge case and I haven't (yet) encountered 
something like this in the wild, but it does seem contrary to the spirit of the 
email library to raise an exception like this that can propagate all the way to 
email.message.get().

--
components: email
messages: 353624
nosy: aft90, barry, r.david.murray
priority: normal
severity: normal
status: open
title: invalid content-transfer-encoding in encoded-word causes KeyError
type: crash
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Change by Neil Schemenauer :


--
nosy: +benjamin.peterson, larry, ned.deily
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I created GH-16502.  I'm not exactly sure of the process of making a revert on 
a branch like '3.8' so hopefully it is correct.  The code change is exactly 
what has been reverted in 3.8.  The net effect will be as if the revert was 
never done.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37725] "make clean" should remove PGO task data

[Neil Schemenauer]

Change by Neil Schemenauer :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Change by Neil Schemenauer :


--
pull_requests: +16092
pull_request: https://github.com/python/cpython/pull/16502

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38331] Exec not recognizing global variables inside function

[Huyston]

New submission from Huyston :

This seems like a bug for me, forgive me if its not.

Consider the following script:

def func():
print(var)

my_globals = {'func':func,'var':14}
exec("print(var);func()",my_globals,my_globals)

This is the output:

14
Traceback (most recent call last):
  File "bug.py", line 5, in 
exec("print(var);func()",my_globals,my_globals)
  File "", line 1, in 
  File "bug.py", line 2, in func
print(var)
NameError: name 'var' is not defined

The first line gives the expected result (14). However the second line throws 
the NameError.

If 'func' is defined inside the exec argument string, then it prints 14 and 14, 
which is the expected result (for me at least).

Ex:

def func():
print(var)

my_globals = {'func':func,'var':14}
exec("def func():\nprint(var)\nprint(var);func()",my_globals,my_globals)

Result:
14
14

So is this really a bug or is this the expected behavior somehow?

--
components: Interpreter Core
messages: 353622
nosy: Huyston
priority: normal
severity: normal
status: open
title: Exec not recognizing global variables inside function
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38330] httplib specifies content-length when transfer-encoding present

[apmatthews]

Change by apmatthews :


--
keywords: +patch
pull_requests: +16090
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16501

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38304] PEP 587 implementation is not ABI forward compatible

[STINNER Victor]

STINNER Victor  added the comment:

I reopen the issue since there seems to be disagreement about the whole feature 
(provide a stable ABI for embedded Python): see bpo-38326.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[STINNER Victor]

STINNER Victor  added the comment:

> Binary compatibility of an embedding-only struct is totally unnecessary, as 
> posted on the thread.

Well, I'm fine with removing PyConfig.struct_size right now. I wrote two PRs to 
remove it:

* PR 16500 (code)
* https://github.com/python/peps/pull/1185 (PEP)

We can still add a similar "version" ("struct_size" or whatever) field later 
*if* we want to provide a stable ABI for embedded Python.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[Steve Dower]

Steve Dower  added the comment:

Either way, the paths in the latest tests [1] seem to be fine, and they all 
passed, so I don't think this is a release blocker anymore.

Thanks, Victor!

[1]: 
https://dev.azure.com/Python/cpython/_build/results?buildId=52024=logs=c8a71634-e5ec-54a0-3958-760f4148b765

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[Steve Dower]

Steve Dower  added the comment:

> I checked why sys.executable is not normalized in the the "appx build". 
> PC\python_uwp.cpp calls set_process_name() which sets PyConfig.executable and 
> the path is not normalized. If PyConfig.executable is set explicitly, the 
> path is left unchanged: PyConfig has the highest priority.

Ah, that would explain it, certainly. I don't know why the dots are ever added 
though.

This test also has the weird oddity that it isn't running as an actual app, so 
a different initialization path is taken. In this case, it should be using the 
final name as reported by the operating system, so the extra dots are basically 
unexplainable. I'll try a couple of experiments and see if I can figure it out.

> the UI is kind of "hidden" in GitHub

Yeah, but I look at it periodically (the "Commits" view is a convenient way to 
see recent CI and buildbot status). It's considerably simpler for me than 
finding out it's broken in an RC :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38304] PEP 587 implementation is not ABI forward compatible

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16089
pull_request: https://github.com/python/cpython/pull/16500

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38330] httplib specifies content-length when transfer-encoding present

[apmatthews]

New submission from apmatthews :

RFC 7230 3.3.2 states "A sender MUST NOT send a Content-Length header field in 
any message that contains a Transfer-Encoding header field."

When trying to perform a chunked request:

import httplib
http = httplib.HTTPSConnection('google.com')
http.request("POST", '/', None, {'Content-Type': 'text/plain',
 'Transfer-Encoding': 'chunked'})

Resulting headers include:

Content-Length: 0
Transfer-Encoding: chunked

The receiving server should ignore the Content-Length in this case but some 
versions of IIS don't and consequently fail to accept the chunks that follow.

--
components: Library (Lib)
messages: 353617
nosy: apmatthews
priority: normal
severity: normal
status: open
title: httplib specifies content-length when transfer-encoding present
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38325] [Windows] test_winconsoleio failures

[STINNER Victor]

STINNER Victor  added the comment:

Until a fix is found, can we mark the tests as "known to fail" on a specific 
Windows version? (So test_winconsoleio doesn't fail anymore.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[STINNER Victor]

STINNER Victor  added the comment:

> Adding in the appx _layout_ test (it's the whole test suite in an "installed" 
> layout) was easier to do in CI than creating a buildbot config, so I threw it 
> in as a test and then left it on. It's certainly not been failing this whole 
> time.

I'm fine with keeping it here. I don't pay much attention to it, since I don't 
get an email when a Azure Pipelones job fails, and the UI is kind of "hidden" 
in GitHub (not as visible as CI results on a PR).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[STINNER Victor]

STINNER Victor  added the comment:

> The bug was probably exposed due to a change in path initialization (there's 
> been a few changes here recently ;) ) that stopped normalising prefix. You 
> can see that sys.executable in your dumped path has additional "." in the 
> path, and that's never been the case before - they're always cleaned up 
> earlier than that.

Yeah, I had to modify a lot of "path config" code to fix many bugs (regressions 
compared to Python 3.7). I also added the first tests on the "path 
configuration" in test_embed.

I checked why sys.executable is not normalized in the the "appx build". 
PC\python_uwp.cpp calls set_process_name() which sets PyConfig.executable and 
the path is not normalized. If PyConfig.executable is set explicitly, the path 
is left unchanged: PyConfig has the highest priority.

Should the executable path be normalized in this case?

--

I looked at Python 3.6 (the version before I started to rework the Python 
initialization). But there is no python_uwp.cpp in this version.

In Python 3.7, python_uwp.cpp calls set_process_name() which calls 
_Py_SetProgramFullPath(). But config_init_path_config() seems to ignore the 
_Py_SetProgramFullPath() call in Python 3.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38325] [Windows] test_winconsoleio failures

[Eryk Sun]

Eryk Sun  added the comment:

Apparently handling non-BMP codes is broken in recent builds of the new console 
in Windows 10. I see this problem in build 18362 as well. It seems there have 
been updates that have changed the naive way the console used to handle 
surrogate codes as just regular UCS-2 codes, and this has disrupted the UTF-16 
wide-character API in several ways. This is probably related to the new support 
for virtual-terminal emulation and pseudoconsoles, since supporting a UTF-8 
stream interface has required significant redesign of the console backend.

Low-level ReadConsoleInputW and WriteConsoleInputW still work, but high-level 
ReadConsoleW now fails if it encounters a non-BMP surrogate pair, i.e. at least 
two key-event records with the non-BMP character encoded as a UTF-16 surrogate 
pair. It can be more than two input records depending on the source of input -- 
WriteConsoleInputW vs pasting from the clipboard -- in terms of KeyDown/KeyUp 
events or an Alt+Numpad sequence.

There are issues with reading from screen buffers as well. WriteConsoleW can 
still successfully write non-BMP characters, and these can be copied from the 
console fine. But ReadConsoleOutputCharacterW can no longer read them. This 
used to work, but now it 'succeeds with 0 characters read if the screen-buffer 
region contains a non-BMP character. I checked the lower-level 
ReadConsoleOutputW function, and it's behaving differently now. It used to read 
a non-BMP character as two CHAR_INFO records containing the surrogate pair 
codes, but now it reads a non-BMP character as a single CHAR_INFO record 
containing a replacement character U+FFFD. 

I suppose we need to skip testing non-BMP and surrogate codes if the Windows 
version is (10, 0, 18362) and above.

Also, _testconsole needs to support FlushConsoleInputBuffer. Every test that 
calls _testconsole.write_input should be isolated with a try/finally that 
flushes the input buffer at the end. For example:

write_input(raw, 'spam')
try:
actual = input()
finally:
flush_input(raw)

If reading fails, 'spam' will be flushed from the input buffer.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38329] Top level symlinks are broken in the Python 3.7.4 framework for macOS.

[Kevin Packard]

New submission from Kevin Packard :

The macOS installer for Python 3.7.4 places "Python.framework" into 
/Library/Frameworks/  However, the top-level symlinks inside the framework are 
broken for "Headers" and "Resources". Because of this, the framework can not be 
imported into an Xcode project.

--
components: macOS
messages: 353612
nosy: KevinPackard, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Top level symlinks are broken in the Python 3.7.4 framework for macOS.
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

STINNER Victor  added the comment:


New changeset aca8c406ada3bb547765b262bed3ac0cc6be8dd3 by Victor Stinner in 
branch 'master':
bpo-38321: Fix _testcapimodule.c warning (GH-16494)
https://github.com/python/cpython/commit/aca8c406ada3bb547765b262bed3ac0cc6be8dd3


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Łukasz Langa]

Łukasz Langa  added the comment:

If either of you resurrects tp_clear in functions in the next 12 hours or so, 
I'll merge it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38324] [Windows] test_locale and test__locale failures on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> Also, since these seem to be on your own machine, I'm guessing your locale is 
> not en-US?

Oh, the behavior of setlocale() depends on my system locale? Yeah, my system is 
configured in French, sorry I don't recall the locale name.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37945] [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813()

[STINNER Victor]

Change by STINNER Victor :


--
title: test_locale failing -> [Windows] locale.getdefaultlocale() issues on 
Windows: test_locale.test_getsetlocale_issue1813()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> Is introducing tp_clear on functions a thing that has ABI consequences? In 
> other words, if we take our time on this, would it land in 3.8.1 or 3.9.0?

I think it should not have ABI consequences.  However, I see the addition of 
tp_clear as a new feature.  Leaking memory due to reference cycles is bad 
behavior but not a bug to be fixed in a maintenance release.  Unless we require 
full GC protocol on every container object, we can't promise not to leak.

Inaka's change to add func tp_clear has been in all the 3.8.0 pre-releases (I 
think).  So, it should be pretty well exercised by now (at least, as well as 
the per-releases are tested).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Łukasz, all type objects have tp_clear slots, and always did.  The patch in 
question put something useful in the function object's tp_clear slot instead of 
leaving it NULL.  No interface, as such, changes either way.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Łukasz Langa]

Łukasz Langa  added the comment:

Now we only need a volunteer to prepare a PR to revert the revert... :>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Yes, it's better to have tp_clear than not for a variety of reasons (including 
setting examples of best practice).

Best I can tell, the patch for BPO-33418 was reverted _only_ to worm around the 
crash in _this_ report.  That's no longer needed.  Or, if it is, we've missed 
something fundamental in the fix for this bug.  In which case, reverting the 
other patch is the only clear way to find that out quickly.  I favor getting it 
right.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Łukasz Langa]

Łukasz Langa  added the comment:

Is introducing tp_clear on functions a thing that has ABI consequences? In 
other words, if we take our time on this, would it land in 3.8.1 or 3.9.0?

I'm kind of nervous about the rate of change in the past 48 hours.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> Would [func tp_clear] help with memory usage in functions or was BPO-33418 
> addressed in another way since?

Having a tp_clear for all container objects that can be involved in reference 
cycles will help the GC free memory.  BPO-33418 may be contrived but it does 
demonstrate a problem that could happen in "real" code.  If you have a 
long-running program, tracking down a memory leak due to reference cycles can 
be fiendishly difficult.  That's why Tim originally wrote cyclops and why I 
started working on cyclic GC in the first place.

It is a "quality of implementation" issue.  It is not wrong for CPython to leak 
memory if you create reference cycles (not all types are required to implement 
the GC protocol).  I expect users would be surprised if it happens since the 
majority have never used Python without the cyclic GC.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

It's unclear to me whether BPO-33418 was a bug or a contrived annoyance :-)

If someone believes it was worth addressing, then what it did is the only way 
to fix it, so should be restored now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Łukasz Langa]

Łukasz Langa  added the comment:

> If that PR is applied, I think we should also restore tp_clear for functions 
> (revert GH-15826).

If that's safe and easy, let's go for it. Would it help with memory usage in 
functions or was BPO-33418 addressed in another way since?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[miss-islington]

Change by miss-islington :


--
pull_requests: +16088
pull_request: https://github.com/python/cpython/pull/16499

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

FWIW, I agree with Neil in all respects about the release:  his patch is the 
best approach, plugs segfaulting holes that have been there for many years, and 
the earlier patches aren't needed anymore.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38328] Speed up the creation time of constant list literals.

[Brandt Bucher]

Change by Brandt Bucher :


--
keywords: +patch
pull_requests: +16087
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16498

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33325] Optimize sequences of constants in the compiler

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +16086
pull_request: https://github.com/python/cpython/pull/16498

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38328] Speed up the creation time of constant list literals.

[Brandt Bucher]

New submission from Brandt Bucher :

The attached PR contains a small change to the peephole optimizer that converts 
sequences of:

LOAD_CONST(a), LOAD_CONST(b), ..., BUILD_LIST(n)

to

LOAD_CONST((a, b, ...)), BUILD_LIST_UNPACK(1)

The improvement quickly becomes significant for lists larger than a few items 
(elements vs speedup):

 5:  ~5%
10: ~20%
15: ~25%
20: ~30%
25: ~35%
30: ~45%
35: ~50%

This can be tested on any version of Python by comparing the performance of 
"[0, 1, 2, ...]" vs "[*(0, 1, 2, ...)]". The common cases of empty and 
single-element lists are not affected by this change.

This is related to bpo-33325, but that was an invasive change for all 
collection literals that had an unknown affect on performance. I've limited 
this one to lists and kept it to a few lines in the peephole optimizer.

--
components: Interpreter Core
messages: 353599
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Speed up the creation time of constant list literals.
type: performance
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Neil, my brief msg 10 minutes before yours suggested the same thing (just clear 
the weakref), so it must be right ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

Oops, I linked to wrong PR, my proposed fix is GH-16495.  It is the same as 
what Tim suggests in his last comment.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38302] __rpow__ not reached when __ipow__ returns NotImplemented

[hongweipeng]

hongweipeng  added the comment:

Oh, I see. Thank you.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> Why setting it back to release blocker? As far as I recall, this issue is not
> a Python 3.8 regression. The regression which triggered this old and existing
> bug has been fixed, see previous comments.

I leave it up to our glorious release manager to decide how to proceed.  IMHO,
GH-15826 (revert the addition of tp_clear for functions) and GH-15641 (Avoid
closure in weakref.WeakValueDictionary) are two cases of not fixing the real
bug, just hiding symptoms.  However, since this bug has existed for decades, I
wouldn't fault him for taking the conservative approach and not trying to
address the real bug in 3.8.

I've created a new PR (GH-16083) that I think is the correct fix.  If that PR
is applied, I think we should also restore tp_clear for functions (revert
GH-15826).  GH-15641 can probably stay.


Tim on my rough patch:
> It's semantically correct since we never wanted to execute a callback from a
> trash weakref to begin with

Thanks for your help Tim.  I think my PR is a cleaner fix that does essentially
the same thing.  Just call _PyWeakref_ClearRef() on weakrefs that are in
'unreachable'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38297] Imports at top of module is often not used

[Brett Cannon]

Brett Cannon  added the comment:

So it's a bit misleading to use the stdlib as a guideline because there are 
reasons we do this in certain spots. E.g. the os module purposefully does 
function-level imports to make startup cheaper. importlib does this to minimize 
how many modules need to be frozen into the interpreter.

But regardless of why, the PEP 8 guidance is still accurate as well as 
wholesale changes aren't allowed for stylistic reasons ("A Foolish Consistency 
is the Hobgoblin of Little Minds"). So while I appreciate the analysis and find 
it interesting, I'm closing this issue as there's nothing specific to do here.

--
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38303] Make audioop PEP-384 compatible

[Tyler Kieft]

Change by Tyler Kieft :


--
keywords: +patch
pull_requests: +16085
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16497

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Neil, how about this alternative:  leave the weakref implementation alone.  If 
we find a trash weakref, simply clear it instead.  That would prevent callbacks 
too, & would also prevent the weakref from being used to retrieve its 
possibly-trash-too referent.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[Nick Coghlan]

Change by Nick Coghlan :


--
keywords: +patch
pull_requests: +16084
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/16496

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Change by Neil Schemenauer :


--
pull_requests: +16083
pull_request: https://github.com/python/cpython/pull/16495

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

> Would the attached rough patch (gc_disable_wr_callback.txt)
> be a possible fix?  When we find W inside handle_weakrefs(),
> we mark it as trash and will not execute the callback.

It's semantically correct since we never wanted to execute a callback from a 
trash weakref to begin with.  The nature of the error violated that intent:  
the callback from a trash weakref occurs outside gcmodule, where it has no idea 
that the weakref is trash.  After your patch, it would know.

How effective is it?  Well, failure modes "like this" ;-)

If a callback function is trash, delete_garbage will eventually clear it.  But 
if the function is trash the weakref containing it must also be trash (if it 
weren't trash, neither would be the reachable-from-it callback function).  Then 
since the containing weakref is trash, your patch will find it and prevent the 
callback.

So this "should" fix the original problem, even if tp_clear were restored for 
function objects (which it probably should be).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37398] contextlib.ContextDecorator decorating async functions

[Krzysztof Wróblewski]

Change by Krzysztof Wróblewski :


--
nosy: +Krzysztof Wróblewski

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38324] [Windows] test_locale and test__locale failures on Windows

[Tim Golden]

Tim Golden  added the comment:

This is the existing issue https://bugs.python.org/issue37945 which I haven't 
had time to progress. Please feel free to follow up

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset c9a413ede47171a224c72dd34122005170caaad4 by Vinay Sajip (Victor 
Stinner) in branch 'master':
bpo-38321: Fix PyCStructUnionType_update_stgdict() warning (GH-16492)
https://github.com/python/cpython/commit/c9a413ede47171a224c72dd34122005170caaad4


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22273] abort when passing certain structs by value using ctypes

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset c9a413ede47171a224c72dd34122005170caaad4 by Vinay Sajip (Victor 
Stinner) in branch 'master':
bpo-38321: Fix PyCStructUnionType_update_stgdict() warning (GH-16492)
https://github.com/python/cpython/commit/c9a413ede47171a224c72dd34122005170caaad4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38242] Revert the new asyncio Streams API

[Bruce Merry]

Change by Bruce Merry :


--
nosy: +bmerry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[Łukasz Langa]

Change by Łukasz Langa :


--
versions: +Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38327] Creating set with empty string returns empty set

[Emil Bode]

Emil Bode  added the comment:

You're right, I tested with set('a'), which gave me a set of size one, but 
generalized it here to 'somestring'.
Maybe I'm just too loose with using set, instead of {}

Sorry to bother you

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38327] Creating set with empty string returns empty set

[Ammar Askar]

Ammar Askar  added the comment:

I think the key thing you're missing here is that the set() constructor can 
take any arbitrary iterable 
(https://docs.python.org/3/library/functions.html#func-set). It simply goes 
over all the elements inside and adds them all to the set. This is no different 
than the following for example:

>>> for char in 'somestring': 
...   print(char) 
...   
s 
o 
m 
e 
s 
t 
r 
i 
n 
g 
>>>
>>> for char in '':
...   print(char)
...
>>>

When you iterate over a string, it simply goes over each character inside it.

> While set('somestring') gives me a set of size one

This should not be the case, set('something') should be giving you a set of 
size 9. Each element in the set being a character from the string 'somestring'

>>> set('somestring')
{'t', 's', 'e', 'n', 'g', 'o', 'r', 'i', 'm'}
>>> len(set('somestring'))
9

> set('') gives me an empty set (of size zero)

Now hopefully it should be obvious why this happens, the set() constructor goes 
over each character in the string. Which in this case, there aren't any because 
the string is completely empty. This leads to an empty set. This is no 
different than doing set([])

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38327] Creating set with empty string returns empty set

[Emil Bode]

Emil Bode  added the comment:

Some details about my setup:
Python 3.7.1,
Spyder 3.3.2
IPython 7.2.0
under Windows 10 64-bit

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38327] Creating set with empty string returns empty set

[Emil Bode]

New submission from Emil Bode :

Initializing/creating a new set with an empty string via the set-command 
returns an empty set instead of set with the empty string.

As in:
While set('somestring') gives me a set of size one, 
set('') gives me an empty set (of size zero), just as set() would do

It is possible to create a set with an empty string, as the command {''} and 
set(['']) work just as expected

--
messages: 353585
nosy: EmilBode
priority: normal
severity: normal
status: open
title: Creating set with empty string returns empty set
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38324] [Windows] test_locale and test__locale failures on Windows

[Steve Dower]

Steve Dower  added the comment:

This is a known issue (forgetting the number right now) - Linux-style locales 
don't work on Windows, and so there's a normalization function that has to be 
completely rewritten.

Also, since these seem to be on your own machine, I'm guessing your locale is 
not en-US? Please make sure you provide enough information for others to 
reproduce these - if they were occurring all the time, we wouldn't have got 
this far, so you've obviously got something configured differently.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35360] Update SQLite to 3.28 in Windows and macOS installer builds

[Steve Dower]

Steve Dower  added the comment:

Please file a new issue

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[Steve Dower]

Steve Dower  added the comment:

The bug was probably exposed due to a change in path initialization (there's 
been a few changes here recently ;) ) that stopped normalising prefix. You can 
see that sys.executable in your dumped path has additional "." in the path, and 
that's never been the case before - they're always cleaned up earlier than that.

Adding in the appx _layout_ test (it's the whole test suite in an "installed" 
layout) was easier to do in CI than creating a buildbot config, so I threw it 
in as a test and then left it on. It's certainly not been failing this whole 
time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[Steve Dower]

Steve Dower  added the comment:

(Continuing from the email thread, so read that for context if you haven't)

Binary compatibility of an embedding-only struct is totally unnecessary, as 
posted on the thread. There's no feasible way to embed cross-Python versions on 
any platform, so we should just officially say that embedding applications are 
only compatible with the version it was built to target.

(Aside: this is why I keep talking about "embeddable distros", as these help 
solve the problem of trying to embed an arbitrary system Python.)

AFAICT, this should remove the need for any version or size checks at all.

--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[STINNER Victor]

STINNER Victor  added the comment:

> 2019-09-30 14:41:36   lukasz.langaset priority: release blocker

Why setting it back to release blocker? As far as I recall, this issue is not a 
Python 3.8 regression. The regression which triggered this old and existing bug 
has been fixed, see previous comments.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Łukasz Langa]

Change by Łukasz Langa :


--
priority:  -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38248] inconsistency in asyncio.Task between cancellation while running vs. cancellation immediately after it finishes

[STINNER Victor]

STINNER Victor  added the comment:


New changeset efe74b6369a8d08f27c69703fcc1686966e51068 by Victor Stinner in 
branch 'master':
bpo-38321: Fix _asynciomodule.c compiler warning (GH-16493)
https://github.com/python/cpython/commit/efe74b6369a8d08f27c69703fcc1686966e51068


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

STINNER Victor  added the comment:


New changeset efe74b6369a8d08f27c69703fcc1686966e51068 by Victor Stinner in 
branch 'master':
bpo-38321: Fix _asynciomodule.c compiler warning (GH-16493)
https://github.com/python/cpython/commit/efe74b6369a8d08f27c69703fcc1686966e51068


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[Nick Coghlan]

Nick Coghlan  added the comment:

(I'm currently working a PR for this that Victor can review)

--
assignee:  -> ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38315] Provide defaultdict variant that passes key to default_factory

[Mark Amery]

Mark Amery  added the comment:

I'm aware of __missing__. However, I don't think its existence is by itself a 
knockdown argument against doing this. __missing__ also fulfils the need 
satisfied by defaultdict, yet Python still has both - and the latter is almost 
always more convenient to use when it's possible to do so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16082
pull_request: https://github.com/python/cpython/pull/16494

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38248] inconsistency in asyncio.Task between cancellation while running vs. cancellation immediately after it finishes

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16081
pull_request: https://github.com/python/cpython/pull/16493

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16080
pull_request: https://github.com/python/cpython/pull/16493

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22273] abort when passing certain structs by value using ctypes

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16079
pull_request: https://github.com/python/cpython/pull/16492

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +16078
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16492

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

STINNER Victor  added the comment:

And more:

c:\vstinner\python\master\modules\_testcapimodule.c(6409): warning C4146: unary 
minus operator applied to unsigned type, result still unsigned

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38321] Compiler warnings when building Python 3.8

[STINNER Victor]

STINNER Victor  added the comment:

Other warnings:

c:\vstinner\python\master\objects\longobject.c(420): warning C4244: 'function': 
conversion from 'unsigned __int64' to 'sdigit', possible loss of data

c:\vstinner\python\master\objects\longobject.c(428): warning C4267: 'function': 
conversion from 'size_t' to 'sdigit', possible loss of data

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38326] Concerns with the last minute changes to the PEP 587 API

[Nick Coghlan]

New submission from Nick Coghlan :

(Nosy list is RM, PEP 587 BDFL-Delegate, PEP 587 author)

Filing as a release blocker, given that I don't think we should ship rc1 until 
consensus has been reached on the last minute changes to the PEP 587 
configuration API.

Thread at 
https://mail.python.org/archives/list/python-...@python.org/thread/C7Z2NA2DTM3DLOZCFQAK5A2WFYO3PHHX/

--
messages: 353573
nosy: lukasz.langa, ncoghlan, twouters, vstinner
priority: release blocker
severity: normal
stage: commit review
status: open
title: Concerns with the last minute changes to the PEP 587 API
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38319] shutil.copyfile(): os.sendfile() fails with OverflowError on 32-bit system

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
keywords: +patch
pull_requests: +16077
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16491

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[STINNER Victor]

STINNER Victor  added the comment:

Facts:

* appx tests are not run on buildbots
* appx tests are not run in pre-commit CI of pull requests
* appx tests seem to only be run on Azure Pipelines of the branches (like 3.8 
and master)
* the fixed bug likely existed since Python 3.6:

static int
gotlandmark(const wchar_t *landmark)
{
Py_ssize_t n = wcsnlen_s(prefix, MAXPATHLEN);
join(prefix, landmark);
...
prefix[n] = '\0';
...
}

with join which uses _PathCchCombineEx() or PathCombineW()

... No idea why the bug decided to show up today, 3.8.0rc1 release day.

Anyway, the Azure Pipelines CI is back to green on the 3.8 branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38324] [Windows] test_locale and test__locale failures on Windows

[STINNER Victor]

Change by STINNER Victor :


--
components: +Tests, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
title: test_locale and test__locale failures on Windows -> [Windows] 
test_locale and test__locale failures on Windows
versions: +Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38325] [Windows] test_winconsoleio failures

[STINNER Victor]

New submission from STINNER Victor :

On Windows 10 version 1903, test_winconsoleio even when run from cmd.exe 
console.

C:\vstinner\python\3.8>python -m test -v test_winconsoleio
Running Release|x64 interpreter...
== CPython 3.8.0b4+ (heads/pr/16490:8a204fd07c, Sep 30 2019, 14:29:53) [MSC 
v.1916 64 bit (AMD64)]
== Windows-10-10.0.18362-SP0 little-endian
== cwd: C:\vstinner\python\3.8\build\test_python_1616
== CPU count: 2
== encodings: locale=cp1252, FS=utf-8
Run tests sequentially
0:00:00 [1/1] test_winconsoleio
test_abc (test.test_winconsoleio.WindowsConsoleIOTests) ... ok
test_conin_conout_names (test.test_winconsoleio.WindowsConsoleIOTests) ... ok
test_conout_path (test.test_winconsoleio.WindowsConsoleIOTests) ... ok
test_ctrl_z (test.test_winconsoleio.WindowsConsoleIOTests) ... Ä^Z
ok
test_input (test.test_winconsoleio.WindowsConsoleIOTests) ... abc123
ϼўТλФЙ
A͏B ﬖ̳AA̝
�ERROR
test_open_fd (test.test_winconsoleio.WindowsConsoleIOTests) ... ok
test_open_name (test.test_winconsoleio.WindowsConsoleIOTests) ... ok
test_partial_reads (test.test_winconsoleio.WindowsConsoleIOTests) ... �ERROR
test_partial_surrogate_reads (test.test_winconsoleio.WindowsConsoleIOTests) ... 
�ERROR
test_write_empty_data (test.test_winconsoleio.WindowsConsoleIOTests) ... ok

==
ERROR: test_input (test.test_winconsoleio.WindowsConsoleIOTests)
--
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test_winconsoleio.py", line 148, in 
test_input
self.assertStdinRoundTrip('\U0010\U0010\U0010fffd')
  File "C:\vstinner\python\3.8\lib\test\test_winconsoleio.py", line 135, in 
assertStdinRoundTrip
actual = input()
OSError: [WinError 87] Paramètre incorrect

==
ERROR: test_partial_reads (test.test_winconsoleio.WindowsConsoleIOTests)
--
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test_winconsoleio.py", line 161, in 
test_partial_reads
b = stdin.read(read_count)
OSError: [WinError 87] Paramètre incorrect

==
ERROR: test_partial_surrogate_reads 
(test.test_winconsoleio.WindowsConsoleIOTests)
--
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test_winconsoleio.py", line 178, in 
test_partial_surrogate_reads
b = stdin.read(read_count)
OSError: [WinError 87] Paramètre incorrect

--

Ran 10 tests in 0.013s

FAILED (errors=3)
test test_winconsoleio failed
test_winconsoleio failed

== Tests result: FAILURE ==

1 test failed:
test_winconsoleio

Total duration: 62 ms
Tests result: FAILURE

--
components: Windows
messages: 353571
nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] test_winconsoleio failures
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38324] test_locale and test__locale failures on Windows

[STINNER Victor]

New submission from STINNER Victor :

On Windows 10 version 1903, 3 locale tests fail:

vstinner@WIN C:\vstinner\python\3.8>python -m test -v test_locale test__locale

==
ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous)
--
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test_locale.py", line 567, in 
test_getsetlocale_issue1813
locale.setlocale(locale.LC_CTYPE, loc)
  File "C:\vstinner\python\3.8\lib\locale.py", line 608, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting

==
ERROR: test_float_parsing (test.test__locale._LocaleTests)
--
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test__locale.py", line 184, in 
test_float_parsing
if localeconv()['decimal_point'] != '.':
UnicodeDecodeError: 'locale' codec can't decode byte 0xa0 in position 0: 
decoding error

==
ERROR: test_lc_numeric_localeconv (test.test__locale._LocaleTests)
--
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test__locale.py", line 130, in 
test_lc_numeric_localeconv
formatting = localeconv()
UnicodeDecodeError: 'locale' codec can't decode byte 0xa0 in position 0: 
decoding error

test_float_parsing() fails for locales:

* "ka_GE"
* "fr_FR.UTF-8"

test_lc_numeric_localeconv() fails for locales:

* 'ka_GE'
* 'fr_FR.UTF-8'
* 'ps_AF'

test_getsetlocale_issue1813() fails with:

   testing with ('tr_TR', 'ISO8859-9')

Example:

vstinner@WIN C:\vstinner\python\3.8>python
Running Release|x64 interpreter...
Python 3.8.0b4+ (heads/pr/16490:8a204fd07c, Sep 30 2019, 14:29:53) [MSC v.1916 
64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

>>> import locale
>>> locale.setlocale(locale.LC_CTYPE, 'tr_TR')
'tr_TR'
>>> loc=locale.getlocale(locale.LC_CTYPE)  
>>> loc
('tr_TR', 'ISO8859-9')
>>> locale.setlocale(locale.LC_CTYPE, loc) 
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\vstinner\python\3.8\lib\locale.py", line 608, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting

# It works using the low-level _locale module
# which doesn't parse setlocale() output

>>> import _locale
>>> _locale.setlocale(_locale.LC_CTYPE, None) 
'tr_TR'
>>> locale.setlocale(locale.LC_CTYPE, "tr_TR") 
'tr_TR'

--
messages: 353570
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_locale and test__locale failures on Windows

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38319] shutil.copyfile(): os.sendfile() fails with OverflowError on 32-bit system

[STINNER Victor]

STINNER Victor  added the comment:

Similar failure on ARMv7 Debian buster 3.x:
https://buildbot.python.org/all/#/builders/176/builds/1372

pythoninfo:
sys.maxsize: 2147483647

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] test_ayncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x

[STINNER Victor]

New submission from STINNER Victor :

test_asyncio fails once on AMD64 RHEL7 Refleaks 3.x, and then 
test_close_kill_running() was killed after 3h 15 min. I guess that it hangs, 
but I'm not 100% sure. When test_asyncio was re-run, it seems like test_asyncio 
was run 3x successful but it hanged at the 4rd run. Refleaks runs each test 6 
times.

https://buildbot.python.org/all/#/builders/264/builds/10

0:17:04 load avg: 3.01 [416/419/1] test_asyncio failed (12 min 21 sec) -- 
running: test_multiprocessing_fork (6 min 34 sec), test_concurrent_futures (10 
min 52 sec), test_multiprocessing_spawn (13 min 53 sec)
beginning 6 repetitions
123456
.Unknown child process pid 25032, will report returncode 255
Loop <_UnixSelectorEventLoop running=False closed=True debug=False> that 
handles pid 25032 is closed
.Unknown child process pid 19349, will report returncode 255
Child watcher got an unexpected pid: 19349
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.refleak/build/Lib/asyncio/unix_events.py",
 line 1213, in _do_waitpid
loop, callback, args = self._callbacks.pop(pid)
KeyError: 19349
test test_asyncio failed -- Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.refleak/build/Lib/test/test_asyncio/test_subprocess.py",
 line 156, in test_shell
self.assertEqual(exitcode, 7)
AssertionError: 255 != 7

(...)
0:21:59 load avg: 0.52 [419/419/1] test_concurrent_futures passed (15 min 46 
sec)
(...)
== Tests result: FAILURE ==

404 tests OK.

10 slowest tests:
- test_concurrent_futures: 15 min 46 sec
- test_multiprocessing_spawn: 14 min 7 sec
- test_asyncio: 12 min 21 sec
- test_multiprocessing_forkserver: 8 min 59 sec
- test_multiprocessing_fork: 7 min 13 sec
- test_io: 3 min 47 sec
- test_subprocess: 3 min 30 sec
- test_pickle: 2 min 51 sec
- test_capi: 2 min 47 sec
- test_zipfile: 2 min 41 sec

1 test failed:
test_asyncio

14 tests skipped:
test_devpoll test_gdb test_ioctl test_kqueue test_msilib
test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly
test_winconsoleio test_winreg test_winsound test_zipfile64

Re-running failed tests in verbose mode

Re-running test_asyncio in verbose mode
beginning 6 repetitions
123456
(...)

test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessThreadedWatcherTests) ... ok
...


test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessThreadedWatcherTests) ... ok
...


test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessThreadedWatcherTests) ... ok
...


test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessThreadedWatcherTests) ... ok
...
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_communicate (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) 
... ok
test_communicate_ignore_broken_pipe 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_create_subprocess_exec_text_mode_fails 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_create_subprocess_exec_with_path 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_create_subprocess_shell_text_mode_fails 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_devnull_error 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_devnull_input 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_devnull_output 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_empty_input (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) 
... ok
test_exec_loop_deprecated 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[STINNER Victor]

STINNER Victor  added the comment:


New changeset dec39716ca93ee2e8d9b94915ece33014eb58e9e by Victor Stinner in 
branch 'master':
bpo-38322: Fix gotlandmark() of PC/getpathp.c (GH-16489)
https://github.com/python/cpython/commit/dec39716ca93ee2e8d9b94915ece33014eb58e9e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38322] Azure Pipelines: appx tests fail: init_fs_encoding: failed to get the Python codec of the filesystem encoding

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 18c4ba9f33868761e374a725d497902863d59ea9 by Victor Stinner in 
branch '3.8':
bpo-38322: Fix gotlandmark() of PC/getpathp.c (GH-16490)
https://github.com/python/cpython/commit/18c4ba9f33868761e374a725d497902863d59ea9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com