[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Sergey B Kirpichev]

Change by Sergey B Kirpichev :


Added file: 
https://bugs.python.org/file50072/0001-bpo-44267-fix-parsing-Decimal-s-with-underscores.patch

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +facundobatista, mark.dickinson, rhettinger

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Sergey B Kirpichev]

New submission from Sergey B Kirpichev :

While working on issue44258 I discover that the decimal module doesn't follow 
specification in PEP 515: "The current proposal is to allow one underscore 
between digits, and after base specifiers in numeric literals." (c)

For example:
>>> float("1.1__1")
Traceback (most recent call last):
  File "", line 1, in 
ValueError: could not convert string to float: '1.1__1'

but
>>> from decimal import Decimal as C
>>> from _pydecimal import Decimal as P
>>> C("1.1__1")
Decimal('1.11')
>>> P("1.1__1")
Decimal('1.11')

Maybe this requirement could be relaxed in PEP, but it seems - this was already 
discussed (see Alternative Syntax section).  Hence, I think this is a bug.

Patch for _pydecimal attached.

--
components: Extension Modules, Library (Lib)
files: _pydecimal-pep515.diff
keywords: patch
messages: 394750
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Wrong PEP 515 parsing in decimal module (both C and Python versions)
versions: Python 3.11
Added file: https://bugs.python.org/file50071/_pydecimal-pep515.diff

___
Python tracker 

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

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

[Jordan Borean]

Change by Jordan Borean :


--
pull_requests: +25050
pull_request: https://github.com/python/cpython/pull/26454

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Zac Hatfield-Dodds]

Zac Hatfield-Dodds  added the comment:

Just chiming in with a plea to slow down the rate of changes to 
importlib.metadata - I understand that you want to tidy up the API, but even 
deprecations cause substantial work downstream.  Would it really be so bad to 
support the older APIs until they go end-of-life in CPython?

For example, in Hypothesis we care a great deal about compatibility with all 
supported Python versions (including treating warnings as errors) and try to 
minimize the hard dependencies.  As a result, our entry-points handling looks 
like this:
https://github.com/HypothesisWorks/hypothesis/blob/0a90ed6edf56319149956c7321d4110078a5c228/hypothesis-python/src/hypothesis/entry_points.py

Change can be worth the cost, but there *is* a cost and the packaging ecosystem 
is already painfully complex and fragmented.  Compatibility should be a 
foundational principle, not an optional extra _if someone presents a compelling 
use case!_

I'm also seriously concerned that you take GitHub links as an indication of who 
is affected.  Python is very very widely used, including in environments that 
don't feed much back into the GitHub-open-source space, and I think it's 
important to avoid breaking things for low-visibility users too.

--
nosy: +Zac Hatfield-Dodds

___
Python tracker 

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

[issue44235] Remove l*gettext() and related functions in the gettext module

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset 14ba761078b5ae83519e34d66ab883743912c45b by Dong-hee Na in branch 
'main':
bpo-44235: Remove deprecated functions in the gettext module. (GH-26378)
https://github.com/python/cpython/commit/14ba761078b5ae83519e34d66ab883743912c45b


--

___
Python tracker 

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

[issue44235] Remove l*gettext() and related functions in the gettext module

[Dong-hee Na]

Change by Dong-hee Na :


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

[issue44266] AttributeError: module 'sys' has no attribute 'original_stdout'

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Correct, sys has no attribute 'original_stdout'.

Do you have a file called `sys.py`? Rename it.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue44266] AttributeError: module 'sys' has no attribute 'original_stdout'

[Chinmay Malvania]

New submission from Chinmay Malvania :

I imported sys but when I use it, it says:
AttributeError: module 'sys' has no attribute 'original_stdout'

--
messages: 394746
nosy: chinmay.malvania
priority: normal
severity: normal
status: open
title: AttributeError: module 'sys' has no attribute 'original_stdout'

___
Python tracker 

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

[issue21550] Add Python implementation of the tar utility

[Filipe Laíns]

Filipe Laíns  added the comment:

Given the addition of the tarfile CLI and the seeming lack of interest, can 
this be closed?

--
nosy: +FFY00

___
Python tracker 

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

