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

[Irit Katriel]

Irit Katriel  added the comment:

> os.environ defines the __delitem__ method to call C unsetenv(). Thus `del 
> os.environ[varname]` does unset the environment variable, at least at the 
> level of the C runtime.


For the current process, yes. But it's not that what the user needs to do to 
fix the problem is to define an environment variable and rerun the program.

--

___
Python tracker 

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

[issue46524] test_peg_generator takes 8 minutes on Windows

[Gregory P. Smith]

Gregory P. Smith  added the comment:

re: slow tests in the first half of the list.  the same total amount of time is 
going to be spent regardless.  In our test suite on a modern fast 16 thread 
system, all but 10 tests are completed in parallel within the first 30 seconds. 
 The remaining ~10 take 10x+ that wall time more minutes.

So the most latency you will shave off on a modern system is probably <30 
seconds.  On a slower system the magnitude of that will remain the same in 
proportion.  CI systems are not workstations.  On -j1 or -j2 system I doubt it 
will make a meaningful difference at all.

Picture test execution as a utilization graph:

```
|ttt
|   
|   ttt
|  tt
+
```

The total area under that curve is going to remain the same no matter what so 
long as we execute everything.  Reordering the tests can pull the final long 
tail in a bit by pushing out the top layer.  You move more towards an optimal 
rectangle, but you're still limited by the area.  **The less -jN parallelism 
you have as CPU cores the less difference any reordering change makes.**

What actual parallelism do our Github CI systems offer?

The fundamental problem is that we do a LOT in our test suite and have no 
concept of what depends on what and thus _needs_ to be run.  So we run it all.  
For specialized tests like test_peg_generator and test_tools it should be easy 
to determine from a list of modified files if those tests are relevant.

That gets a lot more complicated to accurately express for things like 
test_multiprocessing and test_concurrent_futures.

test_peg_generator and test_tools are also *packages of tests* that themselves 
should be parallelized individually instead of considered a single serialized 
unit.

At work we even shard test methods within TestCase classes so that big ones can 
be split across test executor tasks: See the _setup_sharding() function in 
absltest here: 
https://github.com/abseil/abseil-py/blob/main/absl/testing/absltest.py#L2368

In absence of implementing an approach like that within test.regrtest to shard 
at a more granular level thus enabling us to approach the golden rectangle of 
optimal parallel test latency, we're left with manually splitting long running 
test module/packages up into smaller units to achieve a similar effect.

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

[issue46571] Strange `@typing.no_type_check` behavior for class variables

[Nikita Sobolev]

Nikita Sobolev  added the comment:

## 1. What is documented?

The docs makes this even more weird!

> @typing.no_type_check
> Decorator to indicate that annotations are not type hints.
> This works as class or function decorator. With a class, it applies 
> recursively to all methods defined in that class (but not to methods defined 
> in its superclasses or subclasses).
> This mutates the function(s) in place.

https://docs.python.org/3/library/typing.html#typing.no_type_check

Docs do not mention modifing nested classes at all! So, it looks like the `(1)` 
solution.

## 2. What does it do now?

It modifies nested types, even ones used in assignments.

## 3. How is that used by runtime type inspectors?

I've made a little research:

1. Hypothesis (I help with maintaining its typing API) does not support 
`@no_type_check` at all: 
https://github.com/HypothesisWorks/hypothesis/issues/3225

2. Pydantic, looks like `@no_type_check` does not change anything at all.


```
from pydantic import BaseModel
from typing import no_type_check

@no_type_check  # the same with and without this decorator
class MyModel(BaseModel):
a: int

print(MyModel(a=1))  # ok
print(MyModel(a='1a'))  # ok
# pydantic.error_wrappers.ValidationError: 1 validation error for MyModel
# a: value is not a valid integer (type=type_error.integer)
```

So, it always tries to coerce types. Docs: 
https://pydantic-docs.helpmanual.io/usage/types/

They also use it inside their own code-base: 
https://github.com/samuelcolvin/pydantic/search?q=no_type_check Probably for 
`mypy` to be happy.

3. `dataclasses` and `attrs` - nothing changes. Both do not use neither 
`@no_type_check` nor `get_type_hints` inside.

Attrs: https://github.com/python-attrs/attrs/search?q=get_type_hints

4. Beartype: https://github.com/beartype/beartype

> We've verified that @beartype reduces to the identity decorator when 
> decorating unannotated callables. That's but the tip of the iceberg, though. 
> @beartype unconditionally reduces to a noop when:
> The decorated callable is itself decorated by the PEP 484-compliant 
> @typing.no_type_check decorator.

So, as far as I understand, they only have `@no_type_check` support for 
callables. Related test: 
https://github.com/beartype/beartype/blob/50b213f315ecf97ea6a42674defe474b8f5d7203/beartype_test/a00_unit/a00_util/func/pep/test_utilpep484func.py

So, to conclude, some project might still rely on current behavior that nested 
types are also implicitly marked as `@no_type_check`, but I cannot find any 
solid proof for it.

The noticable thing is that this never came up before in ~6 years while this 
logic exists: 
https://github.com/python/cpython/blame/8fb36494501aad5b0c1d34311c9743c60bb9926c/Lib/typing.py#L1969-L1970

It helps to prove my point: probably, no one uses it.

## 3. How is that used by runtime type inspectors?
## 4. What would be most useful to runtime type inspectors?

With all the information I gathered, I've changed my opinion :)
Now I think that we should drop the part with modifing nested types at all 
(`(1)` solution). Only a type with `@no_type_check` should be modified.

This is what docs say. This will also solve the original problem.
Even if someone relies on current behavior: the fix is not hard, just add 
`@no_type_check` to nested types as well.

So, do others have any objections / comments / feedback? :)

--

___
Python tracker 

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

[issue46578] cant DEBUG os.spawnv()

[michaellongge]

New submission from michaellongge :

When i try to execute --link.exe *.obj-- on windows 11, i get one error
LIB : fatal error LNK1181: cannot open input file 'Files.obj'
It looks like a space path error
so i run [os.spawnv(link.exe)] alone try to find out where made this error.
But i cant DEBUG os.spawnv() on Pycharm.
When the cursor on os.spawnv() line then press [Step Into], cursor jump to 
ntpath.py (216) it's in "def basename()"  not in os.py "def spawnv()"

so this issue contain 2 parts
1.space error such as "Program Files (x86)"
2.DEBUG cant jump to right place

