[issue40280] Consider supporting emscripten/webassembly as a build target

2022-04-07 Thread Christian Heimes


Christian Heimes  added the comment:


New changeset 2b16a08bc77475917dd5c96417aef4c5210b45ac by Christian Heimes in 
branch 'main':
bpo-40280: Detect missing threading on WASM platforms (GH-32352)
https://github.com/python/cpython/commit/2b16a08bc77475917dd5c96417aef4c5210b45ac


--

___
Python tracker 

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



[issue47245] potential undefined behavior with subprocess using vfork() on Linux

2022-04-07 Thread Alexey Izbyshev


Alexey Izbyshev  added the comment:

In short: both this bug report and [1] are invalid.

The reason why doing syscall(SYS_vfork) is illegal is explained by Florian 
Weimer in [2]:

>The syscall function in glibc does not protect the on-stack return address 
>against overwriting, so it can't be used to call SYS_vfork on x86.

This is off-topic here because CPython calls vfork() via libc, but I'll still 
expand the Florian's comment. Suppose one wants to write my_vfork() wrapper 
over vfork syscall. When vfork syscall returns the first time, my_vfork() has 
to return to its caller. This necessarily involves knowing the return address. 
On some architectures this return address is stored on the stack by the caller 
(e.g. x86). The problem is that any data in my_vfork() stack frame can be 
overwritten by its caller once it returns the first time. Then, when vfork 
syscall returns the second time, my_vfork() could be unable to return to its 
caller because the data it fetches from its (now invalid) stack frame is 
garbage. This is precisely what happens when one implements my_vfork() as 
syscall(SYS_vfork). To avoid this, the most common strategy is to store the 
return address into a register that's guaranteed to be preserved around syscall 
by the OS ABI. For example, the x86-64 musl implementation [3] stores the retur
 n address in rdx (which is preserved around syscall) and then restores it 
after syscall (both on the first and the second return of the syscall).

Now back to CPython. The real problem with stack sharing between the child and 
the parent could be due to compiler bugs, e.g. if a variable stored on the 
stack is modified in the child branch of "if (vfork())", but the compiler 
assumes that some other variable sharing the stack slot with the first one is 
*not* modified in the parent branch (i.e. after vfork() returns the second 
time). But all production compilers handle vfork() (and setjmp(), which has a 
similar issue) in a special way to avoid this, and GCC has 
__attribute__((returns_twice)) that a programmer could use for custom functions 
behaving in this way (my_vfork() would have to use this attribute).

Regarding a separate stack for the child and clone(CLONE_VM|CLONE_VFORK), I 
considered this in #35823, but this has its own problems. The most important 
one is that CPython would be in business of choosing the correct stack size for 
the child's stack, but CPython is *not* in control of all the code executing in 
the child because it calls into libc. In practice, people use various 
LD_PRELOAD-based software that wraps various libc functions (e.g. Scratchbox 2 
build environment for Sailfish OS is an LD_PRELOAD-based sandbox), so even 
common-sense assumptions like "execve() in libc can't use a lot of stack!" 
might turn out to be wrong. CPython *could* work around that by using direct 
syscalls for everything in the child, or by using some "large" size that 
"should be enough for everybody", but I wouldn't want to see that unless we 
have a real problem with vfork(). Note that vfork()-based posix_spawn() 
implementations in C libraries do *not* have this problem because they fully 
control all
  code in the child (e.g. they would use a non-interposable execve() symbol or 
a direct syscall).

> Immediate action item: Add a way for people to disable vfork at runtime by 
> setting a flag in the subprocess module, just in case.

I don't think any action is needed at all, and I think this issue should be 
closed.

> Our current assumptions around the use of vfork() are very much glibc 
> specific.

Could you clarify what glibc-specific assumptions you mean? In #35823 I tried 
to use as little assumptions as possible.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215813
[2] https://bugzilla.kernel.org/show_bug.cgi?id=215813#c2
[3] 
https://git.musl-libc.org/cgit/musl/tree/src/process/x86_64/vfork.s?id=ced75472d7e3d73d5b057e36ccbc7b7fcba95104

--
nosy: +izbyshev

___
Python tracker 

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



[issue43588] [Subinterpreters]: use static variable under building Python with --with-experimental-isolated-subinterpreters cause crash.

2022-04-07 Thread Kumar Aditya


Kumar Aditya  added the comment:

Most of the static variables were removed by GH-31366 so I closed those PRs as 
they were outdated, however some static variable still exist.

--
nosy: +kumaraditya

___
Python tracker 

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



[issue43528] "connect_read_pipe" raises errors on Windows for STDIN

2022-04-07 Thread Kumar Aditya


Change by Kumar Aditya :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ProactorEventLoop doesn't support stdin/stdout nor files with 
connect_read_pipe/connect_write_pipe

___
Python tracker 

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



[issue47246] Race condition in `threadig.Thread._wait_for_tstate_lock`

2022-04-07 Thread Dieter Maurer


New submission from Dieter Maurer :

