date:20220405



Raymond Hettinger  added the comment:

> isfinite() should return True for all ints, without needing
> to coerce them to float

Whoa there.  You're venturing into changing what those math functions were all 
about and the core approach to how they operate.

A zigzag to this new direction would need discussion with all the math folks.  
Many tools in the math module are thin wrapper around libmath and we never 
intended to be universal handlers of all numeric types.  We have a lot of 
functions that start by coercing their input to a float.

My two cents is that this would open an endless can of worms and make everyone 
pay a time and complexity cost for a feature that almost no one needs.  AFAICT 
is more of a purity issue than an actual practical need that would warrant 
separate code paths (for example, we recently closed an issue where someone 
wanted math.log() to have a separate code path for Fraction inputs where it 
return log(f.numerator) - log(f.denominator) with the goal of handling 
fractional values smaller than float_min).

--
nosy: +mark.dickinson, tim.peters

___
Python tracker 

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

[issue47061] Deprecate modules listed in PEP 594

2022-04-05 Thread Brett Cannon



Change by Brett Cannon :


--
pull_requests: +30402
pull_request: https://github.com/python/cpython/pull/32350

___
Python tracker 

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

[issue47022] PEP 594: Document removal of asynchat, asyncore and smtpd

2022-04-05 Thread Brett Cannon



Change by Brett Cannon :


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

[issue47009] Streamline list.append for the common case

2022-04-05 Thread Dennis Sweeney



Dennis Sweeney  added the comment:

Buildbots are passing, so I'm closing this. Thanks for the catch and fix!

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

[issue17004] Expand zipimport to include other compression methods

2022-04-05 Thread Chih-Hsuan Yen



Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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

[issue47121] math.isfinite() can raise exception when called on a number

2022-04-05 Thread Steven D'Aprano



Steven D'Aprano  added the comment:

Isn't this just a quality of implementation issue?

math.isfinite should return True for all ints, since all ints are finite. 
(There are no int infinities or NANs). There is no need to coerce them to float 
to know that they are finite.

Likewise for Fractions. If they overflow, that could be caught and True 
returned.

Decimal infinities convert to float infinities, so the only way you can get an 
overflow error is if the Decimal is finite but too big to convert. So again, 
isfinite could (should?) catch the overflow error and return True.

Any numeric type that has an infinity which does not coerce to float infinity, 
but overflows instead, is buggy, and its not isfinite's responsibility to 
protect against that.

So here is my suggestion:

isfinite() should return True for all ints, without needing to coerce them to 
float. For other numeric types, it should try to coerce them to float, and 
catch OverflowError and raise True. This should be documented, so that other 
numeric types know what contract they are required to follow (infinity coerces 
to float infinity).

I'm going to change this to an enhancement for 3.11 (or 3.12).

--
nosy: +steven.daprano
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

[issue46134] Confusing error message for AttributeError with dataclasses

2022-04-05 Thread Alex Waygood



Alex Waygood  added the comment:

Closing due to lack of response from OP.

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

[issue27546] Integrate tkinter and asyncio (and async)



Terry J. Reedy  added the comment:

I posted look_tk3, I believe, as an answer to an SO question. 

https://stackoverflow.com/questions/47895765/use-asyncio-and-tkinter-or-another-gui-lib-together-without-freezing-the-gui/47896365#47896365

--

___
Python tracker 

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

[issue47229] IDLE crashes on Chromebook Linux/Bullseye



Change by Terry J. Reedy :


--
title: IDLE / Thonny UI crashes on Chromebook Linux/Bullseye -> IDLE crashes on 
Chromebook Linux/Bullseye

___
Python tracker 

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

[issue47229] IDLE / Thonny UI crashes on Chromebook Linux/Bullseye



Terry J. Reedy  added the comment:

This issue tracker is for improving the CPython distribution.  It is not a 
tracker for other software, or for general help with running Python.  For the 
latter, try
https://mail.python.org/mailman/listinfo/python-list

Thonny is 3rd party software with its own tracker, although I suspect that the 
problem is with your upgrade Chromebook/Linux Bullseye.  While running Python 
on Linux on PCs is supported, I do not believe Chromebooks are included; there 
is certainly no Chromebook buildbot for testing CPython listed on 
https://buildbot.python.org/all/#/builders.  If there is a Chromebook Python 
list, you might ask if tkinter works with Bullseye for other users.

IDLE *is* part of CPython.  What specific release of Python are you running.  
This is the first thing IDLE prints when it starts.

If you are running a somewhat recent release of 3.9 or 3.10, then continue.  To 
see whether there might be an IDLE-specific or ever tkinter-specific problem, 
run the CPython test suite from a command line with "python3 -m test -j0 -ugui" 
and report results.  (Or 'python ...' is 'python' works to run python 3.) If it 
passes except for IDLE tests, start IDLE from a command line with "python3 -m 
idlelib".  Get IDLE to quit/crash.  Then report any error info printed in the 
terminal.

--

___
Python tracker 

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

[issue47235] Clarify that `assret_called_once_with` sample code is intended typo



Change by Gregory P. Smith :


--
keywords: +patch
pull_requests: +30401
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32348

___
Python tracker 

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

[issue47235] Clarify that `assret_called_once_with` sample code is intended typo



Gregory P. Smith  added the comment:

LOL... we didn't anticipate this happening when adding the commonly found typo 
detection feature.

--
assignee: docs@python -> gregory.p.smith
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

[issue47230] New compiler warnings with latest zlib



Change by Jeremy Kloth :


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

[issue47230] New compiler warnings with latest zlib



Steve Dower  added the comment:


New changeset a4c7752f3e00b75fd1e4603458b8c77a9fa3d4cb by Jeremy Kloth in 
branch '3.9':
bpo-47230: Silence compiler warnings on Windows from zlib 1.2.12 (GH-32337)
https://github.com/python/cpython/commit/a4c7752f3e00b75fd1e4603458b8c77a9fa3d4cb


--

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



Steve Dower  added the comment:


New changeset 8bce3cb16df5b8ac06ac6b2cae177dd221780b2f by Jeremy Kloth in 
branch '3.10':
bpo-47230: Silence compiler warnings on Windows from zlib 1.2.12 (GH-32337)
https://github.com/python/cpython/commit/8bce3cb16df5b8ac06ac6b2cae177dd221780b2f


--

___
Python tracker 

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

[issue47236] Document types.CodeType.replace() changes about co_exceptiontable



Change by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue40222] "Zero cost" exception handling