Here is my salmpe code.I have tried python3.8 and python3.10 both same error
```
import os

executable= 
'D:\\VS2022\\VC\\Tools\\MSVC\\14.30.30705\\bin\\HostX86\\x64\\link.exe'

cmd310 = ["/LIBPATH:D:\\python310\\lib\\site-packages\\torch\\lib", 
"/LIBPATH:D:\\python310\\libs", "/LIBPATH:D:\\python310\\PCbuild\\amd64", 
"/LIBPATH:D:\\VS2019\\VC\\Tools\\MSVC\\14.29.30133\\ATLMFC\\lib\\x64", 
"/LIBPATH:D:\\VS2019\\VC\\Tools\\MSVC\\14.29.30133\\lib\\x64", 
"/LIBPATH:C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.8\\lib\\um\\x64", 
"/LIBPATH:C:\\Program Files (x86)\\Windows 
Kits\\10\\lib\\10.0.19041.0\\ucrt\\x64", "/LIBPATH:C:\\Program Files 
(x86)\\Windows Kits\\10\\lib\\10.0.19041.0\\um\\x64", 
"/LIBPATH:D:\\VS2019\\VC\\Tools\\MSVC\\14.29.30133\\lib\\x64", 
"/LIBPATH:D:\\VS2019\\VC\\Tools\\MSVC\\14.29.30133\\atlmfc\\lib\\x64", 
"/LIBPATH:D:\\VS2019\\VC\\Auxiliary\\VS\\lib\\x64", "/LIBPATH:C:\\Program Files 
(x86)\\Windows Kits\\10\\Lib\\10.0.19041.0\\ucrt\\x64", "/LIBPATH:C:\\Program 
Files (x86)\\Windows Kits\\10\\Lib\\10.0.19041.0\\ucrt_enclave\\x64", 
"/LIBPATH:C:\\Program Files (x86)\\Windows 
Kits\\10\\Lib\\10.0.19041.0\\um\\x64", "/LIBPATH:C:\\Program Files (x86)
 \\Windows Kits\\NETFXSDK\\4.8\\lib\\um\\x64", "/LIBPATH:D:\\python310\\libs", 
"c10.lib", "torch.lib", "torch_cpu.lib", "torch_python.lib"]
rc = os.spawnv(os.P_WAIT, executable, cmd310)
```

--
components: Build
messages: 412129
nosy: michaellongge
priority: normal
severity: normal
status: open
title: cant DEBUG os.spawnv()
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

[issue46574] itertools.count should work with non-number types

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the suggestion but I'm going to decline.

* The need for this is very low.  

* It's easy to roll your own.

* The code for `count('', 'a')` and `count((), (1,))` isn't intelligible.

* Without special casing, the code for `count('', 'a')` and `count((), (1,))` 
is highly inefficient.  We advise people not to use the 's = s + t' pattern in 
a loop for sequences because it leads to quadratic behavior.

--
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
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

[issue46524] test_peg_generator takes 8 minutes on Windows

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

See also https://bugs.python.org/issue46576 and 
https://github.com/python/cpython/pull/31015

--
nosy: +xtreak

___
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

[Eryk Sun]

Eryk Sun  added the comment:

This is just a point of clarification.

> my del did not change the environment variable

os.environ defines the __delitem__ method to call C unsetenv(). Thus `del 
os.environ[varname]` does unset the environment variable, at least at the level 
of the C runtime.

--
nosy: +eryksun

___
Python tracker 

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

[issue46576] test_peg_generator is extremely slow

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

See also issue46524 for a similar discussion.

--
nosy: +xtreak

___
Python tracker 

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

[issue46577] Hostname spoofing via backslashes in URL

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This seems to be similar to https://bugs.python.org/issue35748

--
nosy: +xtreak

___
Python tracker 

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

[issue46521] codeop._maybe_compile passes code with error + triple quotes

[Terry J. Reedy]

Terry J. Reedy  added the comment:

With my fix to the PR:

>>> a b '''
SyntaxError: unterminated triple-quoted string literal (detected at line 1)
>>> a '''
...

The message is off, and can be left for another issue (or not), but the 
behavior is correct.

With the hack removed, all the tests in test_codeop that the hack works can be 
removed and replaced by a simple test that a code object, error, or None are 
returned in 3 different cases.

--

___
Python tracker 

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

[issue46558] Quadratic time internal base conversions

[Tim Peters]

Tim Peters  added the comment:

Addendum: the "native" time (for built in str(a)) in the msg above turned out 
to be over 3 hours and 50 minutes.

--

___
Python tracker 

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

[issue3451] Asymptotically faster divmod and str(long)

[Tim Peters]

Tim Peters  added the comment:

Ha! This will never die. More discussion in bpo-46558.

Ya, I already closed it, but don't want to. I opened it to begin with to record 
an int->str method that doesn't use division, so it didn't really belong on 
this report.

What if we _didn't_ convert these things to C? That's the primary question the 
new report gets around to asking. These things are far easier to write, 
understand, and maintain in Python, and converting to C is generally only 
improving a constant factor, or _maybe_ removing a log(n) factor. When we're 
looking at massive O() improvements, squeezing those out is of comparatively 
little value.

--
nosy: +tim.peters

___
Python tracker 

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

[issue46558] Quadratic time internal base conversions

[Tim Peters]

Tim Peters  added the comment:

The test case here is a = (1 << 1) - 1, a solid string of 100 million 1 
bits. The goal is to convert to a decimal string.

Methods:

native: str(a)

numeral: the Python numeral() function from bpo-3451's div.py after adapting to 
use the Python divmod_fast() from the same report's fast_div.py.

todecstr: from the Python file attached to this report.

gmp: str() applied to gmpy2.mpz(a).

Timings:

native: don't know; gave up after waiting over 2 1/2 hours.
numeral: about 5 1/2 minutes.
todecstr: under 30 seconds. (*)
gmp: under 6 seconds.

So there's room for improvement ;-)

But here's the thing: I've lost count of how many times someone has whipped up 
a pure-Python implementation of a bigint algorithm that leaves CPython in the 
dust. And they're generally pretty easy in Python.

But then they die there, because converting to C is soul-crushing, losing the 
beauty and elegance and compactness to mountains of low-level details of 
memory-management, refcounting, and checking for errors after every tiny 
operation.

