[issue41114] "TypeError: unhashable type" could often be more clear

[drakebohan]

drakebohan  added the comment:

The problem is that you can't use a list as the key in a dict, since dict keys 
need to be immutable.  This means that when you try to hash an unhashable 
object it will result an error. For ex. when you use a list as a key in the 
dictionary , this cannot be done because lists can't be hashed. The standard 
way to solve this issue is to cast a list to a tuple . TypeError: unhashable 
type: 'list' usually means that you are trying to use a list as an hash 
argument. The standard way to solve this issue is to cast a list to tuple.

Though tuples may seem similar to lists, they are often used in different 
situations and for different purposes. Tuples can be used as keys if they 
contain only strings, numbers, or tuples; if a tuple contains any mutable 
object either directly or indirectly, it cannot be used as a key. You can’t use 
lists as key.

http://net-informations.com/python/iq/unhashable.htm

--
nosy: +drakebohan

___
Python tracker 

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

[issue44295] self.assertDictContainsSubset warning is unhelpful

[Raymond Hettinger]

Change by Raymond Hettinger :


--
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

[issue45582] Rewrite getpath.c in Python

[Steve Dower]

Steve Dower  added the comment:

I have tests passing now, so reviews would be appreciated.

There's definitely scope for optimising this algorithm both for speed and 
clarity, but I'd prefer to get the main translation in first so that any 
further changes have a reliable baseline (especially since we'll likely end up 
changing the behaviour slightly if we touch anything at all in getpath, so it'd 
be good to capture those as individual commits/bugs).

--

___
Python tracker 

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

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

[STINNER Victor]

STINNER Victor  added the comment:

> If this is intended behaviour, which seems to be the case according to 
> ncoghlan's comment https://bugs.python.org/issue32230#msg307721, it should be 
> clearly documented, as it's rather frustrating.

The -b command line documentation is not explicitly enough?

"Issue a warning when comparing bytes or bytearray with str or bytes with int. 
Issue an error when the option is given twice (-bb)."

https://docs.python.org/dev/using/cmdline.html#cmdoption-b

Modifying warning filters don't change how Python emits or not warnings. It 
only changes how emitted warnings are handlded: ignored, displayed, treated as 
errors.

The relationship between -b and BytesWarning is different than other warnings.

Should we add a note near the BytesWarning documentation?
https://docs.python.org/dev/library/exceptions.html#BytesWarning

--

___
Python tracker 

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

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

[STINNER Victor]

STINNER Victor  added the comment:

While you should not do that at home ;-), it's now *technically* possible to 
change the BytesWarning flag at runtime using a a *private* *internal* API:

$ ./python
Python 3.11.0a2+ (heads/remove_asyncore:010015d2eb, Nov 11 2021,

>>> "unicode" == b"bytes"
False

# Change the internal BytesWarning flag
>>> import _testinternalcapi
>>> config=_testinternalcapi.get_config()
>>> config['bytes_warning']=1
>>> _testinternalcapi.set_config(config)

>>> "unicode" == b"bytes"
:1: BytesWarning: Comparison between bytes and string
False

--

___
Python tracker 

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

[issue45812] SystemError when using code.interact

[Andre Roberge]

New submission from Andre Roberge :

In the following, I execute a single invalid statement in the Python 
interpreter, which gives the correct error message. Afterwards, I repeat this 
example using code.interact(), generating a different traceback. This issue 
affects IDLE differently as shown in the attached file: the statement is never 
considered to be complete.

===
Python 3.11.0a2 (tags/v3.11.0a2:e2b4e4b, Nov  5 2021, 20:00:05) [MSC v.1929 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 3 \ 4
  File "", line 1
a = 3 \ 4
^
SyntaxError: unexpected character after line continuation character
>>> import code
>>> code.interact()
Python 3.11.0a2 (tags/v3.11.0a2:e2b4e4b, Nov  5 2021, 20:00:05) [MSC v.1929 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> a = 3 \ 4
...
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", 
line 301, in interact
console.interact(banner, exitmsg)
^
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", 
line 232, in interact
more = self.push(line)
   ^^^
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", 
line 258, in push
more = self.runsource(source, self.filename)
   ^
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\code.py", 
line 63, in runsource
code = self.compile(source, filename, symbol)
   ^^
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\codeop.py", 
line 185, in __call__
return _maybe_compile(self.compiler, source, filename, symbol)
   ^^^
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\codeop.py", 
line 96, in _maybe_compile
code2 = compiler(source + "\n\n", filename, symbol)
^^^
  File "C:\Users\andre\AppData\Local\Programs\Python\Python311\lib\codeop.py", 
line 150, in __call__
codeob = compile(source, filename, symbol, self.flags, True)
 ^^^
SystemError: Negative size passed to PyUnicode_New

--
components: Parser
files: idle_problem.png
messages: 406381
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: SystemError when using code.interact
versions: Python 3.11
Added file: https://bugs.python.org/file50441/idle_problem.png

___
Python tracker 

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

[issue45811] Improve error message when source code contains invisible control characters

[Andre Roberge]

Change by Andre Roberge :


--
nosy: +aroberge

___
Python tracker 

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

[issue39026] Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure

[STINNER Victor]

STINNER Victor  added the comment:

Gaige Paulsen: "I'll try to check that in the next day or two."

Thanks. Did you have the opportunity to give it a try?

--

___
Python tracker 

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

[issue45811] Improve error message when source code contains invisible control characters

[Steven D'Aprano]

New submission from Steven D'Aprano :

Invisible control characters (aside from white space) are not permitted in 
source code, but the syntax error we get is confusing and lacks information:

>>> s = 'print\x17("Hello")'
>>> eval(s)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
print("Hello")
 ^
SyntaxError: invalid syntax


The caret points to an invisible character. The offending control character is 
not visible in the traceback, or the source code unless you use a hex editor. 
Copying and pasting the string from the traceback, or the source code, may 
remove the control character (depending on the tools you use), making it even 
harder to track down the problem.

I suggest that the syntax error should state that the problem is an invisible 
control character, and display it as a standard human-readable code together 
with its hex code:

SyntaxError: invisible control character ^W (0x17)


Just in case it isn't obvious what the mapping between controls and the human 
visible string is:

def control(char):
n = ord(char)
if 0 <= n <= 0x1F:
# C0 control codes
return '^' + chr(ord('@')+n)
elif n == 0x7F:
# DEL
return '^?'
elif 0x80 <= n <= 0x9F:
# C1 control codes
return 'Esc+' + chr(ord('@')+n-0x80)
else:
raise ValueError('Not a control character.')


https://en.wikipedia.org/wiki/C0_and_C1_control_codes

--
components: Interpreter Core
messages: 406379
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Improve error message when source code contains invisible control 
characters
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue30514] test_poplib replace asyncore

[STINNER Victor]

STINNER Victor  added the comment:

I removed asyncore in bpo-28533:

New changeset 9bf2cbc4c498812e14f20d86acb61c53928a5a57 by Victor Stinner in 
branch 'main':
bpo-28533: Remove asyncore, asynchat, smtpd modules (GH-29521)
https://github.com/python/cpython/commit/9bf2cbc4c498812e14f20d86acb61c53928a5a57

But I kept a private copy as test.support._asyncore for the few tests which 
still use it (asyncore, asynchat and/or smtpd).

--
nosy: +vstinner

___
Python tracker 

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

[issue28533] Remove asyncore, asynchat and smtpd modules

[STINNER Victor]

STINNER Victor  added the comment:

asyncore, asynchat, smtpd modules have been removed. I close this issue.

> asyncore is still used in several tests and should be replaced

This issue is not solved. My PR only copied asyncore as a private module in 
test.support (test.support._asyncore). If someone cares, please open a new 
issue.

--
dependencies:  -test_poplib replace asyncore
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

[issue45573] Use pkg-config autoconf macros to detect flags for Modules/Setup

[Brett Cannon]

Brett Cannon  added the comment:

> Is traditional cross-compiling work still useful these days anyway?

Yes for things like WebAssembly where there is no equivalent of an emulated CPU 
under QEMU.

--

___
Python tracker 

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

[issue45677] [doc] improve sqlite3 docs

[Carol Willing]

Carol Willing  added the comment:


New changeset a40d066e8ef548b52eca2b0e27c219ddd7e11592 by Miss Islington (bot) 
in branch '3.9':
bpo-45677: Reword first section of `sqlite3` docs (GH-29326) (GH-29567)
https://github.com/python/cpython/commit/a40d066e8ef548b52eca2b0e27c219ddd7e11592


--

___
Python tracker 

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

[issue45677] [doc] improve sqlite3 docs

[Carol Willing]

Carol Willing  added the comment:


New changeset 94dad5e41e5863e03972f3f3646087fb591f73f9 by Miss Islington (bot) 
in branch '3.10':
bpo-45677: Reword first section of `sqlite3` docs (GH-29326) (GH-29566)
https://github.com/python/cpython/commit/94dad5e41e5863e03972f3f3646087fb591f73f9


--

___
Python tracker 

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

[issue28533] Remove asyncore, asynchat and smtpd modules

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 9bf2cbc4c498812e14f20d86acb61c53928a5a57 by Victor Stinner in 
branch 'main':
bpo-28533: Remove asyncore, asynchat, smtpd modules (GH-29521)
https://github.com/python/cpython/commit/9bf2cbc4c498812e14f20d86acb61c53928a5a57


--

___
Python tracker 

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

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

[Michael Curran]

Michael Curran  added the comment:

PR: https://github.com/python/cpython/pull/26204
Looks like a maintainer needs to allow a workflow to run for the remaining 
checks.

--

___
Python tracker 

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

[issue45810] Prohibit invisible control characters in string literals and comments

[Steven D'Aprano]

New submission from Steven D'Aprano :

Currently invisible control characters aside from whitespace (tabs, newlines, 
formfeeds, carriage returns) are prohibited outside of comments and string 
literals. As discussed in this thread:

https://mail.python.org/archives/list/python-...@python.org/message/DN24FK3A2DSO4HBGEDGJXERSAUYK6VK6/

we should ban C0 and C1 control characters (aside from \t\n\f\r) in string 
literals and comments too.

To be clear, the ban is on actual invisible control characters, not escape 
sequences.

--
components: Interpreter Core
messages: 406370
nosy: serhiy.storchaka, steven.daprano
priority: normal
severity: normal
status: open
title: Prohibit invisible control characters in string literals and comments
type: security
versions: Python 3.11

___
Python tracker 

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

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

[Michael Curran]

Michael Curran  added the comment:

As requested, I created a pr which adds a test to show the crash. It is marked 
as expected failure on 32 bit (x86) and runs successfully as expected on x64.

What would be the next steps in moving this issue forward?

I don't think I have the knowledge to be able to start on an actual fix for the 
bug myself, but I and my organization are happy to assist where we can.

A little bit of background:
The NvDA screen reading software allows blind and vision impaired people across 
the globe to access the Windows Operating System independently, improving 
socialization, education and employment outcomes. It is used by around 200,000 
people in over 150 countries.

The NVDA screen reader is written primarily in Python, and is currently using 
Python 3.7. We would like to upgrade to a newer Python release, but currently 
cannot due to this bug. We currently use the x86 build of Python as a small 
(but significant) number of our users are still on a pure 32-bit build of 
Windows. Taking into account the fact that are main demographic are people from 
developing countries, it is not simple for many of our users to upgrade their 
existing hardware to 64-bit.

There will come a time where we will drop x86 support, and just release an x64 
build of NVDA, but right now our pure x86 user numbers are still too high.

We would love to be able to get our 200,000 users onto a more recent and secure 
Python version as soon as possible, but we can only do this once this bug is 
addressed.

This bug has now been open for 2 years. If the bug is impossible to fix, or no 
one is able, then perhaps Python needs to consider dropping support for x86, as 
currently this build can cause stack corruption, as demonstrated by this issue 
and the pr tests.

--

___
Python tracker 

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

[issue25381] Update doc of three C exception values.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
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

[issue25381] Update doc of three C exception values.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset b0bdc093c2c15c352c5bede060117790705f5db0 by Miss Islington (bot) 
in branch '3.9':
bpo-25381: Update explanation of exceptions in C. (GH-26838) (GH-29569)
https://github.com/python/cpython/commit/b0bdc093c2c15c352c5bede060117790705f5db0


--

___
Python tracker 

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

[issue25381] Update doc of three C exception values.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 0320cf1a250b025f2ef25637851384bf8b61d207 by Miss Islington (bot) 
in branch '3.10':
bpo-25381: Update explanation of exceptions in C. (GH-26838) (GH-29568)
https://github.com/python/cpython/commit/0320cf1a250b025f2ef25637851384bf8b61d207


--

___
Python tracker 

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

[issue45806] Cannot Recover From StackOverflow in 3.9 Tests

[Jeremy Kloth]

Jeremy Kloth  added the comment:

I'll note that it also fails on first run on the Windows 11 builder:

https://buildbot.python.org/all/#/builders/737/builds/65

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue45806] Cannot Recover From StackOverflow in 3.9 Tests

[Jeremy Kloth]

Change by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

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

[issue43225] Add missing value returned by methods on cookiejar

[Carol Willing]

Carol Willing  added the comment:


New changeset 3352834f59531dfa42dbef00ada4fb95ded2ae3a by Emmanuel Arias in 
branch 'main':
bpo-43225: [DOC] Add missing value returned by methods on cookiejar (GH-24522)
https://github.com/python/cpython/commit/3352834f59531dfa42dbef00ada4fb95ded2ae3a


--
nosy: +willingc

___
Python tracker 

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

[issue25381] Update doc of three C exception values.

[miss-islington]

Change by miss-islington :


--
pull_requests: +27817
pull_request: https://github.com/python/cpython/pull/29569

___
Python tracker 

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

[issue25381] Update doc of three C exception values.

[Carol Willing]

Carol Willing  added the comment:


New changeset ad43dc0b54994e7e7d06e3d4896ade188b36ee12 by Terry Jan Reedy in 
branch 'main':
bpo-25381: Update explanation of exceptions in C. (GH-26838)
https://github.com/python/cpython/commit/ad43dc0b54994e7e7d06e3d4896ade188b36ee12


--
nosy: +willingc

___
Python tracker 

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

[issue25381] Update doc of three C exception values.

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +27816
pull_request: https://github.com/python/cpython/pull/29568

___
Python tracker 

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

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful

[Sam Gross]

Sam Gross  added the comment:

The `pthread_exit` behavior has been a problem for PyTorch and related 
libraries since Python 3.9. The PyTorch team has tried working around the 
problems without success (i.e. they keep getting bug reports involving crashes 
in PyEval_SaveThread/RestoreThread).

The hang/paused the thread behavior suggested by jbms and gps seems like the 
only reliable option. This is also what the Java VM does when returning from 
native code and the JVM has exited.

I believe it's not difficult to hang a thread in a cross-platform way: create a 
mutex, acquire it in the main thread (before setting PyRuntime._finalizing), 
never release it. Other threads can acquire that same mutex to block until the 
application exits.

The crashes can occur even without daemon threads if the user presses ctrl-c 
while _thread_shutdown is running.

--
nosy: +colesbury

___
Python tracker 

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

[issue45677] [doc] improve sqlite3 docs

[miss-islington]

Change by miss-islington :


--
pull_requests: +27815
pull_request: https://github.com/python/cpython/pull/29567

___
Python tracker 

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

[issue45677] [doc] improve sqlite3 docs

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +27814
pull_request: https://github.com/python/cpython/pull/29566

___
Python tracker 

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

[issue45677] [doc] improve sqlite3 docs

[Carol Willing]

Carol Willing  added the comment:


New changeset 6c5a312fb6d92e879bf4c570b94e18bb9ffe5970 by Erlend Egeberg 
Aasland in branch 'main':
bpo-45677: Reword first section of `sqlite3` docs (#29326)
https://github.com/python/cpython/commit/6c5a312fb6d92e879bf4c570b94e18bb9ffe5970


--

___
Python tracker 

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

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

[Gregory P. Smith]

Gregory P. Smith  added the comment:

clarification after poking around: s/all/a lot/ - YouTube used it to help their 
Python 3 migration.  Regardless, the env. var has been useful.

--

___
Python tracker 

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

[issue43526] Programmatic management of BytesWarning doesn't work for native triggers.

[Gregory P. Smith]

Gregory P. Smith  added the comment:

fwiw, at work we modified our interpreter to treat PYTHONBYTESWARNING=1 or 2 as 
if -b or -bb were passed.  All of our tests run by default with a 
PYTHONBYTESWARNING=2 in their environment.

--
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

[issue45636] Merge BINARY_*/INPLACE_* into BINARY_OP

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +27813
pull_request: https://github.com/python/cpython/pull/29565

___
Python tracker 

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

[issue45476] [C API] Disallow using PyFloat_AS_DOUBLE() as l-value

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy: +erlendaasland

___
Python tracker 

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

[issue42540] Debug pymalloc crash when using os.fork() [regression]

[Sam Gross]

Change by Sam Gross :


--
keywords: +patch
nosy: +colesbury
nosy_count: 2.0 -> 3.0
pull_requests: +27812
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29564

___
Python tracker 

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

[issue45807] Strange SyntaxError message / suggestions for "@x = 123"

[Andre Roberge]

Change by Andre Roberge :


--
nosy: +aroberge

___
Python tracker 

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

[issue45220] Windows builds sometimes fail on Azure and GitHub Action: fatal error RC1116: RC terminating after preprocessor errors

[Steve Dower]

Steve Dower  added the comment:

> instead of manually defining RT_MANIFEST, try including "winresrc.h" in the 
> resource definition files

I just wish it were documented... we can keep it in mind if another one of 
these pops up.

--

___
Python tracker 

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

[issue45809] Race condition in WeakKeyDictionary/WeakKeyDictionary

[Sam Gross]

Sam Gross  added the comment:

The attached patch (issue45809-repro.patch) introduces artificial delays to 
make reproduction of the underlying issue easier.

To reproduce the issue:
  
  patch -p1 < issue45809-repro.patch
  ./python -m test test_weakref -m test_threaded_weak_value_dict_deepcopy -v

--
keywords: +patch
Added file: https://bugs.python.org/file50440/issue45809-repro.patch

___
Python tracker 

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

[issue45809] Race condition in WeakKeyDictionary/WeakKeyDictionary

[Sam Gross]

New submission from Sam Gross :

The issue described issue7105 (and maybe issue7060) still exists due to a race 
condition in WeakKeyDictionary. This shows up as test failure that looks like:

  test test_weakref failed -- Traceback (most recent call last):
File "Lib/test/test_weakref.py", line 1960, in 
test_threaded_weak_value_dict_deepcopy
  self.check_threaded_weak_dict_copy(weakref.WeakValueDictionary, True)
File "Lib/test/test_weakref.py", line 1940, in check_threaded_weak_dict_copy
  raise exc[0]
File "Lib/test/test_weakref.py", line 1897, in dict_copy
  _ = copy.deepcopy(d)
File "Lib/copy.py", line 153, in deepcopy
  y = copier(memo)
File "Lib/weakref.py", line 189, in __deepcopy__
  for key, wr in self.data.items():
  RuntimeError: dictionary changed size during iteration

The cause is that the check of "self._iterating" and the call to 
"_atomic_removal" are not performed atomically together. By the time 
_atomic_removal() is called, an iteration might have already started.

https://github.com/python/cpython/blob/ec382fac0db6d9159c2d3496a70b7a605545957e/Lib/weakref.py#L109-L114

--
components: Library (Lib)
messages: 406357
nosy: colesbury
priority: normal
severity: normal
status: open
title: Race condition in WeakKeyDictionary/WeakKeyDictionary
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue45220] Windows builds sometimes fail on Azure and GitHub Action: fatal error RC1116: RC terminating after preprocessor errors

[Steve Dower]

Steve Dower  added the comment:


New changeset 32d14b262d6d914f63485f8d6e7859df58cd2089 by Miss Islington (bot) 
in branch '3.9':
bpo-45220: Ensure RT_MANIFEST is defined when compiling Windows resource files 
(GH-29501)
https://github.com/python/cpython/commit/32d14b262d6d914f63485f8d6e7859df58cd2089


--

___
Python tracker 

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

[issue45636] Merge BINARY_*/INPLACE_* into BINARY_OP

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset ec382fac0db6d9159c2d3496a70b7a605545957e by Brandt Bucher in 
branch 'main':
bpo-45636: Remove the old %-formatting fast-path (GH-29532)
https://github.com/python/cpython/commit/ec382fac0db6d9159c2d3496a70b7a605545957e


--

___
Python tracker 

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

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

[Brandt Bucher]

Brandt Bucher  added the comment:

The total size of the main interpreter loop was recently reduced somewhat by an 
unrelated change:
 
https://github.com/python/cpython/commit/9178f533ff5ea7462a2ca22cfa67afd78dad433b

I wonder if this issue still exists?

--

___
Python tracker 

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

[issue45808] configure check for HAVE_CRYPT_R is wrong

[Christian Heimes]

Christian Heimes  added the comment:

https://www.freebsd.org/cgi/man.cgi?crypt(3)

LIBRARY
 Crypt Library (libcrypt, -lcrypt)

SYNOPSIS
 #include 

 char *
 crypt(const char *key, const char *salt);

--

___
Python tracker 

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

[issue45808] configure check for HAVE_CRYPT_R is wrong

[Christian Heimes]

Change by Christian Heimes :


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

___
Python tracker 

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

[issue45808] configure check for HAVE_CRYPT_R is wrong

[Christian Heimes]

New submission from Christian Heimes :

The configure check for HAVE_CRYPT_R assumes that all platforms have . 
Some platforms like FreeBSD don't have  at all. Instead the crypt_r() 
prototype is defined in .

--
messages: 406352
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: configure check for HAVE_CRYPT_R is wrong
type: behavior
versions: Python 3.11

___
Python tracker 

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

[issue45807] Strange SyntaxError message / suggestions for "@x = 123"

[Evan]

Change by Evan :


--
nosy: +schmave

___
Python tracker 

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

[issue45807] Strange SyntaxError message / suggestions for "@x = 123"

[Pierre Quentel]

New submission from Pierre Quentel :

In CPython 3.10 :

Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> @x = 123
  File "", line 1
@x = 123
 ^^^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?

but both suggestions lead to a SyntaxError :

>>> @x == 123
...
  File "", line 2

^
SyntaxError: invalid syntax
>>> @x := 123
...
  File "", line 2

^
SyntaxError: invalid syntax
>>>


Maybe an error message such as "cannot assign to decorator" would be more 
appropriate ?

--
components: Parser
messages: 406351
nosy: lys.nikolaou, pablogsal, quentel
priority: normal
severity: normal
status: open
title: Strange SyntaxError message / suggestions for "@x = 123"
type: enhancement
versions: Python 3.10

___
Python tracker 

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

[issue45512] [sqlite3] simplify "isolation level"

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +27810
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/29562

___
Python tracker 

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

[issue45512] [sqlite3] simplify "isolation level"

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset 822c3dcce3996e411c1ff5c432c6ac7d2845cfd6 by Erlend Egeberg 
Aasland in branch 'main':
bpo-45512: Raise exception if sqlite3.Connection.__init__ is called with bad 
isolation level (#29561)
https://github.com/python/cpython/commit/822c3dcce3996e411c1ff5c432c6ac7d2845cfd6


--

___
Python tracker 

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

[issue45795] urllib http client vulnerable to DOS attack

[Muhammad Farhan]

Muhammad Farhan  added the comment:

Is any one going to respond?

--

___
Python tracker 

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

[issue45476] [C API] Disallow using PyFloat_AS_DOUBLE() as l-value

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 15.11.2021 10:54, STINNER Victor wrote:
> 
> I don't understand what you are trying to prove about compilers not inlining 
> when you explicitly ask them... not to inline.

I'm not trying to prove anything, Victor.

I'm only stating the fact that by switching from macros to inline
functions we are giving away control to the compilers and should not
be surprised that Python now suddenly runs a lot slower on systems
which either have inlining optimizations switched off or where the
compiler (wrongly) assumes that creating more assembler would result
in slower code.

I've heard all your arguments against macros, but don't believe the
blanket approach to convert to inline functions is warranted in all
cases, in particular not for code which is private to the interpreter
and where we know that we need the code inlined to not result in
unexpected performance regressions.

I also don't believe that we should assume that Python C extension
authors will unintentionally misuse Python API macros. If they do,
it's their business to sort out any issues, not ours. If we document
that macros may not be used as l-values, that's clear enough. We don't
need to use compiler restrictions to impose such limitations.

IMO, conversion to inline functions should only happen, when

a) the core language implementation has a direct benefit, and

b) it is very unlikely that compilers will not inline the code
   with -O2 settings, e.g. perhaps using a threshold of LOCs
   or by testing with the website Oleg mentioned.

Overall, I think the PEP 670 should get some more attentions from the
SC to have a guideline to use as basis for deciding whether or not
to use the static inline function approach. That way we could avoid
these discussions :-)

BTW: Thanks for the details about -O0 vs. -Og.

--

___
Python tracker 

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

[issue45512] [sqlite3] simplify "isolation level"

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

Need to amend GH-29053, so I'm opening until the fix is merged.

--
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

[issue45476] [C API] Disallow using PyFloat_AS_DOUBLE() as l-value

[STINNER Victor]

STINNER Victor  added the comment:

I don't understand what you are trying to prove about compilers not inlining 
when you explicitly ask them... not to inline.

The purpose of the -O0 option is to minimize the build time, with a trade-off: 
don't expect the built executable to be fast. If you care about Python 
performance... well, don't use -O0? Python ./configure --with-pydebug builds 
Python with -Og which is not -O0. The -Og level is special, it's a different 
trade-off between the compiler build time and Python runtime performance.

If you want a Python debug build (Py_DEBUG macro defined, ./configure 
--with-pydebug), it's perfectly fine to build it with -O2 or -O3 to make sure 
that static inline functions are inlined. You can also enable LTO and PGO on a 
debug build.

GCC -Og option:
"""
-Og

Optimize debugging experience. -Og should be the optimization level of 
choice for the standard edit-compile-debug cycle, offering a reasonable level 
of optimization while maintaining fast compilation and a good debugging 
experience. It is a better choice than -O0 for producing debuggable code 
because some compiler passes that collect debug information are disabled at -O0.

Like -O0, -Og completely disables a number of optimization passes so that 
individual options controlling them have no effect. Otherwise -Og enables all 
-O1 optimization flags except for those that may interfere with debugging:

-fbranch-count-reg  -fdelayed-branch 
-fdse  -fif-conversion  -fif-conversion2  
-finline-functions-called-once 
-fmove-loop-invariants  -fmove-loop-stores  -fssa-phiopt 
-ftree-bit-ccp  -ftree-dse  -ftree-pta  -ftree-sra
"""
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

I prefer to use gcc -O0 when I develop on Python because the build time matters 
a lot in my very specific use case, and gcc -O0 is the best to debug Python in 
a debugger. See my article:
https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb

On RHEL8, the Python 3.9 debug build is now built with -O0 to be fully usable 
in gdb (to debug C extensions).

In RHEL, the main motivation to use -O0 rather than -Og was to get a fully 
working gdb debugger on C extensions. With -Og, we get too many  
values which are blocking debugging :-(

--

___
Python tracker 

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

[issue45512] [sqlite3] simplify "isolation level"

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
pull_requests: +27809
pull_request: https://github.com/python/cpython/pull/29561

___
Python tracker 

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

[issue45476] [C API] Disallow using PyFloat_AS_DOUBLE() as l-value

[STINNER Victor]

STINNER Victor  added the comment:

I wrote PEP 670 "Convert macros to functions in the Python C API" for this 
issue:
https://www.python.org/dev/peps/pep-0670/

--

___
Python tracker 

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

[issue45476] [C API] Disallow using PyFloat_AS_DOUBLE() as l-value

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 15.11.2021 08:54, Oleg Iarygin wrote:
> 
> Oleg Iarygin  added the comment:
> 
> Marc-Andre:
>> Inlining is something that is completely under the control of the
> used compilers. Compilers are free to not inline function marked for
> inlining [...]
> 
> I checked the following C snippet on gcc.godbolt.org using GCC 4.1.2 and 
> Clang 3.0.0 with /-O0/-O1/-Os, and both compilers inline a function 
> marked as static inline:
> 
> static inline int foo(int a)
> {
> return a * 2;
> }
> 
> int bar(int a)
> {
> return foo(a) < 0;
> }
> 
> So even with -O0, GCC from 2007 and Clang from 2011 perform inlining. Though, 
> old versions of CLang leave a dangling original copy of foo for some reason. 
> I hope a linker removes it later.

That's a great website :-) Thanks for sharing.

However, even with x86-64 gcc 11.2, I get assembler which does not inline
foo() without compiler options or with -O0: https://gcc.godbolt.org/z/oh6qnffh7

Only with -O1, the site reports inlining foo().

> As for other compilers, I believe that if somebody specifies -O0, that person 
> has a sound reason to do so (like per-line debugging, building precise flame 
> graphs, or other specific scenario where execution performance does not 
> matter), so inlining interferes here anyway.

Sure, but my point was a different one: even with higher optimization
levels, the compiler can decide whether or not to inline. We expect
the compiler to inline, but cannot be sure.

With macros the compiler has no choice and we are in control and even
when using -O0, you will still want e.g. Py_INCREF() and Py_DECREF()
inlined.

--

___
Python tracker 

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

[issue45512] [sqlite3] simplify "isolation level"

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
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