I have observed an `AssertionError (assert self._is_stopped)` in 
`threading.Thread._wait_for_tstate_lock`. This indicates that Python's internal 
state has been corrupted.

The analysis revealed the following race condition:
`_wait_for_tstate:lock` contains the code:
```
lock.release()
self._stop()
```
The `lock.release()` allows a conflicting call to execute. If this happens 
before `self._stop()` has executed `self._is_stopped = True`, the 
`AssertionError` is raised.

I suggest to give `_stop` an additional parameter `locked` with default 
`False`. In indicates whether the caller holds the `tstate_lock`. If this is 
the case, `_stop` releases the lock after it has ensured a consistent state 
(esspecially set `_is_stopped` to `True`). With this modification to `_stop` 
the two lines above can be replaced by `self._stop(locked=True)`.

--
components: Library (Lib)
messages: 416919
nosy: dmaurer
priority: normal
severity: normal
status: open
title: Race condition in `threadig.Thread._wait_for_tstate_lock`
type: behavior
versions: Python 3.10, Python 3.11, 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



[issue47246] Race condition in `threadig.Thread._wait_for_tstate_lock`

2022-04-07 Thread Dieter Maurer


Dieter Maurer  added the comment:

Apparently, the explanation is not that easy: `_stop` first sets `_is_stopped` 
to `True` and only then `_tstate_lock` to `None`. Therefore, the race should 
not cause the `AssertionError`.

I observed the `AssertionError` in Python 3.6. The related `threading` code is 
however almost identical to that in Python 3.11.

--

___
Python tracker 

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



[issue47247] Default arguments for access 'mode' parameters in pathlib and os should display as octal literals

2022-04-07 Thread Aidan Woolley


New submission from Aidan Woolley :

E.g. 0o777 rather than 511

This is a regression since the docs for 3.9

Affected functions/methods:
pathlib.Path.mkdir
pathlib.Path.touch
os.open
os.mkdir
os.makedirs
os.mkfifo
os.mknod

--
assignee: docs@python
components: Documentation
messages: 416921
nosy: AidanWoolley, docs@python
priority: normal
severity: normal
status: open
title: Default arguments for access 'mode' parameters in pathlib and os should 
display as octal literals
type: enhancement
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



[issue47246] Race condition in `threadig.Thread._wait_for_tstate_lock`

2022-04-07 Thread Dieter Maurer


Dieter Maurer  added the comment:

The observation was caused by a bug which has been fixed in newer Python 
versions (3.9+ if I remember correctly). `isAlive` was called on a 
`_DummyThread` (while `_DummyThread` overides `is_alive` it had forgotten to 
override `isAlive` as well).

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue47248] Possible slowdown of regex searching in 3.11

2022-04-07 Thread Mark Shannon


New submission from Mark Shannon :

The 3 regular expression benchmarks in the pyperformance suite, regex_v8, 
regex_effbot and regex_dna show slowdowns between 3% and 10%.

Looking at the stats, nothing seems wrong with specialization or the memory 
optimizations.

Which strongly suggests a regression in the sre module itself, but I can't say 
so for certain.

--
keywords: 3.11regression
messages: 416923
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Possible slowdown of regex searching in 3.11
type: performance
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



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

2022-04-07 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

It would be nice if the class creation process was documented a bit 
better. Here is my experiment to see what is going on:

```
# the global `__name__` is normally the module's name.
__name__ = "something"

class Meta_default_prepare(type):
def __new__(meta, name, bases, ns):
print("ns for", name, "\n   ", ns)
return super().__new__(meta, name, bases, ns)

class Meta_custom_prepare(Meta_default_prepare):
def __prepare__(meta, *args):
return {'__name__': 'another_name'}

class Spam(metaclass=Meta_default_prepare):
pass

class Eggs(metaclass=Meta_custom_prepare):
pass

print("Spam module and name:", Spam.__module__, Spam.__name__)
print("Eggs module and name:", Eggs.__module__, Eggs.__name__)

```

And the output in Python 3.10 is:

```
ns for Spam 
{'__module__': 'something', '__qualname__': 'Spam'}
ns for Eggs 
{'__name__': 'another_name', '__module__': 'another_name', '__qualname__': 
'Eggs'}
Spam module and name: something Spam
Eggs module and name: another_name Eggs
```

My take on this is that if the key __name__ is not present, the value of 
the class __module__ is taken from the global variable. So far so good.

But if '__name__' is a key in the mapping returned by __prepare__, it 
gets left in the class dict, and gets used to set the class __module__ 
as well.

But in neither case does it get used to set the class __name__.

I cannot decide whether or not this makes sense to me.

--

___
Python tracker 

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



[issue1666807] Incorrect file path reported by inspect.getabsfile()

2022-04-07 Thread Ewout ter Hoeven


Ewout ter Hoeven  added the comment:

When running anything with a freshly installed version of Python 3.11.0a7 on 
64-bit Windows, the following message is printed:

---
pydev debugger: CRITICAL WARNING: This version of python seems to be 
incorrectly compiled (internal generated filenames are not absolute)
pydev debugger: The debugger may still function, but it will work slower and 
may miss breakpoints.
pydev debugger: Related bug: http://bugs.python.org/issue1666807
---

--
nosy: +EwoutH
versions: +Python 3.11 -Python 2.5

___
Python tracker 

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



[issue47249] test_multiprocessing_fork probabilistic failure

2022-04-07 Thread tongxiaoge


New submission from tongxiaoge :

This problem is probabilistic. I run Python3 all test cases on OBS. In recent 
months, there have been about three times that the test cases hang on 
probabilistically. The current version with problems is 3.10.2, this problem 
has also appeared in 3.10.0 and 3.9.9.

--
components: Tests
files: test hang on.png
messages: 416926
nosy: sxt1001
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork probabilistic failure
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50726/test hang on.png

___
Python tracker 

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



[issue47249] test_multiprocessing_fork probabilistic failure

2022-04-07 Thread tongxiaoge


tongxiaoge  added the comment:

I previously suspected the patch d0d83a9 
(https://github.com/python/cpython/commit/d0d83a94314402366e04e7ea2638f809510eb830)
 fixed this problem, so I upgraded python3 to 3.10.2, but the problem still 
occurred.

--

___
Python tracker 

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



[issue47248] Possible slowdown of regex searching in 3.11

2022-04-07 Thread Ma Lin


Ma Lin  added the comment:

Could you give the two versions? I will do a git bisect.

I tested 356997c~1 and 356997c [1], msvc2022 non-pgo release build:

# regex_dna ###
an +- std dev: 151 ms +- 1 ms -> 152 ms +- 1 ms: 1.01x slower
t significant

# regex_effbot ###
an +- std dev: 2.47 ms +- 0.01 ms -> 2.46 ms +- 0.02 ms: 1.00x faster
t significant

# regex_v8 ###
an +- std dev: 21.7 ms +- 0.1 ms -> 22.4 ms +- 0.1 ms: 1.03x slower
gnificant (t=-30.82)

https://github.com/python/cpython/commit/35699721a3391175d20e9ef03d434675b496

--
nosy: +malin

___
Python tracker 

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



[issue47247] Default arguments for access 'mode' parameters in pathlib and os should display as octal literals

2022-04-07 Thread Eric V. Smith


Eric V. Smith  added the comment:

I think this is a duplicate of #46782.

--
nosy: +eric.smith

___
Python tracker 

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



[issue47250] Add object.__getstate__() introduced a refleak

2022-04-07 Thread STINNER Victor


New submission from STINNER Victor :

The following change introduced reference leaks:
---
commit 884eba3c76916889fd6bff3b37b8552bfb4f9566
Author: Serhiy Storchaka 
Date:   Wed Apr 6 20:00:14 2022 +0300

bpo-26579: Add object.__getstate__(). (GH-2821)

Copying and pickling instances of subclasses of builtin types
bytearray, set, frozenset, collections.OrderedDict, collections.deque,
weakref.WeakSet, and datetime.tzinfo now copies and pickles instance 
attributes
implemented as slots.
---


Example of buildbot failure.

AMD64 RHEL8 Refleaks 3.x:
https://buildbot.python.org/all/#builders/259/builds/355

14 tests failed:
test_bytes test_copy test_datetime test_deque test_descr
test_distutils test_minidom test_ordered_dict test_pickle test_set
test_shutil test_tarfile test_typing test_weakset


Example of leak:

$ ./python -m test -R 3:3 test_descr -m test_issue24097
(...)
beginning 6 repetitions
123456
..
test_descr leaked [1, 1, 1] references, sum=3
test_descr failed (reference leak)
(...)

--
components: Interpreter Core
messages: 416930
nosy: corona10, erlendaasland, pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add object.__getstate__() introduced a refleak
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



[issue26579] Support pickling slots in subclasses of common classes

2022-04-07 Thread STINNER Victor


STINNER Victor  added the comment:

> bpo-26579: Add object.__getstate__(). (GH-2821)
> https://github.com/python/cpython/commit/884eba3c76916889fd6bff3b37b8552bfb4f9566

This change introduced reference leaks: see bpo-47250.

--

___
Python tracker 

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



[issue47250] Add object.__getstate__() introduced refleaks

2022-04-07 Thread STINNER Victor


Change by STINNER Victor :


--
title: Add object.__getstate__() introduced a refleak -> Add 
object.__getstate__() introduced refleaks

___
Python tracker 

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



[issue47120] Make all jump opcodes relative

2022-04-07 Thread Irit Katriel


Change by Irit Katriel :


--
pull_requests: +30427
pull_request: https://github.com/python/cpython/pull/32400

___
Python tracker 

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



[issue1666807] Incorrect file path reported by inspect.getabsfile()

2022-04-07 Thread Guido van Rossum


Guido van Rossum  added the comment:

@Ewout, the current workaround (until pydevd is fixed) is to add 
-Xfrozen_modules=off to the Python command line.

--

___
Python tracker 

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



[issue40280] Consider supporting emscripten/webassembly as a build target

2022-04-07 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Christian: IDLE and test_idle require threading. I once tested for threading in 
test_idle (not sure about IDLE itself) but removed the test when threading was 
made supposedly non-optional.  Test_idle still tests for tkinter and idlelib.  
For PR 32352. did you miss IDLE's requirement or is tkinter and hence IDLE and 
its test not included on WASM/emscripten?  Will it never be?

--
nosy: +terry.reedy

___
Python tracker 

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



[issue40280] Consider supporting emscripten/webassembly as a build target

2022-04-07 Thread Christian Heimes


Christian Heimes  added the comment:

In GH-32352 I changed only tests that I was able to execute under 
wasm32-emscripten. As far as I know TK does not build for WASM. Somebody would 
have to port TCL/TK to WebGL or SDL2 to make it work in the browser.

--

___
Python tracker 

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



[issue47250] Add object.__getstate__() introduced refleaks

2022-04-07 Thread Brandt Bucher


Brandt Bucher  added the comment:

Found it. This line should be removed:

https://github.com/python/cpython/blob/4c92427fb85e420404a9bd26347e32acc1bbd3b7/Objects/typeobject.c#L5033

--
nosy: +brandtbucher

___
Python tracker 

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



[issue47250] Add object.__getstate__() introduced refleaks

2022-04-07 Thread Dong-hee Na


Change by Dong-hee Na :


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

___
Python tracker 

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



[issue39187] urllib.robotparser does not respect the longest match for the rule

2022-04-07 Thread Andre Burgaud


Andre Burgaud  added the comment:

Hi Matele,

Thanks for looking into this issue.

I have seen indeed some implementations that were based on the Python 
implementation and that had the same problems. The Crystal implementation in 
particular (as far as I remember, as it was a while ago). As a reference, I 
used the Google implementation https://github.com/google/robotstxt that 
respects the internet draft 
https://datatracker.ietf.org/doc/html/draft-koster-rep-00.

The 2 main points are described in section 
https://datatracker.ietf.org/doc/html/draft-koster-rep-00#section-2.2.2, 
especially in the following paragraph:

   "To evaluate if access to a URI is allowed, a robot MUST match the
   paths in allow and disallow rules against the URI.  The matching
   SHOULD be case sensitive.  The most specific match found MUST be
   used.  The most specific match is the match that has the most octets.
   If an allow and disallow rule is equivalent, the allow SHOULD be
   used."

1) The most specific match found MUST be used.  The most specific match is the 
match that has the most octets.
2) If an allow and disallow rule is equivalent, the allow SHOULD be used.