[issue44262] tarfile: some content different output

[Filipe Laíns]

Filipe Laíns  added the comment:

I modified the script to keep the both Python generated tarballs and ran 
diffoscope, which presents the issue very clearly:


$ diffoscope py.gz py2.gz
--- py.gz
+++ py2.gz
├── filetype from file(1)
│ @@ -1 +1 @@
│ -gzip compressed data, was "py", last modified: Sat May 29 23:24:02 2021, max 
compression
│ +gzip compressed data, was "py2", last modified: Sat May 29 23:24:03 2021, 
max compression


The issue is that by default, when writing gzip files, the mtime will be set 
for the last modification. This is helpful, but might be unwanted in some 
cases. You can change the mtime as shown in [1].

Now let's take a look at the difference between the file Python generated and 
the one the `tar` command generated.


$ diffoscope py.gz tar_a0.tgz
--- py.gz
+++ tar_a0.tgz
├── filetype from file(1)
│ @@ -1 +1 @@
│ -gzip compressed data, was "py", last modified: Sat May 29 23:24:02 2021, max 
compression
│ +gzip compressed data, from Unix


It seems like it generates the same output here because the `tar` command does 
not set any mtime on the archive by default.


[1] 
https://github.com/FFY00/trampolim/blob/dbd03c90eaa2cc732e1a01268786b491dc872fb7/trampolim/_build.py#L354

--
nosy: +FFY00

___
Python tracker 

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

[issue44261] SocketType documentation misleading

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

I propose to deprecate socket.SocketType. There's no reason to publicly expose 
_socket.socket separately from socket.socket, the only type that moat users 
should care about.

SocketType isn't needed for type checking; socket.socket is itself a class and 
can be used in type annotations.

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue43750] Undefined constant PACKET_MULTIHOST referred to in package socket

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:


New changeset 5f28752f5b51a1866f2428eeaf6082266723c78d by Zackery Spytz in 
branch 'main':
bpo-43750: Fix incorrect reference to PACKET_MULTIHOST in the docs (GH-25241)
https://github.com/python/cpython/commit/5f28752f5b51a1866f2428eeaf6082266723c78d


--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue44229] Intermittent connection errors in ssl tests on macOS CI

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> This might be the same macOS bug.

It could be, but the same thing happens on Windows

--

___
Python tracker 

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

[issue44265] Create an MSI Package

[Muhammad Hussein Ammari]

New submission from Muhammad Hussein Ammari :

Hi, Please create an MSI package. (like Python v3.4.4 or Python v2.7.18)
https://www.python.org/ftp/python/3.4.4/python-3.4.4.amd64.msi
https://www.python.org/ftp/python/2.7.18/python-2.7.18.amd64.msi
Thanks.

--
components: Installation, Windows
messages: 394740
nosy: paul.moore, steve.dower, tim.golden, xmha97, zach.ware
priority: normal
severity: normal
status: open
title: Create an MSI Package
versions: Python 3.10, Python 3.11, 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

[issue44229] Intermittent connection errors in ssl tests on macOS CI

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

Here's the output when with test.support.verbose = True:

test_ssl: testing with 'OpenSSL 1.1.1k  25 Mar 2021' (1, 1, 1, 11, 15)  
   
  under Mac ('11.3.1', ('', '', ''), 'x86_64')  
   
  HAS_SNI = True
   
  OP_ALL = 0x8054   
   
  OP_NO_TLSv1_1 = 0x1000
   
test_get_server_certificate (test.test_ssl.SimpleBackgroundTests) ...  server:  
new connection from ('127.0.0.1', 51163)

 server:  bad connection attempt from ('127.0.0.1', 51163): 
   
Traceback (most recent call last):
   File "/Users/erlendaasland/src/cpython-ssl/Lib/test/test_ssl.py", line 2366, 