So a new question in this endless dilemma: _why_ do we need to convert to C? 
Why not leave the extreme cases to far-easier to write and maintain Python 
code? When we're cutting runtime from hours down to minutes, we're focusing on 
entirely the wrong end to not settle for 2 minutes because it may be 
theoretically possible to cut that to 1 minute by resorting to C.


(*) I hope this algorithm tickles you by defying expectations ;-) It 
essentially stands `numeral()` on its head by splitting the input by a power of 
2 instead of by a power of 10. As a result _no_ divisions are used. But instead 
of shifting decimal digits into place, it has to multiply the high-end pieces 
by powers of 2. That seems insane on the face of it, but hard to argue with the 
clock ;-) The "tricks" here are that the O(log log n) powers of 2 needed can be 
computed efficiently in advance of any splitting, and that all the heavy 
arithmetic is done _in_ the `decimal` module, which implements 
fancier-than-Karatsuba multiplication and whose values can be converted to 
decimal strings very quickly.

--

___
Python tracker 

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

[issue46554] Add append keyword argument to Path.write_text() and Path.write_bytes()

[Keelung Yang]

Keelung Yang  added the comment:

Without append kwarg, users need two lines to append. It's bad to both 
readability and writability.

Library developers should focus on bath language and library's design targets, 
but how frequently used. And as all discussed here, at least one applications 
scene(logging) benefited from append kwarg. Right?

--

___
Python tracker 

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

[issue46577] Hostname spoofing via backslashes in URL

[Dashmeet Kaur Ajmani]

New submission from Dashmeet Kaur Ajmani :

A URL's hostname can be spoofed by using a backslash (\) character followed by 
an at (@) character. If the hostname is used in security decisions, the 
decision may be incorrect.

Impact: Depending on library usage and attacker intent, impacts may include 
allow/block list bypasses, SSRF attacks, open redirects, or other undesired 
behavior.

Example URL: "http://google.com:80\\@yahoo.com/#what\\is going on"

Expected behaviour (as returned by NPM urijs):
{
 "scheme": "http",
 "user": "",
 "password": "",
 "host": "google.com",
 "port": "",
 "path": "@yahoo.com/",
 "query": "",
 "fragment": "what\\is going on"
}

Actual behaviour:
{
 "scheme": "http",
 "user": "google.com",
 "password": "80\\",
 "host": "yahoo.com",
 "port": "",
 "path": "/",
 "query": "",
 "fragment": "what\\is going on"
}

Expected version is the behavior of other parsers which implement the WHATWG 
URL specification, including web browsers and Node's built-in URL class.

Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26291

--
components: Library (Lib)
messages: 412118
nosy: meetdash
priority: normal
severity: normal
status: open
title: Hostname spoofing via backslashes in URL
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

[issue46400] Please update bundled libexpat to 2.4.4 with security fixes

[sping]

sping  added the comment:

2.4.4 with more security fixes has been released, adjusting the ticket to be 
about updating to 2.4.4 now.

--
title: Please update bundled libexpat to 2.4.3 with security fixes -> Please 
update bundled libexpat to 2.4.4 with security fixes

___
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

[Irit Katriel]

Irit Katriel  added the comment:

I vote to reject this proposal. Unless another core dev disagrees, I will close 
this issue.

--
status: pending -> open

___
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

[Irit Katriel]

Irit Katriel  added the comment:

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

The user of a program should not see this exception. The program should 
translate it to an error that would make sense to the user.

--
resolution:  -> rejected
status: open -> pending

___
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

[Irit Katriel]

Irit Katriel  added the comment:

It's not necessarily true that the environment variable is not set just because 
the key is not in os.environ. In this example my del did not change the 
environment variable:

>>> import os
>>> os.environ['TMPDIR']
'/var/folders/kf/0v7kz3ps62dg11v9rq0sz35mgn/T/'
>>> del os.environ['TMPDIR']
>>> os.environ['TMPDIR']
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 678, in __getitem__
KeyError: 'TMPDIR'

--
nosy: +iritkatriel

___
Python tracker 

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

[issue46521] codeop._maybe_compile passes code with error + triple quotes

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thank you for the PR. As I wrote on my preliminary review, I see this likely 1 
failure that might may be in the test fixture. Will test and debug later.

--

___
Python tracker 

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

[issue30210] No Documentation on tkinter dnd module

[Irit Katriel]

Irit Katriel  added the comment:

Doc was added under issue25237:

https://docs.python.org/3/library/tkinter.dnd.html

--
nosy: +iritkatriel
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Add doc for tkinter commondialog.Dialog and subclasses

___
Python tracker 

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

[issue46572] Unicode identifiers not necessarily unique

[Diego Argueta]

Diego Argueta  added the comment:

I did read PEP-3131 before posting this but I still thought the behavior was 
counterintuitive.

--

___
Python tracker 

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

[issue43359] Dead assignment in Py_UniversalNewlineFgets

[Irit Katriel]

Irit Katriel  added the comment:

That function has been edited in the meantime and this line is no longer there.

--
nosy: +iritkatriel
resolution:  -> out of date
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

[issue43361] Dead assignment in idna_converter function

[Irit Katriel]

Irit Katriel  added the comment:

I don't think removing this will make the code easier to read. It's an exercise 
to verify that all the different if-else branches set this variable.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue29172] blake2: Use lowest-common denominator signature of #pragma pack

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> BETA report: Python-3.6 build messages to stderr: AIX and "not 
GCC"

___
Python tracker 

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

[issue46574] itertools.count should work with non-number types

[Vedran Čačić]

Vedran Čačić  added the comment:

At one moment, I had a need for 

itertools.count(datetime.date.today(), datetime.timedelta(days=1))

Of course, it was no problem to write it myself, but still, it would be 
incredibly neat if it simply worked.

--
nosy: +veky

___
Python tracker 

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

[issue41416] Restore default implementation of __ne__ in mixins Set and Mapping

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +29195
pull_request: https://github.com/python/cpython/pull/21628

___
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

[ntrischi]

ntrischi  added the comment:

Compiling Python3.8.9 from source on Windows 10 with VS2019. Running 
PCBuild\build.bat, I'm getting the following issue: 

C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\um\winnt.h(253): 
error RC2188: 
C:\Python-3.8.9\PCbuild\obj\38amd64_Release\pythoncore\RCa09752(53) : fatal 
error RC1116: RC terminating after preprocessor errors 
[C:\Python-3.8.9\PCbuild\pythoncore.vcxproj]

I noticed this issue is closed but it doesn't seem to be resolved.