STINNER Victor  added the comment:

I created bpo-47236 "Document types.CodeType.replace() changes about 
co_exceptiontable".

--

___
Python tracker 

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

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11



STINNER Victor  added the comment:

Ok sure, I created bpo-47236 "Document types.CodeType.replace() changes about 
co_exceptiontable".

--

___
Python tracker 

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

[issue47236] Document types.CodeType.replace() changes about co_exceptiontable



New submission from STINNER Victor :

It would be nice to document the bpo-40222 changes in What's New in Python 3.11 
and in the CodeType documentation:

* https://docs.python.org/dev/library/types.html#types.CodeType
* https://docs.python.org/dev/whatsnew/3.11.html

Users of types.CodeType.replace(co_code=new_code) must now pass 
co_exceptiontable or exception handling will no longer work as expected. 
Callers are responsible to build co_exceptiontable.

Currently, the format of this table is documented at:
https://github.com/python/cpython/blob/main/Objects/exception_handling_notes.txt

There is no public function to encode this table, it's also the responsibility 
of the caller.

See also bpo-47185 "code.replace(co_code=new_code) no longer catch exceptions 
on Python 3.11" closed as "won't fix" for the background.

--
assignee: docs@python
components: Documentation
messages: 416831
nosy: docs@python, vstinner
priority: normal
severity: normal
status: open
title: Document types.CodeType.replace() changes about co_exceptiontable
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

[issue47205] posix.sched_{get|set}affinity(-1) no longer returns ProcessLookup causing test failures on FreeBSD

2022-04-05 Thread Kubilay Kocak



Change by Kubilay Kocak :


--
title: test_sched_getaffinity and setaffinity fail on FreeBSD buildbit -> 
posix.sched_{get|set}affinity(-1) no longer returns ProcessLookup causing test 
failures on FreeBSD

___
Python tracker 

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

[issue47205] test_sched_getaffinity and setaffinity fail on FreeBSD buildbit

2022-04-05 Thread Kubilay Kocak



Kubilay Kocak  added the comment:

>From one of our base/kernel developers:

--

> koobs wrote:
>
> I don't grok the system call semantics, but it appears the issue is calls
> with the '-1' argument:
>
> mask = posix.sched_getaffinity(0)
> ...
> self.assertRaises(OSError, posix.sched_getaffinity, -1)
> ...
> self.assertRaises(OSError, posix.sched_setaffinity, -1, mask)
>
> This line was added 10 years ago in:
>
> https://github.com/python/cpython/commit/848698727fcbb633246b56ab57080b4d5493c186
>
> It wants an OSError [1] and presumably was getting it before recent
> failures, but isn't anymore:
>
> [1] https://docs.python.org/3/library/exceptions.html#OSError

So this is the difference:

Python 3.11.0a6+ (heads/main:38ae5b8c0c, Apr  5 2022, 03:27:23) [GCC 11.2.0] on 
freebsd13
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> mask = posix.sched_getaffinity(-1)
>>> mask
{0, 1, 2, 3, 4, 5, 6, 7}

