[issue43140] built-in open() doesn't use locale.getpreferredencoding() as the default encoding

Cake Xu added the comment: Thank Eryk for answering my question. So I get it now. I use this in Linux. If my understanding is right, the open() will invoke locale.getpreferredencoding() by setting the do_setlocale=False -- i.e. locale.getpreferredencoding(False) -- to avoid invoking

[issue42804] Unable to compile the cpython code x86 windows

Sunny added the comment: Got it fixed with following the below steps a. Delete external folder b. Run the below build command build.bat -k -E -p x64 -k killed the existing python build process -E skipped the external libraries fetching -p mentioned the platform closing the ticket as it

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Serhiy Storchaka added the comment: Sorry, I thought I just forgot to close this issue. -- resolution: fixed -> stage: resolved -> needs patch status: closed -> open ___ Python tracker

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Change by Serhiy Storchaka : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue43140] built-in open() doesn't use locale.getpreferredencoding() as the default encoding

Change by Eryk Sun : -- components: +IO, Library (Lib) title: build-in open() doesn't use whatever locale.getpreferredencoding() returns as default encoding. -> built-in open() doesn't use locale.getpreferredencoding() as the default encoding versions: +Python 3.10

[issue43140] build-in open() doesn't use whatever locale.getpreferredencoding() returns as default encoding.

Eryk Sun added the comment: On most platforms, unless UTF-8 mode is enabled, locale.getpreferredencoding(False) returns the LC_CTYPE encoding of the current locale. For example, in Linux: >>> locale.setlocale(locale.LC_CTYPE, 'en_US.UTF-8') 'en_US.UTF-8' >>>

[issue43141] `asdict` fails with frozen dataclass keys; tries to use raw dict form as key

Change by Karthikeyan Singaravelan : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43142] Do not add duplicate FDs to list in duplicate_for_child()

Change by Sanchit : -- keywords: +patch pull_requests: +23257 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24461 ___ Python tracker ___

[issue43142] Do not add duplicate FDs to list in duplicate_for_child()

New submission from Sanchit : While spawning, if a process having code built on top of Python's multiprocessing module calls multiprocessing.reduction.DupFd() (in /Lib/multiprocessing/reduction.py) multiple times on the same File descriptor by mistake, then it ends up invoking

[issue43141] `asdict` fails with frozen dataclass keys; tries to use raw dict form as key

New submission from Evgeny Naumov : A simple example is documented here: https://github.com/samuelcolvin/pydantic/issues/2233 but it doesn't look like it was actually filed as a bug against CPython... Copy paste of the minimal reproducing example: from dataclasses import asdict, dataclass

[issue43048] Printing RecursionError results in RecursionError

Change by Vladimir Feinberg : -- keywords: +patch pull_requests: +23256 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/24460 ___ Python tracker

[issue43140] build-in open() doesn't use whatever locale.getpreferredencoding() returns as default encoding.

Change by Cake Xu : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43140] build-in open() doesn't use whatever locale.getpreferredencoding() returns as default encoding.

New submission from Cake Xu : In the document about build-in function open() https://docs.python.org/3/library/functions.html#open, it says that "encoding is the name of the encoding used to decode or encode the file. This should only be used in text mode. The default encoding is platform

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

Pablo Galindo Salgado added the comment: Yeah, I also believe this doesn't look like a bug and the fact that is consistent with 3.8 makes me more confident to say that is not. -- ___ Python tracker

[issue42918] Nested multi-line expression will lead to "compile()" fails

Lysandros Nikolaou added the comment: Thanks a lot for the report, Xinmeng! This is a bug in how we're checking for bad single statements in bad_single_statement and it's not trivial to fix due to the string shenanigans we're doing there in newline_in_string, which does not account for many

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

Lysandros Nikolaou added the comment: I can't really understand if this should be considered a bug or not. It's definitely consistent with 3.8 and my inclination that it is not. -- nosy: +pablogsal ___ Python tracker

[issue30915] distutils sometimes assumes wrong C compiler