--
nosy: +ntrischi
versions: +Python 3.8

___
Python tracker 

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

[issue46548] macOS installers cannot be signed on Monterey

[Ned Deily]

Ned Deily  added the comment:

The short answer to the original issue: at the moment, build-installer.py 
continues to create python.org installers in the legacy bundle installer format 
that is no longer supported by more modern versions of macOS and there are 
additional steps that are used to convert the artifacts produced by 
build-installer.py into a modern flat-package (.pkg) format installer. Those 
steps are outlined in Mac/BuildScript/README.rst but the exact commands are not 
provided there. The longer answer is that we have long provided macOS 
installers that are designed to work on a very wide range of macOS versions and 
Mac hardware. Up until very recently, the production of an installer required 
multiple steps on different versions of macOS to be able to meet those 
requirements, i.e. the build of Python itself had to run on an older system 
(macOS 10.9) but the flat package and signing has to run on a more recent 
system to be able to be notarized by Apple. And that manufacturing has evolved 
over many years 
 as Apple has attempted to enhance macOS security while minimizing the impact 
on end users (e.g. Gatekeeper, code signing, notarization). As of fairly 
recently (Python 3.10.1 et al) with the addition to Python of full 
"weaklinking" support on macOS (along with Apple Silicon and Big Sur support), 
it is now possible to build on a current system while supporting older systems 
as well as we now do in the new universal2 installer variant. Since we are 
still providing the legacy 10.9 Intel-only installer variant for 3.9.x 
releases, there hasn't been an urgent need to modify the overall manufacturing 
process yet, but I do plan to do so and document prior to the upcoming 3.11 
feature code cutoff (in part to better support Apple Silicon Macs).

--
assignee:  -> ned.deily

___
Python tracker 

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

[issue46576] test_peg_generator is extremely slow

[Gregory P. Smith]

Change by Gregory P. Smith :


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

___
Python tracker 

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

[issue46548] macOS installers cannot be signed on Monterey

[Yair Frid]

Yair Frid  added the comment:

Apple builds python on their own, so probably you wont have any luck finding 
the build scripts

--
nosy: +Fongeme

___
Python tracker 

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

[issue46576] test_peg_generator is extremely slow

[Gregory P. Smith]

New submission from Gregory P. Smith :

test_peg_generator is an extremely slow test.  This bug tracks any changes to 
reduce its runtime and test latency.

--
components: Tests
messages: 412104
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: test_peg_generator is extremely slow
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

[issue46575] One-off errors in hashlib.scrypt error messages

[Ron Kaminsky]

New submission from Ron Kaminsky :

There are one-off errors in upper bounds given in the error messages for 
hashlib.scrypt(...). MAX_INT *is* accepted (and at least for maxmem, works).

See 
https://github.com/python/cpython/blob/8fb36494501aad5b0c1d34311c9743c60bb9926c/Modules/_hashopenssl.c#L1375

and 
https://github.com/python/cpython/blob/8fb36494501aad5b0c1d34311c9743c60bb9926c/Modules/_hashopenssl.c#L1382

With thanks to everyone involved for all the fine work on Python!

--
messages: 412103
nosy: ron_kaminsky
priority: normal
severity: normal
status: open
title: One-off errors in hashlib.scrypt error messages
type: behavior

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Eryk Sun]

Eryk Sun  added the comment:

In Windows, paths that are relative to the current directory on a drive aren't 
resolved. The following should be resolved by the current code:

>>> os.chdir('C:/Temp')
>>> pathlib.Path('C:').absolute()
WindowsPath('C:')

But _from_parts() has bugs with drive-relative paths. 

Assuming the bugs are fixed, when a path has a drive, Path.absolute() should 
resolve against abspath(self.drive) instead of getcwd().

--

___
Python tracker 

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

[issue38682] struct timeval is not declared

[Irit Katriel]

Irit Katriel  added the comment:

timval is defined in sys/time.h.

This would be something to do with your setup, but you did not provide any 
information about your system and the steps you took to get to this point so 
it's hard to know what happened.

In any case, 3.7 is no longer maintained so I am closing this. Please create a 
new issue, with more information, if you are seeing this problem on a current 
version (>= 3.9).

--
nosy: +iritkatriel
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

[issue39339] ProcessPoolExecutor() Exception in thread QueueManagerThread

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ProcessPoolExecutor(max_workers=64) crashes on Windows

___
Python tracker 

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

[issue40174] HAVE_CLOCK_GETTIME not repected in pytime.c

[Irit Katriel]

Irit Katriel  added the comment:

> For my information, is there a kind of committee or someone taking these 
> kinds of decisions or at least expressing rules as to the spirit in which 
> they should be made?


You can bring this up on the python-ideas mailing list if you want to pull in 
additional core developers into the discussion.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Barney Gale]

Barney Gale  added the comment:

Now that GH 26153 is merged, I think this bug can be resolved.

--

___
Python tracker 

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

[issue39711] SIGBUS and core dumped during tests of 3.8.1

[Irit Katriel]

Irit Katriel  added the comment:

Looks like you ran out of disk space: OSError: [Errno 12] Not enough space


In any case, 3.8 is no longer maintained, so I am closing this as out of date. 
Please create a new issue if you are having problems with a current version (>= 
3.9).

--
nosy: +iritkatriel
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

[issue44031] test_embed and test_tabnanny fails if the current directory is non-ASCII

[Irit Katriel]

Irit Katriel  added the comment:

test_embed does not fail anymore.

--

___
Python tracker 

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

[issue44031] test_embed and test_tabnanny fails if the current directory is non-ASCII

[Irit Katriel]

Change by Irit Katriel :


--
type: compile error -> behavior
versions: +Python 3.10, Python 3.11 -Python 3.8

___
Python tracker 

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

[issue44031] test_embed and test_tabnanny fails if the current directory is non-ASCII

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
nosy: +iritkatriel
nosy_count: 4.0 -> 5.0
pull_requests: +29193
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31014

___
Python tracker 

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

[issue46572] Unicode identifiers not necessarily unique

[Eryk Sun]

Eryk Sun  added the comment:

Please read "Identifiers and keywords" [1] in the documentation. For example:

>>> import unicodedata as ud
>>> ud.normalize('NFKC', '햇햆햗') == 'bar'
True

>>> c = '\N{CYRILLIC SMALL LETTER A}'
>>> ud.name(ud.normalize('NFKC', c))
'CYRILLIC SMALL LETTER A'

