[issue39951] Ignore specific errors when closing ssl connections

[Christian Heimes]

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 bug in higher 
level application could. The ssl module cannot ignore this error condition.

https://github.com/openssl/openssl/blob/76624df15fef0725f28a8b9d0f31256946669b1a/ssl/record/rec_layer_s3.c#L1635-L1648

--
assignee:  -> christian.heimes
components: +SSL, asyncio -Extension Modules, Library (Lib)
nosy: +asvetlov, yselivanov
stage: resolved -> 
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

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

[miss-islington]

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 

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

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

[Serhiy Storchaka]

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)
https://github.com/python/cpython/commit/effaec0bb54f381db8ccfa62514bc26b00946b40


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue39951] Ignore specific errors when closing ssl connections

[Dima Tisnek]

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 (sending close notifies) closes both directions at once.
However, something like a data race is possible:
Let's say "our" side sent close notify at t0, which arrives at "their" side at 
t1, and the packet that "their" sent at "t1" arrives back to "us"
 at t2.
"Their" side can legitimately continue to send data during t0..t1, as it has 
not received the close notify yet.
This data can arrive at "our" side anywhere within t0...t2 period.
Current implementation treats this data as protocol violation.
I don't believe it should, because the data was legitimate at the time it was 
sent. It should most likely be discarded though.