In the robots.txt example you provided, the longest rule is Allow: 
/wp-admin/admin-ajax.php. Therefore it will take precedence over the other 
shorter Disallow rule for the sub-directory admin-ajax.php that should be 
allowed. To achieve that, the sort of the rule should list the Allow rule first.

I'm currently traveling. I'm sorry if my explanations sound a bit limited. If 
it helps, I can pickup this discussion when I'm back home, after mid-April. In 
particular, I can run new tests with Python 3.10, since I raised this potential 
problem a bit more than two years ago and that I may need to refresh my memory 
:-) 

In the meantime, let me know if there is anything that I could provide to give 
a clearer background. For example, are you referring to the 2 issues I 
highlighted above, or is it something else that you are thinking about. Also, 
could you point me to the other robots checkers that you looked at?

Thanks!

Andre

--

___
Python tracker 

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



[issue47250] New object.__getstate__() method introduced refleaks

2022-04-07 Thread Alex Waygood


Change by Alex Waygood :


--
title: Add object.__getstate__() introduced refleaks -> New 
object.__getstate__() method introduced refleaks

___
Python tracker 

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



[issue45542] Using multiple comparison operators can cause performance issues

2022-04-07 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



[issue47251] Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE

2022-04-07 Thread Pieter Eendebak


New submission from Pieter Eendebak :

The implementations of BINARY_SUBSCR_LIST_INT and BINARY_SUBSCR_TUPLE_INT are 
almost identical. They can be merged, so there is one opcode less and the code 
is shared.

--
components: Interpreter Core
messages: 416937
nosy: pieter.eendebak
priority: normal
severity: normal
status: open
title: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
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



[issue47251] Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE

2022-04-07 Thread Pieter Eendebak


Change by Pieter Eendebak :


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

___
Python tracker 

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



[issue47177] Frames should store next_instr instead of lasti

2022-04-07 Thread Brandt Bucher


Brandt Bucher  added the comment:


New changeset ef6a482b0285870c45f39c9b17ed827362b334ae by Brandt Bucher in 
branch 'main':
bpo-47177: Replace `f_lasti` with `prev_instr` (GH-32208)
https://github.com/python/cpython/commit/ef6a482b0285870c45f39c9b17ed827362b334ae


--

___
Python tracker 

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