---
[1] 
https://docs.python.org/3/reference/lexical_analysis.html?highlight=nfkc#identifiers

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

___
Python tracker 

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

[issue46574] itertools.count should work with non-number types

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +29192
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31013

___
Python tracker 

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

[issue46574] itertools.count should work with non-number types

[Mital Ashok]

New submission from Mital Ashok :

There's no reason that `count('', 'a')` for `'', 'a', 'aa', ...` or `count((), 
(1,))` for `(), (1,), (1, 1), ...` shouldn't work.

count(a, b) should be equivalent to accumulate(chain((a,), repeat(b)))

The docs don't strongly suggest that it won't work (it says *start* is a 
number, but the "roughly equivalent to" generator would work for str/tuple/etc)

--
components: Library (Lib)
messages: 412095
nosy: Mital Ashok
priority: normal
severity: normal
status: open
title: itertools.count should work with non-number types
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

[issue12010] Compile fails when sizeof(wchar_t) == 1

[Irit Katriel]

Irit Katriel  added the comment:

Closing after over 10 years of no activity. (The discussion from back then 
seems to be leaning towards wont fix.)

--
nosy: +iritkatriel
resolution:  -> out of date
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

[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.

[Remy Fouquette]

New submission from Remy Fouquette :

The same problem doesn't exist on Windows.

--
components: macOS
files: issue.py
messages: 412093
nosy: ned.deily, remyrfouquette, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python modules such as pyglet or pygame crash Python when tkinter 
message boxes are opened on MacOS.
type: crash
versions: Python 3.10
Added file: https://bugs.python.org/file50597/issue.py

___
Python tracker 

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

[issue27101] Compilation of python (modules) for foreign target platform problem.

[Irit Katriel]

Irit Katriel  added the comment:

2.7 and 3.5 are no longer maintained. Please create a new issue if you are 
still having this problem with a current version (>= 3.9).

--
nosy: +iritkatriel
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

[issue46521] codeop._maybe_compile passes code with error + triple quotes

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

If we want to go with this approach, I am going to need help to fix test_idle 
as I have no idea why is failing if test_codeop passes.

--

___
Python tracker 

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

[issue46521] codeop._maybe_compile passes code with error + triple quotes

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Ugh, the approach to do that breaks super heavily test_idle :(

--

___
Python tracker 

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

[issue46520] ast.unparse produces bad code for identifiers that become keywords

[Kodiologist]

Change by Kodiologist :


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

___
Python tracker 

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

[issue46329] Split up the CALL_NO_KW and CALL_KW instructions.

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I'm reverting PR30855 for the time being given our buildbot policy.

--

___
Python tracker 

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

[issue46329] Split up the CALL_NO_KW and CALL_KW instructions.

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
Removed message: https://bugs.python.org/msg412088

___
Python tracker 

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

[issue46329] Split up the CALL_NO_KW and CALL_KW instructions.

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I'm reverting #30855 for the time being given our buildbot policy.

--

___
Python tracker 

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

[issue46329] Split up the CALL_NO_KW and CALL_KW instructions.

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +29190
pull_request: https://github.com/python/cpython/pull/31011

___
Python tracker 

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

[issue46555] Unicode-mangled names refer inconsistently to constants

[jack1142]

Change by jack1142 :


--
nosy: +jack1142

___
Python tracker 

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

[issue46521] codeop._maybe_compile passes code with error + triple quotes

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue46521] codeop._maybe_compile passes code with error + triple quotes

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>> Pablo, is there any possibility that the internal REPL parser could be 
>> wrapped, exposed to Python, and called with fake stdin/out/err objects?

I would really advise against this. Unfortunately, the state of affairs is that 
the REPL is somehow super entangled with the parser, to the point that is the 
tokenizer asking for more characters that triggers a read from stdin. Exposing 
this with some API would be super dangerous because we would be elevated to the 
"supported" level anything that works just because it happens to be close to 
what the interactive mode needs.

On the other side, codeop is fundamentally flawed in the way is built because 
relies on comparing error messages from the parser, which is a very poor way of 
handling semantic information.

What we need here is a mode of the parser that somehow raises a very specific 
error on incomplete input, but not an incorrect one. And that may be not 
immediate to implement given in how many places we can raise lexer and parser 
errors. I will give it a go, in any case

--

___
Python tracker 

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

[issue46572] Unicode identifiers not necessarily unique

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

This seems coherent with https://www.python.org/dev/peps/pep-3131/ to me. The 
parser ensures all identifiers are converted into the normal form NFKC while 
parsing; comparison of identifiers is based on NFKC.

--

___
Python tracker 

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

[issue46570] Windows support for OpenSSL 3.0

[Christian Heimes]

Christian Heimes  added the comment:

OpenSSL 3.0 support is still experimental and incomplete. 3.10 is definitely 
out of scope. 3.11 might be feasible if somebody puts in the work.

--
assignee: christian.heimes -> steve.dower

___
Python tracker 

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

[issue46572] Unicode identifiers not necessarily unique

[Diego Argueta]

New submission from Diego Argueta :

The way Python 3 handles identifiers containing mathematical characters appears 
to be broken. I didn't test the entire range of U+1D400 through U+1D59F but I 
spot-checked them and the bug manifests itself there:

Python 3.9.7 (default, Sep 10 2021, 14:59:43) 
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> foo = 1234567890
>>> bar = 1234567890
>>> foo is bar
False
>>> 햇햆햗 = 1234567890

>>> foo is 햇햆햗
False
>>> bar is 햇햆햗
True

>>> 햇햆햗 = 0
>>> bar
0


This differs from the behavior with other non-ASCII characters. For example, 
ASCII 'a' and Cyrillic 'a' are properly treated as different identifiers:

>>> а = 987654321# Cyrillic lowercase 'a', U+0430
>>> a = 123456789# ASCII 'a'
>>> а# Cyrillic
987654321
>>> a# ASCII
123456789


While a bit of a pathological case, it is a nasty surprise. It's possible this 
is a symptom of a larger bug in the way identifiers are resolved.

This is similar but not identical to https://bugs.python.org/issue46555

Note: I did not find this myself; I give credit to Cooper Stimson 
(https://github.com/6C1) for finding this bug. I merely reported it.

--
components: Parser, Unicode
messages: 412084
nosy: da, ezio.melotti, lys.nikolaou, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Unicode identifiers not necessarily unique
type: behavior
versions: 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

[issue46571] Strange `@typing.no_type_check` behavior for class variables

[Guido van Rossum]

Guido van Rossum  added the comment:

@no_type_check (introduced by PEP 484) is intended for static checkers, to 
signal to them that they shouldn't check the given function or class.

I don't think PEP 484 specifies its runtime effect -- arguably get_type_hints() 
could just ignore it. Or raise an exception when called on such a class. We 
could even argue that @no_type_check shouldn't have a runtime effect.

But before we change anything we should be guided by:

1. What is documented?
2. What does it do now?
3. How is that used by runtime type inspectors?
4. What would be most useful to runtime type inspectors?

--

___
Python tracker 

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

[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__

[Ethan Furman]

Ethan Furman  added the comment:

Good catch, thank you both.

--

___
Python tracker 

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[Andrew Svetlov]

Andrew Svetlov  added the comment:

You are welcome!

--

___
Python tracker 

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

[issue46497] IDLE macOS shortcut ctrl+S doesn’t work for show completions

[David Contreras]

David Contreras  added the comment:

I disabled the default ^space in macOS settings>Keyboard>Shortcuts>Input 
Sources>Select the Previous input source (^space)

After doing that ^space works on IDLE, nonetheless the menu shows ^S which is 
not ^space.

--
Added file: https://bugs.python.org/file50596/IDLE edit menu.jpg

___
Python tracker 

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

[issue46571] Strange `@typing.no_type_check` behavior for class variables

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Let's not jump into deprecating it.

I think (2) makes the most sense. If we can get that working reliably (using 
__qualname__ I assume), it would be my preference; otherwise we should do (1).

This problem can also affect function objects, right? `class B: meth = 
some_function`.

--

___
Python tracker 

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue46520] ast.unparse produces bad code for identifiers that become keywords

[Kodiologist]

Kodiologist  added the comment:

(Hilariously, I couldn't post this comment on bugs.python.org due to some kind 
of Unicode bug ("Edit Error: 'utf8' codec can't decode bytes in position 
208-210: invalid continuation byte"), so I've rendered 
"\U0001D555\U0001D556\U0001D557" as "DEF" in the below.)

Thanks for clarifying the terminology re: reserved words vs. keywords.

> The effect is the same as "globals()['DEF']=1" (which is the same as
> passing 'def' or anything else that normalizes to it) and that in
> turn allows ">>> DEF", which returns 1.

This doesn't quite seem to be the case, at least on Pythons 3.9 and 3.10:

>>> globals()['DEF']=1
>>> DEF
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'def' is not defined
>>> globals()['def']=1
>>> DEF
1

It looks the dictionary interface to `globals` doesn't normalize like the 
parser does.

--

___
Python tracker 

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

[issue46570] Windows support for OpenSSL 3.0

[Zachary Ware]

Change by Zachary Ware :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch
type: compile error -> 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

[issue28970] ctypes.from_buffer counterpart to actively remove the mapping

[Irit Katriel]

Change by Irit Katriel :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue46571] Strange `@typing.no_type_check` behavior for class variables

[Alex Waygood]

Alex Waygood  added the comment:

...Option 3). Deprecate @no_type_check?

Maybe we should gather some stats on how many people are using @no_type_check? 
My feeling is that it's never achieved widespread adoption, so maybe it's just 
not that useful a thing to have in the stdlib.

Anyway, the behaviour you've pointed out is nuts, so I agree that something 
needs to change here!

--

___
Python tracker 

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

[issue46571] Strange `@typing.no_type_check` behavior for class variables

[Nikita Sobolev]

Change by Nikita Sobolev :


--
type:  -> behavior

___
Python tracker 

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

[issue46571] Strange `@typing.no_type_check` behavior for class variables

[Nikita Sobolev]

New submission from Nikita Sobolev :

I was working on improving coverage and test quality of `typing.py`, when I saw 
that `@no_type_check` is quite strange.

Let's dive into this!

## Everything is correct

We will start with a basic example, that illustrates that everything works fine:

```
from typing import no_type_check, get_type_hints