TLS 1.3 and later
Closing a connection only closes one half of the connection, the other half is 
closed after the round trip. (I'm not clear whether that's always the case, or 
if that's an option).
Current implementation is simply unprepared for half-closed connections (I 
think) and thus in a way, unprepared for TLS 1.3

--

___
Python tracker 

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

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

[Douglas Raillard]

Douglas Raillard  added the comment:

Thanks for looking into this issue

--

___
Python tracker 

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

[issue39951] Ignore specific errors when closing ssl connections

[Christian Heimes]

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.

Python's ssl module does not support one-way close yet. It's an unfortunate 
limitation of the API that predates my involvement in the ssl module. The 
unwrap() methods always performs a blocking two-way shutdown. unwrap() calls 
SSL_shutdown() twice to downgrade a TLS connection to a plain TCP connection. 
The unwrap() API also requires cooperation from both parties.

https://tools.ietf.org/html/rfc5246#section-7.2.1
https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html

--

___
Python tracker 

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

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

[Vinay Sajip]

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

--
nosy: +vinay.sajip
resolution:  -> not a bug
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

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

[Masoud Azizi]

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
priority: normal
severity: normal
status: open
title: (list have item) instate (item in list)
type: behavior
versions: Python 3.10, 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

[issue43135] Can't input Japanese.

[Marusoftware]

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&tcl upgrade is required.

--
assignee: terry.reedy
components: IDLE, Tkinter
messages: 386523
nosy: Marusoftware, terry.reedy
priority: normal
severity: normal
status: open
title: Can't input Japanese.
type: behavior
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

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

[Marusoftware]

Change by Marusoftware :


--
title: Can't input Japanese. -> Can't input Japanese on idle (MacOS).

___
Python tracker 

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

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

[Jan Steinke]

Change by Jan Steinke :


--
nosy: +jan-xyz

___
Python tracker 

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

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

[E. Paine]

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 

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

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

[Louis Sautier]

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 the problem.

Please consider the attached reproducer script and its output:
$ ./queue_test.py
using processes
2021-02-05T12:48:21.742728 worker 0 got 0, queue size was 100
2021-02-05T12:48:21.743702 worker 1 got 1, queue size was 99
2021-02-05T12:48:21.744059 worker 2 got 2, queue size was 98
2021-02-05T12:48:21.745352 worker 3 got 3, queue size was 97
2021-02-05T12:48:22.743905 worker 1 queue is EMPTY, size was 96
2021-02-05T12:48:22.744064 worker 0 got 4, queue size was 96
2021-02-05T12:48:22.746525 worker 3 queue is EMPTY, size was 95
2021-02-05T12:48:22.749573 worker 2 got 5, queue size was 95
2021-02-05T12:48:23.744474 worker 0 got 6, queue size was 94
2021-02-05T12:48:23.750728 worker 2 got 7, queue size was 93
2021-02-05T12:48:24.745852 worker 0 got 8, queue size was 92
2021-02-05T12:48:24.751827 worker 2 got 9, queue size was 91
[…]

I have been able to reproduce this problem with Python 2.7 and 3.5 through 3.9 
(3.10 untested).

When using threads and queue.Queue instead of their multiprocessing 
counterparts, the problem is not present ("./queue_test.py thread" → no 
spurious exceptions until the queue is actually empty).

--
components: Library (Lib)
files: queue_test.py
messages: 386525
nosy: sbraz
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.get(block=False) can raise queue.Empty on 
non-empty queue
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49791/queue_test.py

___
Python tracker 

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

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

[Louis Sautier]

Change by Louis Sautier :


--
nosy: +mdk

___
Python tracker 

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

[issue43137] webbrowser to support "gio open "

[Matthias Klose]

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 tool was superseded by gio(1) in 2015, and removed from
upstream GNOME in 2018. The version in Debian is currently a
Debian-specific patch, which we would like to remove before Debian 11.

The gnome-open tool was superseded by gvfs-open in 2008, ceased to be
part of GNOME releases after about 2011, most recently appeared in a
Debian stable release as part of Debian 9, and was finally removed from
Debian in 2019.
"""

The current list of browser could need some cleanup, e.g.:

 - remove "The Netscape and old Mozilla browsers"
 - remove grail?
 - remove gvfs-open
 - gnome-open?
 - can't find galeon anymore, but epiphany

--
components: Library (Lib)
messages: 386526
nosy: doko
priority: normal
severity: normal
status: open
title: webbrowser to support "gio open "
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

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

[Marcin Kowalczyk]

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 

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

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

[Julien Palard]

Julien Palard  added the comment:

I can reproduce it in 3.10 too.

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

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

[Marusoftware]

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.

Anyway this issue is solved by using 3.10.
But, 3.10 is now preview...I'm wait for release...

--

___
Python tracker 

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

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

[Marusoftware]

Change by Marusoftware :


--
resolution:  -> fixed

___
Python tracker 

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

[issue43129] Number of object on stack required by opcode

[Irit Katriel]

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 question is of course how to keep it up to 
date, and this is pretty much the same problem whether it's part of compile.c, 
the standard library or an external application.

--
nosy: +iritkatriel

___
Python tracker 

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

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

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

[Serhiy Storchaka]

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)
https://github.com/python/cpython/commit/c8b4375fe1aca1188f57ecf482547abd77e3ef91


--

___
Python tracker 

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

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

[Dirk Herrmann]

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 this case, Python first tries to import foo, then foo.bar, and finally 
foo.bar.baz.

I find this confusing.  Assuming that 5.3 is correct, the examples in 7.11 
could be improved, like, for the sample line mentioned above:

   import foo.bar.baz # foo, foo.bar and foo.bar.baz imported, foo 
bound locally

--
assignee: docs@python
components: Documentation
messages: 386532
nosy: Dirk Herrmann, docs@python
priority: normal
severity: normal
status: open
title: [doc] Inconsistent / confusing documentation regarding importing 
submodules
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

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

[Serhiy Storchaka]

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 examples in the stdlib which would benefit from this feature? The 
closest that I found is in mailbox and combines "rb+" with "wb+" and "rb", and 
I seen combinations of "rb+" and "xb+" in third-party code, but they are 
different cases.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

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

[Dennis Sweeney]

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 don't like using "a have x" to duplicate the behavior of "x in a", 
because,
per PEP 20: "There should be one-- and preferably only one --obvious way to do 
it."

--
nosy: +Dennis Sweeney

___
Python tracker 

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

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

[Paul Ganssle]

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: 
https://github.com/python/cpython/pull/24450#issuecomment-774190609

--
nosy: +p-ganssle
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
type:  -> behavior

___
Python tracker 

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

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

[Irit Katriel]

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 tracker 

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

[issue30915] distutils sometimes assumes wrong C compiler

[Irit Katriel]

Change by Irit Katriel :


--
components: +Distutils
nosy: +dstufft, eric.araujo, steve.dower

___
Python tracker 

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

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

[Terry J. Reedy]

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 universal2 installer is still listed as 
experimental, though now it seems to be pretty solid.

--
components: +macOS -IDLE
nosy: +ned.deily, ronaldoussoren
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

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

[Felix Yan]

New submission from Felix Yan :

==
FAIL: test_compound (tkinter.test.test_ttk.test_widgets.ButtonTest)
--
Traceback (most recent call last):
  File 
"/build/python/src/Python-3.9.1/Lib/tkinter/test/test_ttk/test_widgets.py", 
line 173, in test_compound
self.checkEnumParam(widget, 'compound',
  File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 
152, in checkEnumParam
self.checkInvalidParam(widget, name, '',
  File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 
75, in checkInvalidParam
widget[name] = value
AssertionError: TclError not raised

=
FAIL: test_type (tkinter.test.test_tkinter.test_widgets.MenuTest)
--
Traceback (most recent call last):
  File 
"/build/python/src/Python-3.9.1/Lib/tkinter/test/test_tkinter/test_widgets.py", 
line 1245, in test_type
self.checkEnumParam(widget, 'type',
  File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 
152, in checkEnumParam
self.checkInvalidParam(widget, name, '',
  File "/build/python/src/Python-3.9.1/Lib/tkinter/test/widget_tests.py", line 
75, in checkInvalidParam
widget[name] = value
AssertionError: TclError not raised

--

--
components: Tests
messages: 386538
nosy: felixonmars
priority: normal
severity: normal
status: open
title: test_ttk test_compound and test_tk test_type fails with Tk 8.6.11.1
type: behavior
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

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

[Spencer Nelson]

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 operations (asyncio is based on system calls of the 
> select/poll/epoll/kpoll variety, which add meaningful overhead when we're 
> talking about an operation that is otherwise equivalent to an extremely cheap 
> simple collections.deque.append call).

A few things:

First, I don't think I proposed that. I was simply saying that my expectations 
on behavior were incorrect, which points towards documentation.

Second, I don't think making a point "preemptible" is the same as actually 
executing a cooperative-style yield to the scheduler. I just expected that it 
would always be in the cards - that it would always be a potential point where 
I'd get scheduled away.

Third, I don't think that await asyncio.sleep(0) triggers a syscall, but I 
certainly could be mistaken. It looks to me like it is special-cased in 
asyncio, from my reading of the source. Again - could be wrong.

Fourth, I think that the idea of non-cooperative preempting scheduling is not 
nearly as bizarre as you make it sound. There's certainly plenty of prior art 
on preemptive schedulers out there. Go uses a sort of partial preemption at 
function call sites *because* it's a particularly efficient way to do things.

But anyway - I didn't really want to discuss this. As I said above, it's 
obviously a way way way bigger design discussion than my specific issue.


> It also breaks many reasonable uses of asyncio.wait and asyncio.as_completed, 
> where the caller can reasonably expect to be able to await the known-complete 
> tasks without being preempted (if you know the coroutine is actually done, it 
> could be quite surprising/problematic when you await it and get preempted, 
> potentially requiring synchronization that wouldn't be necessary otherwise).

I think this cuts both ways. Without reading the source code of asyncio.Queue, 
I don't see how it's possible to know whether its put method yields. Because of 
this, I tend to assume synchronization is necessary everywhere. The way I know 
for sure that a function call can complete without yielding is supposed to be 
that it isn't an `async` function, right? That's why asyncio.Queue.put_nowait 
exists and isn't asynchronous.

> In real life, if whatever you're feeding the queue with is infinite and 
> requires no awaiting to produce each value, you should probably just avoid 
> the queue and have the consumer consume the iterable directly.

The stuff I'm feeding the queue doesn't require awaiting, but I *wish* it did. 
It's just a case of not having the libraries for asynchronicity yet on the 
source side. I was hoping that the queue would let me pace my work in a way 
that would let me do more concurrent work.

> Or just apply a maximum size to the queue; since the source of data to put is 
> infinite and not-awaitable, there's no benefit to an unbounded queue, you may 
> as well use a bound roughly fitted to the number of consumers, because any 
> further items are just wasting memory well ahead of when it's needed.

The problem isn't really that put doesn't yield for unbounded queues - it's 
that put doesn't yield *unless the queue is full*. That means that, if I use a 
very high maximum size for the queue, I'll still spend a big chunk of time 
filling up the queue, and only then will consumers start doing work.

I could pick a small queue bound, but then I'm more likely to waste time doing 
nothing if consumers are slower than the producer - I'll sit there with a 
full-but-tiny queue. Work-units in the queue can take wildly different amounts 
of time, so consumers will often be briefly slow, so the producer races ahead - 
until it hits its tiny limit. But then new work units arrive, and so the 
consumers are fast again - and they're quickly starved for work because the 
producer didn't build a good backlog.

So, the problem still remains, if work takes an uncertain amount of time which 
would seem to be the common reason for using a queue in the first place.

> Point is, regular queue puts only block (and potentially release the GIL 
> early) when they're full or, as a necessary consequence of threading being 
> less predictable than asyncio, when there is contention on the lock 
> protecting the queue internals (which is usually resolved quickly); why would 
> asyncio queues go out of their way to block when they don't need to?

I think you have it backwards. asyncio.Queue.put *always* blocks other 
coroutines' execution for unbounded queues. Why do they always block? If I 
wanted that, I wouldn't use anything in asyncio.Queue. I'd just use a 
collections.deque.

--

___
Python tracker 

[issue30915] distutils sometimes assumes wrong C compiler

[Steve Dower]

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

___
Python tracker 

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

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

[Lysandros Nikolaou]

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 

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

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

[Lysandros Nikolaou]

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 edge cases. I'll try to dig a bit deeper during the 
weekend.

--
nosy: +pablogsal

___
Python tracker 

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

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

[Pablo Galindo Salgado]

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 

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

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

[Cake Xu]

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 dependent 
(whatever locale.getpreferredencoding() returns), but any text encoding 
supported by Python can be used. See the codecs module for the list of 
supported encodings.
"
But as I tried, I found that after I set locale using locale.setlocale(), the 
default encoding used by open() was changed and thus sometimes led to a 
UnicodeDecodeError.

So I think that the default encoding used by open() is the second element of 
whatever locale returned by locale.getlocale().

--
assignee: docs@python
components: Documentation
messages: 386544
nosy: docs@python, smallbigcake
priority: normal
severity: normal
status: open
title: build-in open() doesn't use whatever locale.getpreferredencoding() 
returns as default encoding.
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

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

[Cake Xu]

Change by Cake Xu :


--
type:  -> behavior

___
Python tracker 

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

[issue43048] Printing RecursionError results in RecursionError

[Vladimir Feinberg]

Change by Vladimir Feinberg :


--
keywords: +patch
pull_requests: +23256
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24460

___
Python tracker 

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

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

[Evgeny Naumov]

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

@dataclass(eq=True, frozen=True)
class A:
  a: str

@dataclass(eq=True, frozen=True)
class B:
  b: dict[A, str]

asdict(B({A("x"):"y"}))


The offending code are these lines in dataclasses.py:

elif isinstance(obj, dict):
return type(obj)((_asdict_inner(k, dict_factory),
  _asdict_inner(v, dict_factory))

The _asdict_inner(k, dict_factory) [correctly] turns dataclasses into dicts... 
which are not hashable. I assume there is a good reason the _asdict_inner 
function is called on the key, but its failure in this case looks like a 
(rather annoying!) error.

--
components: Library (Lib)
messages: 386545
nosy: enaumov
priority: normal
severity: normal
status: open
title: `asdict` fails with frozen dataclass keys; tries to use raw dict form as 
key
type: behavior
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

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

[Sanchit]

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 duplicate_for_child(fd)) of the class 
Popen, which, in turn, adds a duplicate FD to a list.
This list is then used in spawnv_passfds() in /Lib/multiprocessing/util.py, 
which uses that list as an argument in a call of _posixsubprocess.fork_exec().

In Modules/_posixsubprocess.c, checks exist to ensure that all the FDs in the 
list are unique, positive, and in a sorted order.
If duplicate entries are found, a ValueError: bad value(s) in fds_to_keep 
exception is raised, and the execution is terminated.
Even if this exception were somehow handled, a developer can't change the 
aforementioned FD list in Python without breaking modularity.

It's better to let developers get away with calling 
multiprocessing.reduction.DupFd() (in /Lib/multiprocessing/reduction.py) on by 
not accepting duplicate entries in the first place, so that spawning a process 
can be successful.

--
components: Library (Lib)
messages: 386546
nosy: sanchit
priority: normal
severity: normal
status: open
title: Do not add duplicate FDs to list in duplicate_for_child()
type: behavior
versions: Python 3.10, 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

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

[Sanchit]

Change by Sanchit :


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

___
Python tracker 

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

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +eric.smith

___
Python tracker 

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

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

[Eryk Sun]

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'
>>> locale.getpreferredencoding(False)
'UTF-8'
>>> locale.setlocale(locale.LC_CTYPE, 'en_US.iso-88591')
'en_US.iso-88591'
>>> locale.getpreferredencoding(False)
'ISO-8859-1'

If the designers of the io module had wanted the preferred encoding to always 
be the default encoding from setlocale(LC_CTYPE, ""), they would have used and 
documented locale.getpreferredencoding(True).

---

In Windows, locale.getpreferredencoding(False) always returns the default 
encoding from locale.getdefaultlocale(), which is the process active (ANSI) 
code page. Changing it to track the LC_CTYPE locale would be convenient for 
applications and scripts running in Windows 10, for which the CRT's POSIX 
locale implementation has supported UTF-8 since spring of 2018.

The base behavior can't be changed at this point, but a -X option and/or 
environment variable could enable locale.getpreferredencoding(False) --  i.e. 
locale._get_locale_encoding() -- to return the current LC_CTYPE encoding in 
Windows, as it does in POSIX.

--
nosy: +eryksun

___
Python tracker 

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

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

[Eryk Sun]

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

___
Python tracker 

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

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: needs patch -> 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

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

[Serhiy Storchaka]

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 

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

[issue42804] Unable to compile the cpython code x86 windows

[Sunny]

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 worked

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

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

[Cake Xu]

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 setlocale(LC_CTYPE, "").

Previously I had thought it's locale.getpreferredencoding(True) that invoked.

--

___
Python tracker 

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