in wrap_conn   
self.sslconn = self.server.context.wrap_socket(
   File "/Users/erlendaasland/src/cpython-ssl/Lib/ssl.py", line 518, in 
wrap_socket
return self.sslsocket_class._create(
   File "/Users/erlendaasland/src/cpython-ssl/Lib/ssl.py", line 1070, in 
_create   
self.do_handshake()
   File "/Users/erlendaasland/src/cpython-ssl/Lib/ssl.py", line 1339, in 
do_handshake  
self._sslobj.do_handshake()
 OSError: [Errno 41] Protocol wrong type for socket 
   
ERROR

==  
   
ERROR: test_get_server_certificate (test.test_ssl.SimpleBackgroundTests)
   
--
Traceback (most recent call last):
  File "/Users/erlendaasland/src/cpython-ssl/Lib/test/test_ssl.py", line 2130, 
in test_get_server_certificate  
_test_get_server_certificate(self, *self.server_addr, cert=SIGNING_CA)
  File "/Users/erlendaasland/src/cpython-ssl/Lib/test/test_ssl.py", line 2327, 
in _test_get_server_certificate 
pem = ssl.get_server_certificate((host, port), ca_certs=cert)
  File "/Users/erlendaasland/src/cpython-ssl/Lib/ssl.py", line 1520, in 
get_server_certificate
with create_connection(addr, timeout=timeout) as sock:
  File "/Users/erlendaasland/src/cpython-ssl/Lib/socket.py", line 844, in 
create_connection
raise err
  File "/Users/erlendaasland/src/cpython-ssl/Lib/socket.py", line 832, in 
create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 61] Connection refused

-- 


The mock server fails with EPROTOTYPE, thus the client fails with connection 
refused.

I found similar issues after doing some googling:
- 
http://erickt.github.io/blog/2014/11/19/adventures-in-debugging-a-potential-osx-kernel-bug/
- https://github.com/benoitc/gunicorn/issues/1487#issuecomment-333680970

This might be the same macOS bug.

--

___
Python tracker 

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

[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules

[Guido van Rossum]

Guido van Rossum  added the comment:

> What is/was the initial reason to not preserve the MRO for a TypedDict?

Hm, I can't say for sure. I believe it had something to do with TypedDict 
instances being instances of dict at runtime, but I can't actually reconstruct 
the reason. Maybe it's written up in PEP 589, but I suspect not (I skimmed and 
couldn't find it). If you ask on typing-sig maybe David Foster (who contributed 
the initial idea and implementation) remembers.

--

___
Python tracker 

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

[issue42085] Add dedicated slot for sending values

[Irit Katriel]

Irit Katriel  added the comment:


New changeset d338ce0796e5fe8e54dfe52f93ed9d5936ad3efe by Miss Islington (bot) 
in branch '3.10':
bpo-42085: [docs] Add versionadded for am_send in type object documentation 
(GH-25465) (GH-26453)
https://github.com/python/cpython/commit/d338ce0796e5fe8e54dfe52f93ed9d5936ad3efe


--

___
Python tracker 

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

[issue42085] Add dedicated slot for sending values

[miss-islington]

Change by miss-islington :


--
pull_requests: +25049
pull_request: https://github.com/python/cpython/pull/26453

___
Python tracker 

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

[issue42085] Add dedicated slot for sending values

[Irit Katriel]

Irit Katriel  added the comment:


New changeset 0b11c429c7f1721d9ffb9ae19e3e8e2e7bd6444d by Martmists in branch 
'main':
bpo-42085: [docs] Add versionadded for am_send in type object documentation 
(GH-25465)
https://github.com/python/cpython/commit/0b11c429c7f1721d9ffb9ae19e3e8e2e7bd6444d


--
nosy: +iritkatriel

___
Python tracker 

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

[issue42085] Add dedicated slot for sending values

[Martmists]

Change by Martmists :


--
nosy: +martmists
nosy_count: 4.0 -> 5.0
pull_requests: +25048
pull_request: https://github.com/python/cpython/pull/25465

___
Python tracker 

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

[issue44264] Add descriptive error message when environment variable not detected

[David Gene]

New submission from David Gene :

Using os.environ[KEY] with a non-existent environment variable key only gives a 
simple KeyError, which may be fine for a developer to understand, but if a user 
of a Python program were to come across it, it may not indicate what they 
needed to do to avoid the crash. I would raising the keyError with a message 
such as "Environment variable '{}' not set".

--
messages: 394735
nosy: astrosticks
priority: normal
pull_requests: 25047
severity: normal
status: open
title: Add descriptive error message when environment variable not detected
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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
pull_requests: +25046
pull_request: https://github.com/python/cpython/pull/26452

___
Python tracker 

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

[issue38768] [feature request] Add lldb equivalent to Tools/gdb

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

This looks useful: https://lldb.llvm.org/use/python.html

--

___
Python tracker 

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

[issue44263] Better explain the GC contract for PyType_FromSpecWithBases

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset d8ce746e7c5193757c8d316105870b0dc5d6fa53 by Miss Islington (bot) 
in branch '3.10':
bpo-44263: Mention PyType_Ready in the gc protocol warning (GH-26445) (#26446)
https://github.com/python/cpython/commit/d8ce746e7c5193757c8d316105870b0dc5d6fa53


--

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Ben Darnell]

Ben Darnell  added the comment:

> The maintenance burden of the introduced deprecation should be pretty low.

This is going to cause an unpleasant amount of churn in the Tornado community. 
It's been idiomatic (going back 12 years now) to do all your setup in 
synchronous code before starting the event loop. I'm tempted to restore the 
implicit loop creation in Tornado's `IOLoop.current()` (which is now 
essentially a wrapper around `asyncio.get_event_loop()`).