class A:
x: int = 1

class B:
y: str = 'a'

print(get_type_hints(A))  # ok: {'x': }
print(get_type_hints(B))  # ok: {'y': }
```

Ok, let's move on.

## Adding `@no_type_check`

Now, adding `@no_type_check` to `B` will make the result of `get_type_hints()` 
call on it - an empty `dict`:

```
from typing import no_type_check, get_type_hints

class A:
x: int = 1

@no_type_check
class B:
y: str = 'a'

print(get_type_hints(A))  # ok: {'x': }
print(get_type_hints(B))  # ok: {}
```

This is still ok.

## Broken?

And now we can add some class-level constant to `B`, like `delegate` to show 
how it breaks `A`:

```
from typing import no_type_check, get_type_hints

class A:
x: int = 1

@no_type_check
class B:
y: str = 'a'
delegate = A  # adding this line will make `A` to have `__no_type_check__` 
as well

print(get_type_hints(A))  # {}, wait, what?
print(get_type_hints(B))  # {}, ok
```

Why is that important?

It introduces an unfortunate side-effect that can make some totally unrelated 
(!) class completely ignore `get_type_hints()` and break things like 
`pydantic`, `beartype`, `attrs, etc that rely on type hints.

By adding a class-level assignment to a class that has `@no_type_check` or 
other `no_type_check_decorator`.

Why does this happen?

It happens because `no_type_check` has this logic:

```
if isinstance(arg, type):
arg_attrs = arg.__dict__.copy()
for attr, val in arg.__dict__.items():
if val in arg.__bases__ + (arg,):
arg_attrs.pop(attr)
for obj in arg_attrs.values():
if isinstance(obj, types.FunctionType):
obj.__no_type_check__ = True
if isinstance(obj, type):
no_type_check(obj)
```

Source: 
https://github.com/python/cpython/blob/8b1b27f1939cc4060531d198fdb09242f247ca7c/Lib/typing.py#L1952-L1975

As you can see above, we traverse all `__dict__` values of the given `class` 
and for some reason recurse into all nested types. 

I think that the original goal was to handle cases like:

```
@no_type_check
class Outer:
class Inner: ...
```

And now it also affects regular assignments.

So, what can we do?

0. Nothing, it works correctly (I disagree)
1. Do not cover nested classes at all with `@no_type_check`, only cover methods
2. Only cover types that are **defined** in this class, like my `Inner` class 
example
3. Something else?