Python 3.10.4 (main, Mar 25 2022, 00:00:00) [GCC 11.2.1 20220127 (Red Hat 
11.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> mask = posix.sched_getaffinity(-1)
Traceback (most recent call last):
  File "", line 1, in 
ProcessLookupError: [Errno 3] No such process

FreeBSD always accepted -1 as denoting the current process, while Linux
does not.  In fact, Linux uses 0 as current process pid alias.

For FreeBSD, both -1 and 0 works as getpid(), and I do not see it right
to break our traditional API conventions.  I believe the test should be
fixed.

--

I am not sure what changed between 3.10 and main that changed/removed
ProcessLookupError as the return for posix.sched_{get|set}affinity
with -1 as the argument, but that appears to be the cause of the current test 
failure

--

___
Python tracker 

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

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11



Guido van Rossum  added the comment:

If you think the changes to .replace() should be documented just open a new 
bpo. You made this issue about your various proposals to change .replace().

--

___
Python tracker 

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

[issue47233] show_caches option affects code positions reported by dis.get_instructions(...)

2022-04-05 Thread Brandt Bucher



Brandt Bucher  added the comment:

Nice catch. The fix should be pretty simple: just move this line...

https://github.com/python/cpython/blob/c1d93b6411f975d67e43942f1a2745a22983c18c/Lib/dis.py#L425

...up to the top of the for loop.

Are you interested in working on this?

--

___
Python tracker 

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

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11



STINNER Victor  added the comment:

>>> def f():
... foo()
... try:
... bar()
... except:
... pass
... 
>>> def g():
... try:
... foo()
... bar()
... except:
... pass
... 

>>> dis.dis(f)
  1   0 RESUME   0

  2   2 LOAD_GLOBAL  1 (NULL + foo)
 14 PRECALL  0
 18 CALL 0
 28 POP_TOP

  3  30 NOP

  4  32 LOAD_GLOBAL  3 (NULL + bar)
 44 PRECALL  0
 48 CALL 0
 58 POP_TOP
 60 LOAD_CONST   0 (None)
 62 RETURN_VALUE
>>   64 PUSH_EXC_INFO

  5  66 POP_TOP

  6  68 POP_EXCEPT
 70 LOAD_CONST   0 (None)
 72 RETURN_VALUE
>>   74 COPY 3
 76 POP_EXCEPT
 78 RERAISE  1
ExceptionTable:
  32 to 58 -> 64 [0]
  64 to 66 -> 74 [1] lasti

>>> dis.dis(g)
  1   0 RESUME   0

  2   2 NOP

  3   4 LOAD_GLOBAL  1 (NULL + foo)
 16 PRECALL  0
 20 CALL 0
 30 POP_TOP

  4  32 LOAD_GLOBAL  3 (NULL + bar)
 44 PRECALL  0
 48 CALL 0
 58 POP_TOP
 60 LOAD_CONST   0 (None)
 62 RETURN_VALUE
>>   64 PUSH_EXC_INFO

  5  66 POP_TOP

  6  68 POP_EXCEPT
 70 LOAD_CONST   0 (None)
 72 RETURN_VALUE
>>   74 COPY 3
 76 POP_EXCEPT
 78 RERAISE  1
ExceptionTable:
  4 to 58 -> 64 [0]
  64 to 66 -> 74 [1] lasti


Oh, I didn't follow recent bytecode changes. Ok, now I see that it is not 
longer possible to build the exception table just from the bytecode. The 
purpose of the exception table is to handle exceptions: the opcodes related to 
exception handles are simply gone in Python 3.11.

I was thinking about looking for things like PUSH_EXC_INFO or POP_EXCEPT, but 
as Guido shows, it doesn't work: the start of the "try" block cannot be 
detected in the bytecode anymore in Python 3.11.


> If code.replace() is not updated to recompute co_exceptiontable, at least, it 
> would be nice to document the bpo-40222 changes in What's New in Python 3.11 
> and in the CodeType documentation

You closed the issue. I understand that you don't want to document 
CodeType.replace() changes neither. Users of this API should follow Python 
development and notice that their code no longer works with Python 3.11.

--

___
Python tracker 

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

[issue47233] show_caches option affects code positions reported by dis.get_instructions(...)

2022-04-05 Thread Brandt Bucher



Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue47235] Clarify that `assret_called_once_with` sample code is intended typo

2022-04-05 Thread Mariatta



New submission from Mariatta :

In unittest.mock documentation, there is an example code which intentionally 
contains typo.

Source: 
https://github.com/python/cpython/blame/main/Doc/library/unittest.mock.rst#L2553

We've received quite a number of false "bug report" regarding this text. 
Basically people saw the sample code containing `assret` then they rushed to 
create an issue/PR, before actually reading the rest of the section. This typo 
was intentionally placed there, so it should not be fixed. However since this 
is definitely confusing to readers, perhaps the documentation should be 
improved.

On Discord, Brandt suggested to add a comment on the sample code like:


```
# Intended typo!
```

so hopefully people will stop trying to fix it.


Previous false "bug reports":
bpo-35789
bpo-38700

--
assignee: docs@python
components: Documentation
messages: 416826
nosy: Mariatta, docs@python
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify that `assret_called_once_with` sample code is intended typo
versions: Python 3.10, Python 3.11, 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

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11



Guido van Rossum  added the comment:

This idea just cannot work. Take these two functions:

def f():
foo()
try:
bar()
except:
pass

def g():
try:
foo()
bar()
except:
pass

Using dis to look at their disassembly, the only hint that in f(), the call to 
foo() is outside the try block and in g() it is inside it is the presence of 
some NOP opcodes. The actual demarcation of where the try blocks start and end 
is exclusively determined by the exception table.

It just doesn't make sense to try to validate that correct parameters are being 
passed in when you are modifying co_code and friends.

--
resolution:  -> wont fix
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

[issue47232] Difficulties building tip of tree Python for emscripten



Hood Chatham  added the comment:

Okay I got it working. I was making several mistakes that each caused the same 
symptoms so it was hard to track them all down.

Thanks again for your help!

--
status: open -> closed

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



Change by Jeremy Kloth :


--
pull_requests: +30400
pull_request: https://github.com/python/cpython/pull/32347

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



Change by Jeremy Kloth :


--
pull_requests: +30399
pull_request: https://github.com/python/cpython/pull/32346

___
Python tracker 

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

[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods



Guido van Rossum  added the comment:

At this point I think it's worth filing a new bug proposing to deprecate 1-arg 
super(), pointing out the broken usages that search found.

--

___
Python tracker 

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

[issue46607] Add DeprecationWarning to configparser's LegacyInterpolation



STINNER Victor  added the comment:

Thanks Hugo for the your contribution. I close the issue.

> Searching the top 5,000 PyPI sdists, there's very little (if any "real") use 
> of LegacyInterpolation. Details: https://bugs.python.org/issue45173#msg409685

You can offer them a PR to avoid the deprecated API, or at least notify them by 
creating an issue that this API is deprecated in Python 3.11.

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

[issue47231] TarFile.getmember cannot work on tar sourced directory over 100 characters



Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



Christian Heimes  added the comment:

You are building a cross-build with 
"--with-build-python=/usr/local/bin/python3.11". Is the interpreter up to date?

During alpha and beta phase, the build Python interpreter should be built from 
the exact same git commit as the sources in "../..". If the interpreter 
deviates from the sources in your srcdir, then Python byte code (.pyc), frozen 
byte code, and re engine can have mismatching magic.

I recommend that you build inside an environment that does not have Python 3.11 
installed. Instead build a build Python interpreter from the same checkout that 
you later use for cross-compilation. "./configure && make" is sufficient. You 
don't have to install the build interpreter. 
"--with-build-python=$(pwd)/../build/python" works fine.

We use this approach in python-wasm:

mkdir -p cpython/builddir/build
pushd cpython/builddir/build
../../configure -C
make -j$(nproc)
popd

mkdir -p cpython/builddir/emscripten-browser
pushd cpython/builddir/emscripten-browser
CONFIG_SITE=../../Tools/wasm/config.site-wasm32-emscripten \
  emconfigure ../../configure -C \
--host=wasm32-unknown-emscripten \
--build=$(../../config.guess) \
--with-build-python=$(pwd)/../build/python
emmake make -j$(nproc)


It's going to get easier and less painful as soon as we reach beta phase. 
During beta the byte code will only change when it is required for a bug fix.

--

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



Hood Chatham  added the comment:

There is still a pretty good change I am making some dumb mistake.

--

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



Hood Chatham  added the comment:

config.log is apparently 1.7 MB and when I try to upload I get "Error 413: 
Entity Too Large". I've attached the Makefile.

--
Added file: https://bugs.python.org/file50723/Makefile

___
Python tracker 

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

[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation



Raymond Hettinger  added the comment:

This is a partial duplicate of an issue you already filed: 
https://bugs.python.org/issue47121 where math.isfinite(10**1000) raises an 
OverflowError even though it type checks.

Here was one of the comments:
"""
Types relationships are useful for verifying which methods are available, but 
they don't make promises about the range of valid values.  For example 
math.sqrt(float) -> float promises which types are acceptable but doesn't 
promise that negative inputs won't raise an exception.  Likewise, "n: int=10; 
len(range(n))" is type correct but will raise an OverflowError for "n = 
10**100".
"""

--
nosy: +rhettinger

___
Python tracker 

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

[issue47222] subprocess.Popen() should allow capturing output and sending it to stdout and stderr

2022-04-05 Thread Philip Prindeville



Change by Philip Prindeville :


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

___
Python tracker 

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

[issue46850] [C API] Move _PyEval_EvalFrameDefault() to the internal C API



Change by STINNER Victor :


--
pull_requests: +30397
pull_request: https://github.com/python/cpython/pull/32343

___
Python tracker 

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

[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation



Jelle Zijlstra  added the comment:

Thanks for your report, but I would appreciate a more concise explanation. Let 
me try to rephrase the problem.

Given this function:

def mean(x: list[float]) -> float:
return sum(x) / len(x)

We want to provide a guarantee that if x is a nonempty list containing only 
floats, the function returns successfully and returns a float.

But the type system currently doesn't give this guarantee, because PEP 484 
specifies that ints are compatible with floats, and `mean([0.0, 1.25, 10**1000, 
0.0])` will throw OverflowError.

---

We generally discuss issues with the general type system over at 
https://github.com/python/typing/issues, but here are a few thoughts:

- The type system doesn't generally try to cover exceptions. Your function 
could also raise MemoryError, or KeyboardInterrupt, and the type system can't 
tell you.
- The concrete proposal here would be to make int no longer implicitly 
compatible with float. That might be nice, but at this point it would be a big 
break in backwards compatibility, so I'm not sure we can do it.

--
nosy: +AlexWaygood, JelleZijlstra, gvanrossum, kj

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



Christian Heimes  added the comment:

Please attach config.log and Makefile from the builddir.

--

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



Hood Chatham  added the comment:

I take it back, I am still having this problem.

--
status: closed -> open

___
Python tracker 

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

[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation

2022-04-05 Thread Thomas Fischbacher


New submission from Thomas Fischbacher :

Here is a major general problem with python-static-typing as it is
described by PEP-484: The approach described in
https://peps.python.org/pep-0484/#the-numeric-tower negatively impacts
our ability to reason about the behavior of code with stringency.

I would like to clarify one thing in advance: this is a real problem
if we subscribe to some of the important ideas that Dijkstra
articulated in his classic article "On the role of scientific thought"
(e.g.: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html).
Specifically, this part:

"""
Let me try to explain to you, what to my taste is characteristic
for all intelligent thinking. It is, that one is willing to study in
depth an aspect of one's subject matter in isolation for the sake of
its own consistency, all the time knowing that one is occupying
oneself only with one of the aspects. We know that a program must be
correct and we can study it from that viewpoint only; we also know
that it should be efficient and we can study its efficiency on another
day, so to speak. In another mood we may ask ourselves whether, and if
so: why, the program is desirable. But nothing is gained —on the
contrary!— by tackling these various aspects simultaneously. It is
what I sometimes have called "the separation of concerns", which, even
if not perfectly possible, is yet the only available technique for
effective ordering of one's thoughts, that I know of. This is what I
mean by "focussing one's attention upon some aspect": it does not mean
ignoring the other aspects, it is just doing justice to the fact that
from this aspect's point of view, the other is irrelevant. It is being
one- and multiple-track minded simultaneously.
"""

So, "code should be easy to reason about".

Now, let us look at this function - I am here (mostly) following the
Google Python style guide (https://google.github.io/styleguide/pyguide.html) 
for now:

=== Example 1, original form ===

def middle_mean(xs):
  """Compute the average of the nonterminal elements of `xs`.

  Args:
`xs`: a list of floating point numbers.

  Returns:
A float, the mean of the elements in `xs[1:-1]`.

  Raises:
ValueError: If `len(xs) < 3`.
  """
  if len(xs) < 3:
raise ValueError('Need at least 3 elements to compute middle mean.')
  return sum(xs[1:-1]) / (len(xs) - 2)
==

Let's not discuss performance, or whether it makes sense to readily
generalize this to operate on other sequences than lists, but focus,
following Dijkstra, on one specific concern here: Guaranteed properties.

Given the function as it is above, I can make statements that are
found to be correct when reasoning with mathematical rigor, such as
this specific one that we will come back to:

=== Theorem 1 ===
  If we have an object X that satisfies these properties...:

  1. type(X) is list
  2. len(X) == 4
  3. all(type(x) is float for x in X)

  ...then we are guaranteed that `middle_mean(X)` evaluates to a value Y
  which satisfies:

  - type(Y) is float
  - Y == (X[1] + X[2]) * 0.5 or math.isnan(Y)
===

Now, following PEP-484, we would want to re-write our function, adding type 
annotations.
Doing this mechanically would give us:

=== Example 1, with mechanically added type information ===
def middle_mean(xs: List[float]) -> float:
  """Compute the average of the nonterminal elements of `xs`.

  Args:
`xs`: a list of floating point numbers.

  Returns:
A float, the mean of the elements in `xs[1:-1]`.

  Raises:
ValueError: If `len(xs) < 3`.
  """
  if len(xs) < 3:
raise ValueError('Need at least 3 elements to compute middle mean.')
  return sum(xs[1:-1]) / (len(xs) - 2)
==

(We are also deliberately not discussing another question here: given
this documentation and type annotation, should the callee be
considered to be permitted to mutate the input list?)


So, given the above form, we now find that there seems to be quite a
bit of redundancy here. After all, we have the type annotation but
also repeat some typing information in the docstring. Hence, the
obvious proposal here is to re-write the above definition again, obtaining:

=== Example 1, "cleaned up" ===
def middle_mean(xs: List[float]) -> float:
  """Compute the average of the nonterminal elements of `xs`.

  Args:
`xs`: numbers to average, with terminals ignored.

  Returns:
The mean of the elements in `xs[1:-1]`.

  Raises:
ValueError: If `len(xs) < 3`.
  """
  if len(xs) < 3:
raise ValueError('Need at least 3 elements to compute middle mean.')
  return sum(xs[1:-1]) / (len(xs) - 2)
==

But now, what does this change mean for the contract? Part of the "If
arguments have these properties, then these are the guarantees"
contract now is no longer spelled out by the docstring, but via type
annotations. We naturally would expect this to be straightforward,
so, we would like to have:

=== Theorem 1b ===
  If we have an object X that satisfies these properties...:

  1. Static

[issue47006] PEP 646: Decide on substitution behavior

2022-04-05 Thread Matthew Rahtz



Matthew Rahtz  added the comment:

Ok, https://github.com/python/cpython/pull/32341/files is a reference of how 
the current implementation behaves. Fwiw, it *is* mostly correct - with a few 
minor tweaks it might be alright for at least the 3.11 release.

In particular, instead of dealing with the thorny issue of what to do about 
splitting unpacked arbitrary-length tuples over multiple type variables - e.g. 
C[T, *Ts][*tuple[int, ...]] - instead either deciding to try and evaluate it 
properly and living with the complexity, or leaving it unsimplified and living 
with the __args__, __parameters__ and __origin__ problem - for now, we could 
just raise an exception for any substitutions which involve an unpacked 
arbitrary-length tuple, since I'd guess it's going to be an extremely rare 
use-case.

--

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



Hood Chatham  added the comment:

Okay I found the problem. Elsewhere in my Makefiles `PYTHON_FOR_BUILD` was 
getting overwritten.

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

[issue47006] PEP 646: Decide on substitution behavior

2022-04-05 Thread Matthew Rahtz



Change by Matthew Rahtz :


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

___
Python tracker 

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

[issue47203] ImportError: DLL load failed while importing binascii: %1 is not a valid Win32 application.

2022-04-05 Thread Matthew



Matthew  added the comment:

> Probably there was also shadowing involved, since the built-in module doesn't 
> try to load anything else. Would be nice to know for sure (@Matthew) to make 
> sure we don't have some other issue here, but you're right, I don't see any 
> way for this to happen without other causes.

I'm pretty sure the Python interpreter that was causing the issue was bundled 
with the MSYS2 Mingw64 compiler. I tried reproducing the bug, but I've recently 
reinstalled the compiler due to some issues I was having with it, and the bug 
with importing binascii is no longer present.

--

___
Python tracker 

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

[issue47233] show_caches option affects code positions reported by dis.get_instructions(...)

2022-04-05 Thread 15r10nk



New submission from 15r10nk <15r10nk-python-iss...@polarbit.de>:

The Instructions reported by dis.get_instructions(...) and dis.Bytecode(...) 
have different positions depending on the value of their show_caches argument.

test2.py reproduces the problem.

--
files: test2.py
messages: 416810
nosy: 15r10nk
priority: normal
severity: normal
status: open
title: show_caches option affects code positions reported by 
dis.get_instructions(...)
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50722/test2.py

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



Jeremy Kloth  added the comment:

It seems so, as the zlib update was also backported to 3.9 and 3.10.

--

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten

2022-04-05 Thread pmp-p



Change by pmp-p :


--
nosy: +pmpp

___
Python tracker 

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

[issue47139] pthread_sigmask needs SIG_BLOCK behaviour explaination

2022-04-05 Thread Richard Purdie



Richard Purdie  added the comment:

I think the python code implementing pthread_sigmask already does trigger 
interrupts if any have been queued before the function returns from blocking or 
unblocking.

The key subtlety which I initially missed is that if you have another thread in 
your python script, any interrupt it receives can be raised in the main thread 
whilst you're in the SIGBLOCK section. This obviously isn't what you expect at 
all as those interrupts are supposed to be blocked! It isn't really practical 
to try and SIGBLOCK on all your individual threads.

What I'd wondered is what you mention, specifically checking if a signal is 
masked in the python signal raising code with something like the 
"pthread_sigmask(SIG_UNBLOCK, NULL /* set */, )" before it raises it and 
if there is blocked, just leave it queued. The current code would trigger the 
interrupts when it was unmasked. This would effectively only apply on the main 
thread where all the signals/interrupts are raised. 

This would certainly give the behaviour that would be expected from the calls 
and save everyone implementing the workarounds as I have. Due to the threads 
issue, I'm not sure SIGBLOCK is actually useful in the real world with the 
current implementation unfortunately.

Equally, if that isn't an acceptable fix, documenting it would definitely be 
good too.

--

___
Python tracker 

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

[issue47232] Difficulties building tip of tree Python for emscripten



New submission from Hood Chatham :

I am trying to build tot Python for Emscripten to test recent changes and 
having trouble. The problem is caused by recent changes since 3.11.0a6 to 
`sre`. I build a build Python 3.11 from tot, and provided it to `./configure 
--with-build-python=$(HOSTBUILDDIR)/python`. However, I still see invocations 
to the system Python 3.11 at `/usr/local/bin/python3.11`.

The problem seems to be that the generated `Makefile` has a bunch of stuff 
collapsed into one line:
```
PYTHON_FOR_BUILD=_PYTHON_PROJECT_BASE=$(abs_builddir) 
_PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f 
pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) 
/src/cpython/build/Python-3.11.0dev0/builddir/build-host/python
```
manually fixing this to:
```
PYTHON_FOR_BUILD=/src/cpython/build/Python-3.11.0dev0/builddir/build-host/python
_PYTHON_PROJECT_BASE=$(abs_builddir) 
_PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) 
PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat 
pybuilddir.txt`:)$(srcdir)/Lib 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH)
```
fixes the problem.

My configure invocation is as follows:
```
( \
cd $(BUILDDIR); \
CONFIG_SITE=./config.site-wasm32-emscripten emconfigure \
  ../../configure \
  --cache-file=$(ROOT)/python.config.cache \
  CFLAGS="${PYTHON_CFLAGS}" \
  CPPFLAGS="-I$(SQLITEBUILD) -I$(BZIP2BUILD) 
-I$(ZLIBBUILD)" \
  PLATFORM_TRIPLET="$(PLATFORM_TRIPLET)" \
  --with-build-python=$(HOSTBUILDDIR)/python \
  --without-pymalloc \
  --disable-shared \
  --disable-ipv6 \
  --enable-big-digits=30 \
  --enable-optimizations \
  --host=wasm32-unknown-emscripten\
  --build=$(shell $(EXTRACTDIR)/config.guess) \
  --prefix=$(INSTALL)  \
)
```

--
messages: 416807
nosy: christian.heimes, hoodchatham
priority: normal
severity: normal
status: open
title: Difficulties building tip of tree Python for emscripten

___
Python tracker 

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

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception

2022-04-05 Thread Mark Dickinson



Mark Dickinson  added the comment:

FWIW, I do consider this a bug, albeit a minor one. I may find time to fix it 
at some point (but it's fine to leave it closed until that time comes).

--

___
Python tracker 

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

[issue47184] multiprocessing.set_start_method force argument is not documented

2022-04-05 Thread Sam Ezeh



Sam Ezeh  added the comment:

It's quite weird, the documentation says set_start_method "should not be used 
more than once in the program" twice.

The source code also contains the following line

```
# Type of default context -- underlying context can be set at most once
```

I'm not too familiar with the multiprocessing library but with the force 
parameter set to True, I don't understand why that can't happen. If there's a 
specific reason, maybe that should be documented too.

--

___
Python tracker 

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

[issue47184] multiprocessing.set_start_method force argument is not documented

2022-04-05 Thread Sam Ezeh



Change by Sam Ezeh :


--
keywords: +patch
nosy: +sam_ezeh
nosy_count: 2.0 -> 3.0
pull_requests: +30395
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/32339

___
Python tracker 

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

[issue47061] Deprecate modules listed in PEP 594

2022-04-05 Thread Brett Cannon



Brett Cannon  added the comment:


New changeset c1d93b6411f975d67e43942f1a2745a22983c18c by Brett Cannon in 
branch 'main':
bpo-47061: deprecate the `aifc` module (GH-32134)
https://github.com/python/cpython/commit/c1d93b6411f975d67e43942f1a2745a22983c18c


--

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



Steve Dower  added the comment:

Do we need to backport this?

--

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



Steve Dower  added the comment:


New changeset 944f09adfcc59f54432ac2947cf95f3465d90e1e by Jeremy Kloth in 
branch 'main':
bpo-47230: Silence compiler warnings on Windows from zlib 1.2.12 (GH-32337)
https://github.com/python/cpython/commit/944f09adfcc59f54432ac2947cf95f3465d90e1e


--

___
Python tracker 

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

[issue47027] subprocess.run(), subprocess.Popen() should accept file descriptor as cwd parameter



Gregory P. Smith  added the comment:

this mostly requires plumbing to accept an int as the cwd and plumb that 
through to the between fork and exec code to call `fchdir(cwd_fd)` on the `int` 
instead of chdir(cwd) on the `char*`.

the Modules/_posixsubprocess.c internals are a bit of a mess today with a 
bazillion parameters passed to internal functions which makes this a pain... I 
want to refactor things to use a struct and not need that, but adding this 
feature is doable regardless.

--
components: +Extension Modules -Library (Lib)

___
Python tracker 

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

[issue4833] Explicit directories for zipfiles

2022-04-05 Thread Ethan Furman



Ethan Furman  added the comment:


New changeset 050a8f94c678a05d506fe192c863c4a572178c42 by Sam Ezeh in branch 
'main':
bpo-4833: Add ZipFile.mkdir (GH-32160)
https://github.com/python/cpython/commit/050a8f94c678a05d506fe192c863c4a572178c42


--

___
Python tracker 

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

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception



Change by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception



Raymond Hettinger  added the comment:

One other thought.  The mental model for degrees() is just a simple scaling 
operation.  If done in pure Python, we would get *inf* rather than an 
OverflowError.  I don't see any value in breaking with the obvious substitution:

>>> sys.float_info.max * (180 / pi)
inf

--

___
Python tracker 

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

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception



Raymond Hettinger  added the comment:

I'm not interested in having this move forward.  AFAICT it doesn't solve any 
known user problems (no one has cared about this before or since this issue was 
opened).  It slightly slows the code.  And it might break some existing code 
that wasn't previously a need to catch an OverflowError.

Marking this as closed.  If someone thinks this is really needed, feel free to 
reopen.

--
resolution:  -> wont fix
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

[issue46576] test_peg_generator is extremely slow



Jeremy Kloth  added the comment:

My PR-32338 further reduces the runtime of the test another ~25%.

On my machine, before 85s, after 65s.

--

___
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



Change by Jeremy Kloth :


--
nosy: +jkloth
nosy_count: 3.0 -> 4.0
pull_requests: +30394
pull_request: https://github.com/python/cpython/pull/32338

___
Python tracker 

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

[issue47231] TarFile.getmember cannot work on tar sourced directory over 100 characters

2022-04-05 Thread Ethan Furman



Ethan Furman  added the comment:

Nosied others from issue21987.

--
nosy: +andrei.avk, ethan.furman, r.david.murray, vstinner

___
Python tracker 

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

[issue47006] PEP 646: Decide on substitution behavior

2022-04-05 Thread Matthew Rahtz



Matthew Rahtz  added the comment:

[Guido]

> 1. Some edge case seems to be that if *tuple[...] is involved on either side 
> we will never simplify.

Alright, let me think this through with some examples to get my head round it.

It would prohibit the following difficult case:

class C(Generic[*Ts]): ...
Alias = C[T, *Ts]
Alias[*tuple[int, ...]]  # Does not simplify; stays C[T, *Ts][*tuple[int, ...]]

That seems pretty reasonable. It would also prohibit these other relatively 
simple cases, but I guess that's fine:

Alias = C[*Ts]
Alias[*tuple[int, ...]]  # Does not simplify; stays C[*Ts][*tuple[int, ...]]

Alias = C[T, *tuple[int, ...]]
Alias[str]  # Does not simplify; stays C[T, *tuple[int, ...]][str]


> Or perhaps a better rule is that *tuple[...] is never simplified away (but 
> fixed items before and after it may be).

Is this to say that we effectively prohibit binding *tuple[...] to anything? If 
we can simplify without binding *tuple[...] to anything, then we do simplify, 
but otherwise, we don't simplify? So under this rule, the following WOULD work?

Alias = C[T, *tuple[int, ...]]
Alias[str]  # Simplifies to C[str, *tuple[int, ...]], because we didn't have to 
bind *tuple[int, ...] to do it


> 2. Another edge case is that if neither side has any starred items we will 
> always simplify (since this is the existing behavior in 3.10). This may raise 
> an error if the number of subscripts on the right does not match the number 
> of parameters on the left.

Alright, so this is business as usual.


> 3. If there's a single *Ts on the left but not on the right, we should be 
> able to simplify, which again may raise an error if there are not enough 
> values on the right, but if there are more than enough, the excess will be 
> consumed by *Ts (in fact that's the only way *Ts is fed).

So then:

class C(Generic[*Ts]): ...
Alias = C[T, *Ts]
Alias[()]  # Raises error
Alias[int] # Simplifies to C[int, *Ts]
Alias[int, str]# Simplifies to C[int, str]
Alias[int, str, bool]  # Simplifies to C[int, str, bool]

Yup, seems straightforward.


> 4. If there's a *Ts on the right but not on the left, we should _not_ 
> simplify, since whatever we have on the left serves as a constraint for *Ts.

Ok, so this is about the following situations:

class C(Generic[*Ts]): ...
Alias = C[T1, T2]
Alias[*Ts]  # Does not simplify; stays C[T1, T2][*Ts]

Yikes - in fact, this is actually super hairy; I hadn't thought about this edge 
case at all in the PEP.

Agreed that it seems reasonable not to simplify here.


> E.g. tuple[int, int][*Ts] constrains *Ts to being (int, int).

Was that a typo? Surely tuple[int, int][*Ts] isn't valid - since tuple[int, 
int] doesn't have any free parameters?


> 5. If there's exactly one *Ts on the left and one on the right, we _might__ 
> be able to simplify if the prefix and suffix of the __parameters__ match the 
> prefix and suffix of the subscript on the right. E.g. C[int, T, *Ts, 
> float][str, *Ts] can be simplified to C[int, str, *Ts, float]. OTOH C[int, T, 
> *Ts, float][*Ts] cannot be simplified -- but we cannot flag it as an error 
> either. Note that __parameters__ in this example is (T, Ts); we have to 
> assume that typevartuples in __parameters__ are always used as *Ts (since the 
> PEP recognizes no valid unstarred uses of Ts).

Ok, this also makes sense.


---

Still, though, doesn't the point that Serhiy brought up about __origin__, 
__parameters__ and __args__ still apply? In cases where we *don't* simplify, 
there'd still be the issue of what we'd set these things to be.

This evening I'll also revisit the PRs adding tests for substitution to try and 
make them a comprehensive reference as to what's currently possible.

--

___
Python tracker 

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

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception

2022-04-05 Thread Irit Katriel



Change by Irit Katriel :


--
keywords: +easy -patch
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

[issue47139] pthread_sigmask needs SIG_BLOCK behaviour explaination



Gregory P. Smith  added the comment:

The "trick" wouldn't be too useful though as this API can't block and the 
signal flag needs to be processed on the main thread. So I guess documentation 
it is.

The way I think of this is that the signal.pthread_sigmask API is pretty low 
level. After that API is called, no more signals will _reach the process_, but 
the interpreter may process some that happened beforehand. So installing a 
handler is indeed appropriate.

Also, it is entirely possible for C extension modules or code embedding Python 
to call pthread_sigmask in its own threads outside of the Python runtimes 
knowledge. So we us tracking what signals are blocked on our own may not be 
accurate.  We could instead change the eval loop signal processing code to call 
`pthread_sigmask(SIG_UNBLOCK, NULL /* set */, );` to retrieve the 
processes current mask to decide if the flagged signals should be processed by 
Python or not.

BUT... I can imagine complex race cases where that'd surprise people who are 
chaining multiple signal handlers such as one from outside of Python that saved 
the Python handler and calls it afterwards.  Their C/process-level handler 
would be called, would chain to Python's "record that signal X happened and set 
the bit" handler, but Python wouldn't then be guaranteed to call the Python 
handler code if the sigmask changed before the eval loop did its pending signal 
check.

So I'm still inclined to keep this simple and stick with just documenting best 
practices for now.  An implementation of masking from the python eval handler 
may need to be something conditionally controllable for differing application 
situations if added.

--

___
Python tracker 

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

[issue47231] TarFile.getmember cannot work on tar sourced directory over 100 characters

2022-04-05 Thread Chris Fernald

New submission from Chris Fernald :

A fix was made to unify handling of the trailing slash in TarFile.getmember
related to https://bugs.python.org/issue21987. This change fixed the <100
character case, but made it so directories over 100 character which come from a
tar file can no longer be accessed through getmember, even if returned from
getnames. This appears to be because internal to tarfile, member names still
include the trailing slash on directories over 100 characters but getmember
will always remove the trailing slash from the provided name so the comparison
will always fail.

A simple example of this is as follows using 3.10.4.

1. Download:
https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz

2. place attached python script in same directory

3. run on 3.8.2 -> fails to get stripped version of path (line 16)

4. run on 3.10.4 -> fails to get even unstripped version (line 12 & 16)

--
components: Library (Lib)
files: tarfile_repro.py
messages: 416793
nosy: cfernald, serhiy.storchaka
priority: normal
severity: normal
status: open
title: TarFile.getmember cannot work on tar sourced directory over 100
characters
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50721/tarfile_repro.py

___
Python tracker

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

[issue47230] New compiler warnings with latest zlib



Change by Jeremy Kloth :


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

___
Python tracker 

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

[issue47230] New compiler warnings with latest zlib



New submission from Jeremy Kloth :

The latest zlib (1.2.12) introduces 3 new compiler warnings.  Now being an 
external library, I do not think we generally patch them, so I propose to 
simply silence the warnings for the offending file.

For reference, the problem comes from:

--- deflate.h.old   2022-04-05 11:27:26.869042900 -0600
+++ deflate.h.new   2022-04-05 11:26:11.512039600 -0600
@@ -329,8 +329,8 @@
 # define _tr_tally_dist(s, distance, length, flush) \
   { uch len = (uch)(length); \
 ush dist = (ush)(distance); \
-s->sym_buf[s->sym_next++] = dist; \
-s->sym_buf[s->sym_next++] = dist >> 8; \
+s->sym_buf[s->sym_next++] = (uch)dist; \
+s->sym_buf[s->sym_next++] = (uch)(dist >> 8); \
 s->sym_buf[s->sym_next++] = len; \
 dist--; \
 s->dyn_ltree[_length_code[len]+LITERALS+1].Freq++; \

--
components: Build, Windows
messages: 416792
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: New compiler warnings with latest zlib
type: compile error
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

[issue45354] test_winconsoleio fails on Windows 11



Change by Jeremy Kloth :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue47131] Speedup test_unparse



Change by Jeremy Kloth :


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

[issue47131] Speedup test_unparse



Jeremy Kloth  added the comment:

Resolved with merged PR.

--
resolution:  -> fixed

___
Python tracker 

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

[issue47229] IDLE / Thonny UI crashes on Chromebook Linux/Bullseye

2022-04-05 Thread Doug Bates



New submission from Doug Bates :

Having installed IDLE on Chromebbok/Linux Bullseye, on startup the UI crashes 
as soon as a menu item is selected.  Also when trying to use Thonny. Other 
packages seem OK.

Used to work fine under Buster, but not since fresh install to Bullseye.

Apologies from my knowledge/skill level.

--
assignee: terry.reedy
components: IDLE
files: Thonny crashes.txt
messages: 416790
nosy: Coloneldare, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE / Thonny UI crashes on Chromebook Linux/Bullseye
type: crash
Added file: https://bugs.python.org/file50720/Thonny crashes.txt

___
Python tracker 

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

[issue47136] The variable module in the class body getting an undesirable value from prepare of the metaclass

2022-04-05 Thread Ethan Furman



Ethan Furman  added the comment:

You are using the same generic example -- it does show the issue you are 
concerned with, but offers no rational for why we should "fix" it -- in other 
words, we cannot tell if it's actually broken.

Please provide an example of code you are actually using -- a trimmed down 
metaclass is fine, but it should show the kinds of names you are changing to, 
why you want to change the names, etc.

Maybe this is a just a documentation issue, or maybe it's an overlooked case 
that should be supported in Python -- we cannot tell based solely on your 
generic example.

--

___
Python tracker 

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

[issue17004] Expand zipimport to include other compression methods



Change by Christian Heimes :


--
versions: +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

[issue47212] Minor issues in reported Syntax errors

2022-04-05 Thread Alex Waygood



Change by Alex Waygood :


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

[issue47027] subprocess.run(), subprocess.Popen() should accept file descriptor as cwd parameter

2022-04-05 Thread Yann Droneaud



Yann Droneaud  added the comment:

I looked at posixmodule: os.chdir() accepts a file descriptor.
Maybe it can be possible to invoke it from _posixsubprocess.c instead of 
calling chdir().

--

___
Python tracker 

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

[issue47212] Minor issues in reported Syntax errors

2022-04-05 Thread miss-islington



miss-islington  added the comment:


New changeset 94609e3192f15636c760a48c4c1c2c236fac3217 by Matthieu Dartiailh in 
branch '3.10':
[3.10] Backport bpo-47212 (GH-32302) to Python 3.10 (GH-32334)
https://github.com/python/cpython/commit/94609e3192f15636c760a48c4c1c2c236fac3217


--
nosy: +miss-islington

___
Python tracker 

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

[issue47009] Streamline list.append for the common case



Christian Heimes  added the comment:


New changeset 9e88b572fb904b172f9e344069fb7118f1cee517 by Christian Heimes in 
branch 'main':
bpo-47009: Fix assert on big endian (GH-32332)
https://github.com/python/cpython/commit/9e88b572fb904b172f9e344069fb7118f1cee517


--

___
Python tracker 

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

[issue42012] typing support in wsgiref

2022-04-05 Thread Sebastian Rittau



Change by Sebastian Rittau :


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

___
Python tracker 

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

[issue46607] Add DeprecationWarning to configparser's LegacyInterpolation



Gregory P. Smith  added the comment:


New changeset 75280944e5ca957eec7f814b9d0608fc84fc5811 by Hugo van Kemenade in 
branch 'main':
bpo-46607: Add DeprecationWarning for LegacyInterpolation, deprecated in docs 
since 3.2 (GH-30927)
https://github.com/python/cpython/commit/75280944e5ca957eec7f814b9d0608fc84fc5811


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

[issue42012] typing support in wsgiref

2022-04-05 Thread Dong-hee Na



Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue47212] Minor issues in reported Syntax errors

2022-04-05 Thread Matthieu Dartiailh



Change by Matthieu Dartiailh :


--
pull_requests: +30391
pull_request: https://github.com/python/cpython/pull/32334

___
Python tracker 

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

[issue47203] ImportError: DLL load failed while importing binascii: %1 is not a valid Win32 application.



Steve Dower  added the comment:

> There is something fundamentally wrong with the way modules built into the 
> interpreter DLL (python3x.dll) are loaded if anything in sys.path or the 
> system PATH can cause an import to fail.

Probably there was also shadowing involved, since the built-in module doesn't 
try to load anything else. Would be nice to know for sure (@Matthew) to make 
sure we don't have some other issue here, but you're right, I don't see any way 
for this to happen without other causes.

--

___
Python tracker 

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

[issue47226] Unexpected indent message



Change by Terry J. Reedy :


--
nosy:  -paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware

___
Python tracker 

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

[issue47226] Unexpected indent message



Terry J. Reedy  added the comment:

" keys = pygame.key.get_pressed() is showing error called unexpected indent"

The problem is that the keys line in indented one less space than the line 
above.  A shorter example below.

if True:
a = 1
   b = 2

SyntaxError: unindent does not match any outer indentation level


This issue tracker is not a help forum.  Next time, please post instead to 
something like python-list.  Give a minimal snippet of code, like my example 
above, showing the problem and the complete error message. Also, copy and paste 
the error message instead of an image.

Please read https://stackoverflow.com/help/minimal-reproducible-example
about how to ask good questions.

This is in no way an IDLE issue.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: if we write a line of code like i wrote keys = pygame.key.get_pressed() 
is showing error called unexpected indent -> Unexpected indent message

___
Python tracker 

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

[issue47226] if we write a line of code like i wrote keys = pygame.key.get_pressed() is showing error called unexpected indent



Change by Kaushal Sai v :


--
components: +IDLE

___
Python tracker 

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

[issue47088] Implement PEP 675 (LiteralString)



Change by Jelle Zijlstra :


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

[issue47088] Implement PEP 675 (LiteralString)



Jelle Zijlstra  added the comment:


New changeset cfb849a326e52a4edc577112ebf60e1d9d0d7fdb by Jelle Zijlstra in 
branch 'main':
bpo-47088: Add typing.LiteralString (PEP 675) (GH-32064)
https://github.com/python/cpython/commit/cfb849a326e52a4edc577112ebf60e1d9d0d7fdb


--

___
Python tracker 

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

[issue47226] if we write a line of code like i wrote keys = pygame.key.get_pressed() is showing error called unexpected indent



Change by Kaushal Sai v :


--
status: pending -> open
Added file: https://bugs.python.org/file50719/python problem.PNG

___
Python tracker 

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

[issue41930] Wrap sqlite3_serialize API in sqlite3 module



Jelle Zijlstra  added the comment:

Thanks, this will be in Python 3.11.

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

[issue41930] Wrap sqlite3_serialize API in sqlite3 module



Jelle Zijlstra  added the comment:


New changeset a7551247e7cb7010fb4735281f1afa4abeb8a9cc by Erlend Egeberg 
Aasland in branch 'main':
bpo-41930: Add support for SQLite serialise/deserialise API (GH-26728)
https://github.com/python/cpython/commit/a7551247e7cb7010fb4735281f1afa4abeb8a9cc


--
nosy: +JelleZijlstra

___
Python tracker 

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

[issue47226] if we write a line of code like i wrote keys = pygame.key.get_pressed() is showing error called unexpected indent



Change by Kaushal Sai v :


--
status: open -> pending

___
Python tracker 

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

[issue47226] if we write a line of code like i wrote keys = pygame.key.get_pressed() is showing error called unexpected indent



Kaushal Sai v  added the comment:

the error mesessage is tha unexpected incident

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

___
Python tracker 

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

[issue47226] if we write a line of code like i wrote keys = pygame.key.get_pressed() is showing error called unexpected indent