> It leads to weird errors when get_event_loop() is called at import-time and 
> asyncio.run() is used for asyncio code execution.

*Checks asyncio.run's implementation* Oh, I can see how that's a problem (and 
I've been giving people bad advice about the interchangeability of Tornado's 
IOLoop.run_sync and asyncio.run). But why does `asyncio.run` unconditionally 
create a new event loop instead of running on `asyncio.get_event_loop`? If 
asyncio.run used asyncio.get_event_loop it seems to me that we'd have the 
expected behavior and wouldn't have to make breaking changes to get_event_loop. 

> Low-level new_event_loop()/loop.run_until_complete() are still present to run 
> async code if top-level run() is not suitable for any reason.

What if you're using run_forever instead of run_until_complete? (this is the 
common mode of operation for Tornado) There are solutions, of course (my 
preferred one is `await asyncio.Event().wait()`), but it's an extra conceptual 
hurdle to throw at users in a "hello world" example and this is why I've stuck 
with the model that uses (the equivalent of) run_forever instead of asyncio.run.

--
nosy: +Ben.Darnell

___
Python tracker 

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

[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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

[issue42125] linecache cannot get source for the __main__ module with a custom loader

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[hai shi]

Change by hai shi :


--
pull_requests: +25045
pull_request: https://github.com/python/cpython/pull/26451

___
Python tracker 

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

[issue24132] Direct sub-classing of pathlib.Path

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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

[issue44258] Support PEP 515 for Fraction's initialization from string

[Mark Dickinson]

Mark Dickinson  added the comment:

> How about '1_/_2'?

I'd rather keep it consistent with the rules for int: that is, if I split on 
`'/'`, I'd expect the pieces to be parseable by `int`.

As for spaces around the `/`, let's make that a separate issue.

--

___
Python tracker 

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

[issue44258] Support PEP 515 for Fraction's initialization from string

[Vedran Čačić]

Vedran Čačić  added the comment:

How about '1_/_2'? I think making / more separated adds value... though of 
course, someone will ask about '1 / 2' next. :-)

--
nosy: +veky

___
Python tracker 

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

[issue34219] distutils: build_ext -D wrongly assume defining a symbol with no value

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +steve.dower

___
Python tracker 

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