[issue47177] Frames should store next_instr instead of lasti

2022-04-07 Thread Brandt Bucher


Change by Brandt Bucher :


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



[issue47179] pymalloc should align to max_align_t

2022-04-07 Thread Ronald Oussoren


Ronald Oussoren  added the comment:

> If we want to respect sizeof(max_align_t) alignment, we can compute 
> sizeof(max_align_t) in configure and uses the result in obmalloc.c. I expect 
> that it's either 16 or 32, so we can maybe just hardcode ALIGNMENT_SHIFT 
> using something like: "if == 32 ... #elif == 16 ... #else #error ...".

This should be "alignof(max_align_t)" instead of "sizeof(...)". The size itself 
is not relevant.

BTW, on macOS/arm64 alignof(max_align_t) is 8, not 16 (as the code seems to 
expect given the pointer size). This is harmless of course.

--
nosy: +ronaldoussoren

___
Python tracker 

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



[issue46522] concurrent.futures.__getattr__ raises the wrong AttributeError message

2022-04-07 Thread Gobot1234


Gobot1234  added the comment:

I was just looking through the git diff for this PR and found a bug in this 
https://github.com/python/cpython/pull/30887/files#diff-2828caacf5c85c7bd6023ea0e4a381cc5c65179a9822398534c5e9ad9ccbd90dR73.
 There's a missing f on the io __getattr__'s message

--
nosy: +Gobot1234

___
Python tracker 

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



[issue46180] Button clicked failed when mouse hover tooltip and tooltip destroyed

2022-04-07 Thread PySimpleGUI


PySimpleGUI  added the comment:

Hi Ned... thank you kindly for the response.  

Code was provided on Dec 26, 2021 that reproduces the problem.  We've taken the 
extra step of verifying on Linux and Mac that indeed the problem is on those 
operating systems as well.  

I'm struggling to understand why it's now suggested that the way to get help 
from the tkinter team is to also produce code directly in TCl/TK directly or 
that posts on StackOverflow would be of help.  It appears to be a bug that's in 
the lower-level code that happened between releases 8.6.11 and 8.6.12.  We're 
not looking for a workaround, which I suppose is the purpose of posting on 
StackOverflow, we're looking for a fix.

We're doing our best to follow solid best practices of reproducing problems, 
providing code to demonstrate the bug, and using the official bug reporting 
mechanism (bugs.python.org). Any help that can be provided in getting the right 
persons from the tkinter team responsible for the code is greatly appreciated.  
Greatly appreciated!

--

___
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-07 Thread 15r10nk


Change by 15r10nk <15r10nk-python-iss...@polarbit.de>:


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

___
Python tracker 

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



[issue47252] socket.makefile documentation is missing data regarding the 'buffering' parameter

2022-04-07 Thread Alon Menczer


New submission from Alon Menczer :

The documentation of the socket.makefile method is missing data regarding the 
behavior of the `buffering` parameter.

--
assignee: docs@python
components: Documentation
messages: 416943
nosy: alon.menczer, docs@python
priority: normal
severity: normal
status: open
title: socket.makefile documentation is missing data regarding the 'buffering' 
parameter
type: enhancement
versions: Python 3.10, Python 3.11, 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



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

2022-04-07 Thread 15r10nk


15r10nk <15r10nk-python-iss...@polarbit.de> added the comment:

I moved the line.
Is there anything else required? unittests?

--

___
Python tracker 

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



[issue20907] behavioral differences between shutil.unpack_archive and ZipFile.extractall

2022-04-07 Thread Semyon


Change by Semyon :


--
nosy: +MarSoft

___
Python tracker 

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



[issue47253] LOAD_GLOBAL instruction with wrong source position

2022-04-07 Thread 15r10nk


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

The LOAD_GLOBAL instruction has a different/wrong source position if it refers 
the name of an imported module.

--
files: test3.py
messages: 416945
nosy: 15r10nk
priority: normal
severity: normal
status: open
title: LOAD_GLOBAL instruction with wrong source position
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50727/test3.py

___
Python tracker 

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



[issue47245] potential undefined behavior with subprocess using vfork() on Linux?

2022-04-07 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

Thanks!  I agree with you that this is probably not an actual problem on Linux.

_I did look at the various glibc architecture vfork.s implementations: Cute 
tricks used on some where they need to avoid a stack modifying traditional 
return from vfork()._

As for glibc specifics, I'm mostly thinking of the calls we do in the child.

According to the "Standard Description (POSIX.1)" calls to anything other than 
`_exit()` or `exec*()` are not allowed.  But the longer "Linux Description" in 
that vfork(2) man page does not say that.  Which implies merely by omission 
that calls to other things are okay so long as you understand everything they 
do to the process heap/stack/state.  (I wish it were *explicit* about that)

Some of the calls we do from our child_exec() code... many are likely "just" 
syscall shims and thus fine - but that is technically up to libc.