I think that `(2)` is more inline with the currect implementation, so my vote 
is for it.

I would like to implement this when we will have the final agreement :)

--
components: Library (Lib)
messages: 412073
nosy: AlexWaygood, Jelle Zijlstra, gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: Strange `@typing.no_type_check` behavior for class variables
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

[issue46570] Windows support for OpenSSL 3.0

[Jay Lee]

New submission from Jay Lee :

Steps to reproduce:
1) Compile OpenSSL 3.0 on Windows.
2) use get_externals.bat to download Python external requirements on Windows.
3) Overwrite OpenSSL 1.1.1m in externals with your OpenSSL 3.0 build.

Expected behavior:
Python will build against OpenSSL 3.0

Actual behavior:
Build fails with missing DLLs.

Further information:
- For OpenSSL 3.0 builds, the first suffix for libcrypto and libssl is -3, not 
-1_1.
- For x86_64 builds, there's also an -x64 suffix to distinguish from x86 builds.

I have a openssl.props modified file at:
https://github.com/GAM-team/actions-hello-world/blob/master/openssl.props

which I've overwritten the existing:
https://github.com/python/cpython/blob/main/PCbuild/openssl.props#L13

file with and then succesfully compiled against OpenSSL 3.0. However I'm not 
certain if or where the logic should exist to detect OpenSSL 3.0 DLLs instead 
of 1.1.

--
assignee: christian.heimes
components: Build, SSL
messages: 412072
nosy: christian.heimes, jay0lee
priority: normal
severity: normal
status: open
title: Windows support for OpenSSL 3.0
type: compile error
versions: Python 3.10, Python 3.11

___
Python tracker 

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

[issue41711] Socker send method throws a timeout exception

[Irit Katriel]

Change by Irit Katriel :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue45913] readline + GTK + Pytest Seg Fault with Python 3.7 and 3.10 on CI

[Irit Katriel]

Change by Irit Katriel :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue28982] multiprocessing.Queue.get(block=True, timeout=0) always raises queue.Empty

[Irit Katriel]

Change by Irit Katriel :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue46555] Unicode-mangled names refer inconsistently to constants

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

True is a keyword which is compiled to expression whose value is True, 핋핣핦핖 is 
an identifier which refers to the builtin variable "True" which has a value 
True by default. You can change the value of a builtin variable, but the value 
of expression True is always True.

I do not see a problem here. Don't use 핋핣핦핖 if your intention is not using a 
variable.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue46555] Unicode-mangled names refer inconsistently to constants

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

hah, this is "great":

>>> 핋핣핦핖 = 1
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': 
, '__spec__': None, 
'__annotations__': {}, '__builtins__': , 'True': 
1}

The problem is that the lexer assumes that anything that is not ASCII cannot be 
a keyword and lexes 핋핣핦핖 as an identifier.

--
nosy: +Carl.Friedrich.Bolz

___
Python tracker 

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

[issue43583] make test failures, 2 tests failed: test_embed test_tabnanny

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_embed and test_tabnanny fails if the current directory is 
non-ASCII

___
Python tracker 

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