[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules

[Nils Kattenbeck]

Nils Kattenbeck  added the comment:

What is/was the initial reason to not preserve the MRO for a TypedDict?
The only thing which came to my mind would be instantiation performance but as 
annotations are not evaluated by default and on the right-hide side of 
assignment most people will use dict literals I am not sure if this is still 
relevant. Otherwise it might even be simpler to just preserve the original 
bases in TypedDict but please correct me if I overlooked something

--
nosy: +Nils Kattenbeck

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> The standard library has clear rules regarding how previously working 
> interfaces should be deprecated, and this changeset is violating those. At no 
> point was documented that relying on the list/dict trait of the existing 
> interface is not part of the interface.

Thanks Gábor for chiming in.

A minor correction, the "dict" trait was documented, and compatibility is 
retained for that trait.

It's only the "list" trait of the less-commonly-used 
"Distribution.entry_points" that's a concern here, and I've yet to see an 
example of it being an actual concern. I've already offered to add 
compatibility if a compelling use case is presented.

> I don't think the importlib libraries are special enough to warrant exclusion 
> from this rule (as opposed let's say the zoneinfo).

The docs do explicitly call out that the module is provisional. 
https://docs.python.org/3/library/importlib.metadata.html

Still, I believe it's best for this module to honor the stdlib practices as 
best as possible, and I believe the indicated change does that.

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> there's the tuple subclass which pretends to be a dict.

There's no tuple subclass that's pretending to be a dict. It overrides 
__getitem__ for convenience. It never claims to support Mapping.

> mypy complains about incorrect types in overrides for both.

I'm unsure what the concern is. If there's an issue, it hasn't been reported to 
the project. importlib_metadata runs mypy tests with the test suite (all 
passing) and [twine uses the API with strict mypy checking 
enabled](https://github.com/pypa/twine/blob/eff3a454df49c6e998d3d21d07ef846d8318e446/twine/cli.py#L43-L69)
 without any exclusions.

> the worst part of this is that the `__getitem__` moves from O(1) to O(N) (in 
> some private code this makes importlib.metadata on 3.10 _10x slower than on 
> 3.9_)

This issue was revealed during the review and I acknowledged the concern and 
agreed to address the issue if it mattered. This project has demonstrated its 
concern for performance issues as are apparent through a number of 
optimizations in the changelog. In every use case I've seen, the performance is 
improved by the current approach (a group/sort operation is avoided). If the 
performance is a concern, I once again welcome a bug report describing the 
use-case and the impact, though I suspect it's an isolated case and likely 
would best be addressed outside the official codebase.

> this is an api break with 3.9 which returned a `list`

I acknowledge this break, though I believe the concerns are overblown. The API 
specifically sought to reduce dependence on receiving a list and instead to 
provide a more abstract collection. 

> I don't think [introducing behavior in backports] is appropriate.

It's true, the "backport" monkier is a false one here. From the very beginning, 
these modules first introduced their behavior outside the stdlib and were then 
ported into CPython. Moreover, the past couple of years have seen substantial 
refinement and innovation and was able to move much faster and reach stability 
much faster and with wider adoption than if the library had followed the 
stardard Python development cadence.

It's quite likely that this project will eventually stabilize to the point that 
most users do not need the backport, but while it exists, it's providing 
massive value. Consider the most recent example 
(https://importlib-metadata.readthedocs.io/en/latest/history.html#v4-3-1) where 
a performance improvement caused a regression. The regression was detected and 
fixed within a day. Now when CPython adopts that behavior, we can all have 
higher confidence in the viability of the implementation.

It would be a pretty big shift to block this approach, but it's not out of the 
realm of consideration. Still, it's out of scope for this discussion. Feel free 
to raise it separately.

> [the typing issues] were *trivially solved* by a dictionary comprehension

No such solution was proposed by anybody, but more importantly, I don't believe 
the solution would have been so trivial and still met the objectives.

> the types describing the new apis require *significant* `# type: ignore`s to 
> pass mypy because they violate basic substitutability.

I'm unaware of this issue and it's not been reported, but I also don't believe 
it's an issue. Both twine and keyring have adopted the latest API and pass mypy 
tests.

> they also cannot be used in any of the contexts they were appropriate for in 
> <3.10 (Dict[str, List[EntryPoint]] or List[Entrypoint] depending on the api).

That's right. The API has changed.

> many issues on importlib-metadata

Where "many" ~= 1 
(https://github.com/python/importlib_metadata/issues?q=is%3Aissue+DeprecationWarning).

> many issues linking to your deprecation issue

Do you mean https://github.com/python/importlib_metadata/pull/289 or something 
else? I see ~4 projects (astropy, pytest-randomly, keyring, virtualenv) making 
mention there. I'd expected the number of projects to be affected to be more 
than that.

> there is significant toil

I care about toil. A lot. I don't make incompatible changes lightly, and I 
spent a good deal of time documenting the motivations and providing guidance on 
how to transition. I've actively worked with each project that's requested help 
to minimize their toil and provide a one-shot transition to the new API.

> if you look at your issue tracker it has been reported before and by others

I looked and didn't find it. Help me see what I'm missing.

> "the testsuite didn't demonstrate this usecase so I'm free to change it"

That's not the spirit of my words. The API had an intended usage that was borne 
out by the documentation and tests. If users relied on other interfaces that 
were incidentally present, the user bears some risk in relying on those 
behaviors. Still, I accept responsibility to provide a transitional support 
even for those cases.

--
nosy:  -gaborjbernat

___
Python tracker 

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[gaborjbernat]

gaborjbernat  added the comment:

After reading through the points here, I must say I agree with Anthony here. 
The standard library has clear rules regarding how previously working 
interfaces should be deprecated, and this changeset is violating those. At no 
point was documented that relying on the list/dict trait of the existing 
interface is not part of the interface. I don't think the importlib libraries 
are special enough to warrant exclusion from this rule (as opposed let's say 
the zoneinfo).

--
nosy: +gaborjbernat

___
Python tracker 

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

[issue44254] Change turtledemo button colors

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 9bcb76c24f6d3f01e596a439c1521f9099e3fe80 by Miss Islington (bot) 
in branch '3.9':
bpo-44254: On Mac, remove disfunctional colors from turtledemo buttons 
(GH-26448)
https://github.com/python/cpython/commit/9bcb76c24f6d3f01e596a439c1521f9099e3fe80


--

___
Python tracker 

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

[issue44100] test__xxsubinterpreters: test_one() fails in AMD64 Fedora Stable 3.x: "Fatal Python error: Py_EndInterpreter: thread still has a frame"

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

I'm not sure *but* in the DestroyTests.test_one id1 and id3 were never 
explicitly destroyed. Can it be related?

--
nosy: +shreyanavigyan

___
Python tracker 

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

[issue44254] Change turtledemo button colors

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset addd32986f703e692463828ac0014023a901010f by Miss Islington (bot) 
in branch '3.10':
bpo-44254: On Mac, remove disfunctional colors from turtledemo buttons 
(GH-26448)
https://github.com/python/cpython/commit/addd32986f703e692463828ac0014023a901010f


--

___
Python tracker 

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

[issue44259] lib2to3 does not accept "exec" as name

[Mulugruntz]

Mulugruntz  added the comment:

Sorry, I forgot to mention:
macOS Mojave 10.14.5 (18F132)

--

___
Python tracker 

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

[issue44259] lib2to3 does not accept "exec" as name

[Mulugruntz]

Mulugruntz  added the comment:

Traceback (most recent call last):
  File "/Users/sgiffard/Library/Application 
Support/JetBrains/PyCharm2020.3/scratches/scratch_24.py", line 9, in 
driver.parse_string("""class C:\ndef exec(self): pass\n""")
  File 
"/usr/local/Cellar/python@3.9/3.9.5/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib2to3/pgen2/driver.py",
 line 103, in parse_string
return self.parse_tokens(tokens, debug)
  File 
"/usr/local/Cellar/python@3.9/3.9.5/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib2to3/pgen2/driver.py",
 line 71, in parse_tokens
if p.addtoken(type, value, (prefix, start)):
  File 
"/usr/local/Cellar/python@3.9/3.9.5/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib2to3/pgen2/parse.py",
 line 162, in addtoken
raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=1, value='exec', context=(' ', 
(2, 8))

--

___
Python tracker 

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

[issue44254] Change turtledemo button colors

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset af5a324843de395cecc562cb0c757b3768f2077f by Terry Jan Reedy in 
branch 'main':
bpo-44254: On Mac, remove disfunctional colors from turtledemo buttons 
(GH-26448)
https://github.com/python/cpython/commit/af5a324843de395cecc562cb0c757b3768f2077f


--

___
Python tracker 

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

[issue44254] Change turtledemo button colors

[miss-islington]

Change by miss-islington :


--
pull_requests: +25044
pull_request: https://github.com/python/cpython/pull/26450

___
Python tracker 

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

[issue44254] Change turtledemo button colors

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +25043
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26449

___
Python tracker 

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