A few others are Py functions that go elsewhere in CPython and while they may 
be fine for practical reasons today with dangerous bits on conditional branches 
that technically should not be possible to hit given the state by the time 
we're at this point in _posixsubprocess, pose a future risk - anyone touching 
implementations of those is likely unaware of vfork'ed child limitations that 
must be met.

For example if one of the potential code paths that trigger an indirect 
Py_FatalError() is hit... that fatal exit code is definitely not 
post-vfork-child safe.  The pre-exec child dying via that could screw up the 
vfork parent process's state.

--
title: potential undefined behavior with subprocess using vfork() on Linux -> 
potential undefined behavior with subprocess using vfork() on Linux?

___
Python tracker 

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



[issue47103] Copy pgort140.dll when building for PGO

2022-04-07 Thread Steve Dower


Steve Dower  added the comment:


New changeset b0ec17b6d9e0fb61081b6d15a1b2a14b607851b7 by Steve Dower in branch 
'3.10':
bpo-47103: Copy pgort140.dll into output directory when building PGInstrument 
on Windows (GH-32083)
https://github.com/python/cpython/commit/b0ec17b6d9e0fb61081b6d15a1b2a14b607851b7


--

___
Python tracker 

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



[issue47254] enhanced dir?

2022-04-07 Thread apostofes


New submission from apostofes :

current dir gives output like this,
```
from collection import OrderedDict
od = OrderedDict({'a': 1, 'b': 2, 'c': 3})
print(dir(od))
```
```
['__class__', '__contains__', '__delattr__', '__delitem__', '__dict__',
 '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
 '__getitem__', '__gt__', '__hash__', '__init__', '__init_subclass__',
 '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__',
 '__reduce_ex__', '__repr__', '__reversed__', '__setattr__', '__setitem__',
 '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys',
 'get', 'items', 'keys', 'move_to_end', 'pop', 'popitem', 'setdefault',
 'update', 'values']
```
but wouldn't it be better if the output was like this,
```

{'OrderedDict': {'__contains__', '__delitem__', '__dir__', '__eq__',
  '__format__', '__ge__', '__getitem__', '__gt__', '__init__', 
'__init_subclass__',
  '__iter__', '__le__', '__lt__', '__ne__', '__reduce__', 
'__reduce_ex__',
  '__repr__', '__reversed__', '__setitem__', '__sizeof__', 
'__subclasshook__',
  'clear', 'copy', 'fromkeys', 'get', 'items', 'keys', 
'move_to_end', 'pop',
  'popitem', 'setdefault', 'update', 'values'},
'dict': {'__getattribute__', '__len__', '__new__'},
'object': {'__delattr__', '__setattr__', '__str__'}}
```
???

--
messages: 416948
nosy: apostofes
priority: normal
severity: normal
status: open
title: enhanced dir?
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



[issue47103] Copy pgort140.dll when building for PGO

2022-04-07 Thread Steve Dower


Change by Steve Dower :


--
pull_requests: +30432
pull_request: https://github.com/python/cpython/pull/32407

___
Python tracker 

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



[issue47254] enhanced dir?

2022-04-07 Thread apostofes


Change by apostofes :


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

___
Python tracker 

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



[issue47250] New object.__getstate__() method introduced refleaks

2022-04-07 Thread Dong-hee Na


Change by Dong-hee Na :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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



[issue47250] New object.__getstate__() method introduced refleaks

2022-04-07 Thread Dong-hee Na


Dong-hee Na  added the comment:


New changeset e2d78baed385c349d756e96d8f0def0268fa9c4f by Dong-hee Na in branch 
'main':
bpo-47250: Fix refleak from object.__getstate__() (GH-32403)
https://github.com/python/cpython/commit/e2d78baed385c349d756e96d8f0def0268fa9c4f


--

___
Python tracker 

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