Steve Dower added the comment: Existing distutils bugs are closed under PEP 632. New issues will be considered if they are release blockers, but (by definition) no existing issue meets this bar. -- resolution: -> out of date stage: -> resolved status: open -> closed

[issue43119] asyncio.Queue.put never yields if the queue is unbounded

Spencer Nelson added the comment: Josh, > Making literally every await equivalent to: > > await asyncio.sleep(0) > > followed by the actual await (which is effectively what you're proposing when > you expect all await to be preemptible) means adding non-trivial overhead to > all async

[issue43139] test_ttk test_compound and test_tk test_type fails with Tk 8.6.11.1

New submission from Felix Yan : == FAIL: test_compound (tkinter.test.test_ttk.test_widgets.ButtonTest) -- Traceback (most recent call last): File

[issue43135] Can't input Japanese on idle (MacOS).

Terry J. Reedy added the comment: The change in 3.10 is installing tk 8.6.11 instead of 8.6.8. This would have been or would be backported if and only if Ned and Ronald think it both possible and wise. As with most tkinter issues, this affects IDLE but is not an IDLE issue as such. The

[issue30915] distutils sometimes assumes wrong C compiler

Change by Irit Katriel : -- components: +Distutils nosy: +dstufft, eric.araujo, steve.dower ___ Python tracker ___ ___

[issue43134] (list have item) instate (item in list)

Irit Katriel added the comment: I agree with Dennis' comments. New syntax should make the language more powerful, not reduce 2 lines to a 1-liner. -- nosy: +iritkatriel resolution: -> rejected stage: -> resolved status: open -> closed ___ Python

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Paul Ganssle added the comment: Re-opening because this was merged without tests. @ZackerySpytz would you mind adding tests to hit these error cases? I've spent some time satisfying myself that it's indeed possible, and I've detailed a general outline here:

[issue43134] (list have item) instate (item in list)

Dennis Sweeney added the comment: You could express this as: a = [input() for i in range(10)] x = input() print(x in a) This is more clear IMO, because if you want to have something happen before something else, it's clearest to put them on separate lines, one after the other. I also

[issue43133] Accept file mode "rw" to open-or-create a file and seek to the start

Serhiy Storchaka added the comment: Open modes "r", "r+", "w", "w+", "a", "a+" are supported by C function fopen() and similar functions in other languages. Would not "rw" be confusing? Are there fopen-like functions in other programming languages which support this mode? Are there any

[issue43138] [doc] Inconsistent / confusing documentation regarding importing submodules

New submission from Dirk Herrmann : In the language reference, section "7.11 The import statement" is is explained in the example section: import foo.bar.baz # foo.bar.baz imported, foo bound locally When looking at "5.3. Searching", it is stated that regarding foo.bar.baz: In

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Serhiy Storchaka added the comment: New changeset c8b4375fe1aca1188f57ecf482547abd77e3ef91 by Miss Islington (bot) in branch '3.9': bpo-43132: Fix incorrect handling of PyObject_RichCompareBool() in _zoneinfo (GH-24450) (GH-24457)

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

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

[issue43129] Number of object on stack required by opcode

Irit Katriel added the comment: stack_effect is implemented in compile.c because it is used there. If you need something for an application like bytecode, it doesn't need to be in the cpython c code. It can be in the standard library in opcode.py, or even in bytecode library itself. The

[issue43135] Can't input Japanese on idle (MacOS).

Change by Marusoftware : -- resolution: -> fixed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43135] Can't input Japanese on idle (MacOS).

Marusoftware added the comment: Thank you for replying. I tried as you said. This issue is not occurs on 3.10.0a5. Thank you very much. But when want to use python 3.8 or 3.9 and others, I can't use this... If you are OK, generate patches. But this is really hard... So, this is optionally.

[issue43136] multiprocessing.Queue.get(block=False) can raise queue.Empty on non-empty queue

Julien Palard added the comment: I can reproduce it in 3.10 too. -- versions: +Python 3.10 ___ Python tracker ___ ___

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