[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__

[Nikita Sobolev]

Change by Nikita Sobolev :


--
keywords: +patch
nosy: +sobolevn
nosy_count: 3.0 -> 4.0
pull_requests: +29188
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31007

___
Python tracker 

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

[issue46458] Optimise try-except code generation for the happy path

[Irit Katriel]

Irit Katriel  added the comment:

Re next steps, see 
https://github.com/faster-cpython/ideas/issues/226#issuecomment-1024875216.

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[bluecarrot]

bluecarrot  added the comment:

You are absolutely correct. Thank you very much!

--

___
Python tracker 

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

[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__

[Alex Waygood]

Change by Alex Waygood :


--
assignee: docs@python -> ethan.furman
nosy: +ethan.furman
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__

[Dutcho]

New submission from Dutcho :

https://docs.python.org/3.11/library/enum.html#enum.StrEnum contains:
Note __str__() is str.__str__() to better support the replacement of existing 
constants use-case. __format__() is likewise int.__format__() for that same 
reason.

This should be (change indicated by triple star):
Note __str__() is str.__str__() to better support the replacement of existing 
constants use-case. __format__() is likewise ***str***.__format__() for that 
same reason.

Likely copied from IntEnum

--
assignee: docs@python
components: Documentation
messages: 412067
nosy: Dutcho, docs@python
priority: normal
severity: normal
status: open
title: final note on StrEnum documentation incorrectly refers to int.__format__ 
instead of str.__format__
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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Your version works but can be simplified.

Just use

await writer.drain()  
writer.write(data)

without grabbing the drainer early.
The purpose of the .drain() method is to write pausing if the write buffer side 
is greater than the high watermark. 
The 'await writer.drain()' waits until the buffer size became less than low 
watermark. It prevents uncontrollable write buffer growth if a peer cannot 
accept TCP message as fast as `writer.write()` sends them.
The .drain() call has no hidden process under the hood, there is no need to get 
write_drain reference as early as possible. It is just 'waiting for a flag'.
Also, there is no need for `await write_drain` at the end: asyncio transport 
sends all data from the internal write buffer before closing (and doesn't do it 
on 'transport.abort()').

--

___
Python tracker 

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

[issue46565] Delete module-level loop variables when no longer needed

[Alex Waygood]

Alex Waygood  added the comment:

I agree that the typeshed issue is less important than the output of dir() and 
help(). I also agree that we shouldn't make a fetish of typing.

However, I see the typeshed issue less as an issue specific to typing, and more 
as an example that illustrates a general problem third-party tools have. For 
example, having these temporary variables leak into global namespaces also 
makes IDE autocompletion less valuable, and makes life harder for tools that 
auto-generate documentation.

Perhaps a PEP8 revision might be warranted in due course — but in the meantime, 
are there any downsides to this proposed change? I believe we have pointed out 
several upsides.

I don't see this as a style issue first and foremost: the PR is attempting to 
solve a genuine problem for some end-users of Python. It is not simply making 
cosmetic changes.

--

___
Python tracker 

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[bluecarrot]

bluecarrot  added the comment:

Hi Andrew, thank you for your answer. I am experimenting with coroutines, as I 
am pretty new to them. My idea was to let the writer drain while other packets 
where read, and thus I am waiting for the writer_drain right before starting 
writer.write again. Isn't that the correct wait to overlap the readings and the 
writings?

If I modify my initial code to look like:

async def forward_stream(reader: StreamReader, writer: StreamWriter, event: 
asyncio.Event, source: str):
writer_drain = writer.drain()  # <--- awaitable is created here
while not event.is_set():
try:
data = await asyncio.wait_for(reader.read(1024), 1)  # <-- 
CancelledError can be caught here, stack unwinds and writer_drain is never 
awaited, sure.
except asyncio.TimeoutError:
continue
except asyncio.CancelledError:
event.set()
break
 ...  # the rest is not important for this case

await writer_drain

so that in case the task is cancelled, writer_drain will be awaited outside of 
the loop. This works, at the cost of having to introduce code specific for 
testing purposes (which feels wrong). In "production", the workflow of this 
code will be to loose the connection, break out of the loop, and wait for the 
writer stream to finish... but I am not introducing any method allowing me to 
cancel the streams once the script is running.

In the same way leaked tasks are "swallowed", which I have tested and works, 
shouldn't be these cases also handled by the tearDownClass method of 
IsolatedAsyncioTestCase?

--

___
Python tracker 

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

[issue46489] webbrowser crashes Ubuntu kernel

[Danylo]

Danylo  added the comment:

Never mind.

I had a crash today with no Python involved. At least, no webbrowser lib was 
running. Although Python webbrowser lib surely triggers the issue I have with 
my system. Need to find the origin somewhere else.

Please report back if someone else experiences the same issue. Closed for time 
being.

Best,
Danylo

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

___
Python tracker 

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Your code has at least one concurrency problem. Let's look back at 
forward_stream() function:

async def forward_stream(reader: StreamReader, writer: StreamWriter, event: 
asyncio.Event, source: str):
writer_drain = writer.drain()  # <--- awaitable is created here
while not event.is_set():
try:
data = await asyncio.wait_for(reader.read(1024), 1)  # <-- 
CancelledError can be caught here, stack unwinds and writer_drain is never 
awaited, sure.
except asyncio.TimeoutError:
continue
 ...  # the rest is not important for this case

To solve the problem, you should create writer_drain *before its awaiting*, not 
before another 'await' call.

--

___
Python tracker 

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[bluecarrot]

bluecarrot  added the comment:

Seems that, should I add an "await asyncio.sleep(1)" in asyncTearDown, so 
getting

class TestConnections(IsolatedAsyncioTestCase):
async def asyncSetUp(self) -> None:
self.proxy = asyncio.create_task(EnergyAgentProxy(self.proxy_port, 
self.server_port, self.upstream_port))

async def asyncTearDown(self) -> None:
await asyncio.sleep(1)

is enough to "hide the problem under the carpet"... but sounds weird...

--

___
Python tracker 

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

[issue46568] non awaited coroutines on a IsolatedAsyncioTestCase results on a RuntimeWarning

[bluecarrot]

New submission from bluecarrot :

I am unittesting a tcp proxy module using coroutines. This is the coroutine I 
am using to do the forwarding, allowing the writer stream to drain while the 
rest of the coroutines are proceeding:

async def forward_stream(reader: StreamReader, writer: StreamWriter, event: 
asyncio.Event, source: str):
writer_drain = writer.drain()
while not event.is_set():
try:
data = await asyncio.wait_for(reader.read(1024), 1)
except asyncio.TimeoutError:
continue

if not data:
event.set()
break

# parse the data
if reading := parse(data):
# wait for the previous write to finish, and forward the data to 
the other end, process the data in between
await writer_drain
writer.write(data)
writer_drain = writer.drain()

# wait for any outstanding write buffer to be flushed
await writer_drain
logger.info("{} reader forwarder finished.".format(source))

In my unit tests, I have the following (EnergyAgentProxy is the wrapper calling 
the coroutine in the module that creates the proxy)

class TestConnections(IsolatedAsyncioTestCase):
async def asyncSetUp(self) -> None:
self.proxy = asyncio.create_task(EnergyAgentProxy(self.proxy_port, 
self.server_port, self.upstream_port))

The problem is: When running these tests, I am getting the following error:
 /usr/lib/python3.10/unittest/async_case.py:159: RuntimeWarning: coroutine 
'StreamWriter.drain' was never awaited
 Coroutine created at (most recent call last)
   File "/usr/lib/python3.10/unittest/case.py", line 650, in __call__
 return self.run(*args, **kwds)
   [...]
   File "/home/frubio/Documents/powermonitor_raspberrypi/EnergyAgent.py", 
line 48, in forward_stream
 writer_drain = writer.drain()
   self._tearDownAsyncioLoop()

So... to me, it looks like when the tasks are being cancelled I am getting this 
warning because the last "await writer_drain" in forward stream is not 
executed, but I cannot ensure that. Am I doing something wrong? Is there any 
way I can just prevent this warning from showing up in my tests?

--
components: Tests, asyncio
messages: 412060
nosy: asvetlov, bluecarrot, yselivanov
priority: normal
severity: normal
status: open
title: non awaited coroutines on a IsolatedAsyncioTestCase results on a 
RuntimeWarning
type: behavior
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

[issue46565] Delete module-level loop variables when no longer needed

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Thanks for the better wording, Terry!

> Leaving loop variables available is an intended feature of python.

Just to be clear: it sure is! But, sometimes we don't want to polute a global 
namespace with this variable. A common practice across CPython's source is to 
use `del` or comprehensions. That's exactly what my PR does: it finds places 
where people forgot to do that and adds a cleanup.

>  As it is, the PR applies a style standard on the stdlib that is not in PEP 
> 8.  I recommend that you start by proposing an addition to PEP-8.

Interesting idea! But, I think that this is an orthogonal non-blocking task, 
which might be much harder compared to this one :) 

I will add this to my backlog.

> You might post the idea on pydev and ask how much and what sort of discussion 
> is needed.

Good starting point, agreed!

--

___
Python tracker 

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

[issue46512] filecmp.cmpfiles w/ absolute path names

[bers]

bers  added the comment:

> Did your example work with relative paths?

Yes, it does. Just append the following to my example code:

# actually diff the files - correctly!
files = [f.relative_to(dir_a) for f in dir_a.glob("*")]
(_, different, _) = filecmp.cmpfiles(dir_a, dir_b, files, shallow=False)
print("different:", *different)

Output then is

equal: C:\Users\bers\AppData\Local\Temp\tmp1p6jh4rg\a\foo.txt
different: foo.txt

--

___
Python tracker 

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