[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

2022-04-07 Thread neonene


neonene  added the comment:

>What exactly does "pgo hard reject" mean?

In my recognition, "pgo hard reject" is based on the PGOptimizer's heuristic, 
"reject" is related to the probe count (hot/cold).

  https://developercommunity.visualstudio.com/t/1531987#T-N1535774


And there was a reply from MSVC team, closing the issue. MSVC won't be fixed in 
the near future.

  https://developercommunity.visualstudio.com/t/1595341#T-N1695626

>From the reply and my investigation, 3.11 would need the following:

1. Some callsites such as tp_* pointer should not inline its fastpaths in the 
eval switch-case. They often conflict. Each pointer needs to be wrapped with a 
function or maybe _PyEval_EvalFrameDefault needs to be enclosed with 
"inline_depth(0)" pragma.

2. __assume(0) should be replaced with other function, inside the eval 
switch-case or in the inlined paths of callees. This is critical with PGO.

3. For inlining, use __forceinline / macro / const function pointer.

   MSVC's stuck can be avoided in many ways, when force-inlining in the 
evalloop a ton of Py_DECREF()s, unless tp_dealloc does not create a inlined 
callsite:

 void
 _Py_Dealloc(PyObject *op)
 {
  ...
 #pragma inline_depth(0) // effects from here, PGO accepts only 0.
 (*dealloc)(op); // conflicts when inlined.
 }
 #pragma inline_depth()  // can be reset only outside the func.



* Virtual Call Speculation:
  
https://docs.microsoft.com/en-us/cpp/build/profile-guided-optimizations?view=msvc-170#optimizations-performed-by-pgo


* The profiler runs under /GENPROFILE:PATH option, but at the big ceval-func, 
the optimizer merges the profiles into one like /GENPROFILE:NOPATH mode.
https://docs.microsoft.com/en-us/cpp/build/reference/genprofile-fastgenprofile-generate-profiling-instrumented-build?view=msvc-170#arguments


* __assume(0) (Py_UNREACHABLE):
  
https://devblogs.microsoft.com/cppblog/visual-studio-2017-throughput-improvements-and-advice/#remove-usages-of-__assume

--

___
Python tracker 

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



[issue47254] enhanced dir?

2022-04-07 Thread Jelle Zijlstra


Jelle Zijlstra  added the comment:

This would be nice, but backward compatibility alone means we can't change 
dir() to return a dictionary. What you propose would make more sense as a new 
function, perhaps in a package like pydoc or a third-party tool like IPython.

--
nosy: +JelleZijlstra

___
Python tracker 

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



[issue47103] Copy pgort140.dll when building for PGO

2022-04-07 Thread Steve Dower


Steve Dower  added the comment:


New changeset 80c115385c01f456cdc6550543cf2112ae7a8161 by Steve Dower in branch 
'3.9':
bpo-47103: Copy pgort140.dll into output directory when building PGInstrument 
on Windows (GH-32083)
https://github.com/python/cpython/commit/80c115385c01f456cdc6550543cf2112ae7a8161


--

___
Python tracker 

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



[issue34975] start_tls() difficult when using asyncio.start_server()

2022-04-07 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

https://discuss.python.org/t/need-reconsideration-of-bpo-34975-add-start-tls-method-to-streams-api/14720
 would like to see this reconsidered.  reopening.

--
nosy: +gregory.p.smith
resolution: wont fix -> 
stage: resolved -> 
status: closed -> open
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



[issue47254] enhanced dir?

2022-04-07 Thread apostofes


apostofes  added the comment:

would adding an argument to dir be a possible solution,
like,
```
l = [1, 2, 3]
dir(l, categorize=True)
```

--

___
Python tracker 

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



[issue47254] enhanced dir?

2022-04-07 Thread apostofes


apostofes  added the comment:

plus I would want it to have some more methods,
```
l = [1, 2, 3]
```
using enhanced dir should give,
```
{'list': {'__add__', '__contains__', '__delitem__', '__eq__', '__ge__',
 '__getattribute__', '__getitem__', '__gt__', '__iadd__', '__imul__',
 '__init__', '__init_subclass__', '__iter__', '__le__', '__len__',
 '__lt__', '__mul__', '__ne__', '__new__', '__repr__',
 '__reversed__', '__rmul__', '__setitem__', '__sizeof__',
 '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend',
 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'},
'object': {'__delattr__', '__dir__', '__format__', '__reduce__', 
'__reduce_ex__', '__setattr__', '__str__'}}
```
obtained from, (here only printing, made a dictionary in the implementation in 
the PR)
```
for j in dir(l):
print(f'l.{j}.__qualname__')
```
this check fails for,
```
{'list': {'__doc__', '__hash__', '__class__'}}
```
I would also want these,
```
{'list': {'__instancecheck__','__subclasscheck__', '__subclasses__', 'mro'},
 'type': {'__call__', '__prepare__'}}
```
which were obtained from,
```
for j in set(dir(type(l))) - set(dir(l)):
print(f'l.{j}.__qualname__')
```

and it fails for,
```
{'list': {'__abstractmethods__', '__base__', '__bases__', '__basicsize__', 
'__dict__', '__dictoffset__',
   '__flags__', '__itemsize__', '__module__', '__mro__',
   '__name__', '__qualname__', '__text_signature__', 
'__weakrefoffset__'}
```

--

___
Python tracker 

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



[issue47255] Many broken :meth: roles in the docs

2022-04-07 Thread Jelle Zijlstra


New submission from Jelle Zijlstra :

The docs for the hash() builtin use :meth:`__hash__`, but this doesn't actually 
link to the datamodel documentation for __hash__: it needs 
:meth:`~object.__hash__` instead.

I'm fixing this in the builtin functions docs, but there are probably more 
places.

Why don't we warn when a :meth: link doesn't actually create a link?

--
assignee: docs@python
components: Documentation
messages: 416956
nosy: JelleZijlstra, docs@python
priority: normal
severity: normal
status: open
title: Many broken :meth: roles in the docs
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



[issue47255] Many broken :meth: roles in the docs

2022-04-07 Thread Jelle Zijlstra


Change by Jelle Zijlstra :


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

___
Python tracker 

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



[issue47255] Many broken :meth: roles in the docs

2022-04-07 Thread Jelle Zijlstra


Jelle Zijlstra  added the comment:

There are a lot of places in the rest of the docs that have the same problem:

Doc % git grep ':meth:`__' | grep -v whatsnew | wc -l
 610

I wonder if we can make the :meth: role globally default to linking to 
object.__dunder__. Would that require a change to Sphinx?

--

___
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-07 Thread Brett Cannon


Change by Brett Cannon :


--
pull_requests: +30436
pull_request: https://github.com/python/cpython/pull/32410

___
Python tracker 

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



[issue46981] Empty typing.Tuple

2022-04-07 Thread Jelle Zijlstra


Jelle Zijlstra  added the comment:

I tried out 3.11 on my pyanalyze type checker and got some failures because of 
this change, because my previous trick for distinguishing between Tuple and 
Tuple[()] failed.

3.10:

>>> from typing import get_args, Tuple
>>> get_args(Tuple[()])
((),)
>>> get_args(Tuple)
()


3.11:

>>> from typing import get_args, Tuple
>>> get_args(Tuple[()])
()
>>> get_args(Tuple)
()

However, the new behavior is more consistent: get_args(tuple[()]) always 
returned (). It's also easy enough to work around (just check `... is Tuple`).

I'll put a note in the What's New for 3.11 about this change.

--

___
Python tracker 

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



[issue47248] Possible slowdown of regex searching in 3.11

2022-04-07 Thread Dennis Sweeney


Dennis Sweeney  added the comment:

Possibly related to the new atomic grouping support from GH-31982?

--
nosy: +Dennis Sweeney, serhiy.storchaka

___
Python tracker 

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



[issue47256] re: limit the maximum capturing group to 1, 073, 741, 823, reduce sizeof(match_context).

2022-04-07 Thread Ma Lin

New submission from Ma Lin :

These changes reduce sizeof(match_context):
- 32-bit build: 36 bytes, no change.
- 64-bit build: 72 bytes -> 56 bytes.

sre uses stack and `match_context` struct to simulate recursive call, smaller 
struct brings:
- deeper recursive call
- less memory consume
- less memory realloc

Here is a test, if limit the stack size to 1 GiB, the max available value of n 
is:

re.match(r'(ab)*', n * 'ab')   # need to save MARKs
72 bytes: n = 11,184,808
64 bytes: n = 12,201,609
56 bytes: n = 13,421,770

re.match(r'(?:ab)*', n * 'ab') # no need to save MARKs
72 bytes: n = 13,421,770
64 bytes: n = 14,913,078
56 bytes: n = 16,777,213

1,073,741,823 capturing groups should enough for almost all users.
If limit it to 16,383 (2-byte integer), the context size may reduce more. But 
maybe some patterns generated by program will have more than this number of 
capturing groups.

1️⃣Performance:

Before
regex_dna: Mean +- std dev: 149 ms +- 1 ms
regex_effbot: Mean +- std dev: 2.22 ms +- 0.02 ms
regex_v8: Mean +- std dev: 22.3 ms +- 0.1 ms
my benchmark[1]: 13.9 sec +- 0.0 sec

Commit 1. limit the maximum capture group to 1,073,741,823
regex_dna: Mean +- std dev: 150 ms +- 1 ms
regex_effbot: Mean +- std dev: 2.16 ms +- 0.02 ms
regex_v8: Mean +- std dev: 22.3 ms +- 0.1 ms
my benchmark: 13.8 sec +- 0.0 sec

Commit 2. further reduce sizeof(SRE(match_context))
regex_dna: Mean +- std dev: 150 ms +- 1 ms
regex_effbot: Mean +- std dev: 2.16 ms +- 0.02 ms
regex_v8: Mean +- std dev: 22.2 ms +- 0.1 ms
my benchmark: 13.8 sec +- 0.1 sec

If further change the types of toplevel/jump from int to char, in 32-bit build 
sizeof(match_context) will be reduced from 36 to 32 (In 64-bit build still 56). 
But it's slower on 64-bit build, so I didn't adopt it:
regex_dna: Mean +- std dev: 150 ms +- 1 ms
regex_effbot: Mean +- std dev: 2.18 ms +- 0.01 ms
regex_v8: Mean +- std dev: 22.4 ms +- 0.1 ms
my benchmark: 14.1 sec +- 0.0 sec

2️⃣ The type of match_context.count is Py_ssize_t
- If change it to 4-byte integer, need to modify some engine code.
- If keep it as Py_ssize_t, SRE_MAXREPEAT may >= 4 GiB in future versions.  
  Currently SRE_MAXREPEAT can't >= 4 GiB.
So the type of match_context.count is unchanged.

[1] My re benchmark, it uses 16 patterns to process 100 MiB text data:
https://github.com/animalize/re_benchmarks

--
components: Library (Lib)
messages: 416960
nosy: ezio.melotti, malin, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: re: limit the maximum capturing group to 1,073,741,823, reduce 
sizeof(match_context).
type: resource usage
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