Marcin Kowalczyk added the comment: Thank you! This means that I can continue to use PyUnicode_AsUTF8AndSize() without worries: https://github.com/google/riegeli/commit/17ab36bfdd6cc55f37cfbb729bd43c9cbff4cd22 -- ___ Python tracker

[issue43137] webbrowser to support "gio open "

New submission from Matthias Klose : [forwarded from https://bugs.debian.org/969776] """ rust-webbrowser tries to open URLs via "gvfs-open $URL" and "gnome-open $URL". Both are obsolete; the replacement is "gio open $URL", using the gio(1) tool from the libglib2.0-bin package. The gvfs-open

[issue43136] multiprocessing.Queue.get(block=False) can raise queue.Empty on non-empty queue

Change by Louis Sautier : -- nosy: +mdk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43136] multiprocessing.Queue.get(block=False) can raise queue.Empty on non-empty queue

New submission from Louis Sautier : Hello, I have noticed that when multiple processes try to simultaneously get items from a multiprocessing queue with block=False, it will raise queue.Empty even though there are still items in it. Adding a multiprocessing lock around calls to Queue.get fixes

[issue43135] Can't input Japanese on idle (MacOS).

E. Paine added the comment: Can you please test to see whether this occurs on 3.10.0a5 using the Universal2 installer? -- nosy: +epaine ___ Python tracker ___

[issue42853] `OverflowError: signed integer is greater than maximum` in ssl.py for files larger than 2GB

Change by Jan Steinke : -- nosy: +jan-xyz ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43135] Can't input Japanese on idle (MacOS).

Change by Marusoftware : -- title: Can't input Japanese. -> Can't input Japanese on idle (MacOS). ___ Python tracker ___ ___

[issue43135] Can't input Japanese.

New submission from Marusoftware : Can't input Japanese text to idle on MacOS. I think this caused by "https://core.tcl-lang.org/tk/tktview?name=39de9677aa;. So, builtin tk upgrade is required. -- assignee: terry.reedy components: IDLE, Tkinter messages: 386523 nosy: Marusoftware,

[issue43134] (list have item) instate (item in list)

New submission from Masoud Azizi : Please append a code to reverse check?like that? print([input() for i in'_'*10] have input()) Instade of: print(input() in [input() for i in'_'*10] ) i want to check that: is last input in the inputs or not! -- messages: 386522 nosy: mablue

[issue43107] RotatingFileHandler with multi processes creates too small backup files

Vinay Sajip added the comment: This is not a bug. See https://docs.python.org/3/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes You should use SocketHandler or QueueHandler to deal with a situation where multiple processes log to files (whether rotating or not).

[issue39951] Ignore specific errors when closing ssl connections

Christian Heimes added the comment: TLS 1.2 has one-way close notify. For example typical HTTP clients like curl send a close_notify and then shut down the TCP connection. HTTP servers may not reply with close_notify or may not wait for the client to confirm the server-side close notify.

[issue43102] namedtuple's __new__.__globals__['__builtins__'] is None

Douglas Raillard added the comment: Thanks for looking into this issue -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39951] Ignore specific errors when closing ssl connections

Dima Tisnek added the comment: Thank you, Christian, for removing 3.7 target, I was not up to date on Python support schedule. Regarding protocol violation, let me explain what I've dug up so far... I am not an expert, please feel free to correct me. TLS up to 1.2 Closing a connection

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Serhiy Storchaka added the comment: New changeset effaec0bb54f381db8ccfa62514bc26b00946b40 by Zackery Spytz in branch 'master': bpo-43132: Fix incorrect handling of PyObject_RichCompareBool() in _zoneinfo (GH-24450)

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Change by miss-islington : -- nosy: +miss-islington nosy_count: 2.0 -> 3.0 pull_requests: +23255 pull_request: https://github.com/python/cpython/pull/24457 ___ Python tracker

[issue39951] Ignore specific errors when closing ssl connections

Christian Heimes added the comment: 3.7 is in security fix-only mode. APPLICATION_DATA_AFTER_CLOSE_NOTIFY is a protocol violation in any TLS version. It's not related to TLS 1.3. The error occurs when one side wants to close the connection, but the other sides keeps sending user data. It's