[issue46371] A better way to resolve ForwardRefs in type aliases across modules

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +sobolevn

___
Python tracker 

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

[issue46369] get_type_hints does not evaluate ForwardRefs inside NewType

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +AlexWaygood, sobolevn

___
Python tracker 

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

[issue46223] asyncio cause infinite loop during debug

[aaron]

aaron  added the comment:

'@reprlib.recursive_repr' decorator to 'events.Handle.__repr__()'

could you tell me which file should I change? and why?

--

___
Python tracker 

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

[issue46223] asyncio cause infinite loop during debug

[aaron]

aaron  added the comment:

"When running code in debug mode" means we're debug the code. We have used both 
vscode and pycharm. Same result.

--

___
Python tracker 

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

[issue46372] int/float specializations should mutate the LHS in-place when possible

[Brandt Bucher]

Change by Brandt Bucher :


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

___
Python tracker 

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

[issue46372] int/float specializations should mutate the LHS in-place when possible

[Brandt Bucher]

New submission from Brandt Bucher :

The performance of our existing int and float specializations can be improved 
by mutating the LHS operand in-place when possible. This leads to significant 
speedups for several number-crunching benchmarks, and a solid 1% improvement 
overall:

Slower (16):
- regex_effbot: 3.14 ms +- 0.01 ms -> 3.26 ms +- 0.03 ms: 1.04x slower
- pidigits: 197 ms +- 0 ms -> 203 ms +- 0 ms: 1.03x slower
- pickle_list: 4.40 us +- 0.05 us -> 4.51 us +- 0.05 us: 1.02x slower
- logging_silent: 106 ns +- 2 ns -> 108 ns +- 1 ns: 1.02x slower
- unpickle_pure_python: 248 us +- 2 us -> 253 us +- 4 us: 1.02x slower
- xml_etree_generate: 80.3 ms +- 0.5 ms -> 81.5 ms +- 0.7 ms: 1.02x slower
- telco: 6.50 ms +- 0.10 ms -> 6.60 ms +- 0.11 ms: 1.02x slower
- go: 149 ms +- 1 ms -> 151 ms +- 2 ms: 1.01x slower
- pickle: 9.82 us +- 0.07 us -> 9.94 us +- 0.13 us: 1.01x slower
- xml_etree_process: 58.0 ms +- 0.6 ms -> 58.6 ms +- 0.5 ms: 1.01x slower
- pickle_pure_python: 329 us +- 5 us -> 332 us +- 2 us: 1.01x slower
- regex_dna: 217 ms +- 3 ms -> 219 ms +- 0 ms: 1.01x slower
- json_loads: 25.3 us +- 0.2 us -> 25.6 us +- 0.3 us: 1.01x slower
- scimark_fft: 328 ms +- 9 ms -> 331 ms +- 5 ms: 1.01x slower
- 2to3: 263 ms +- 1 ms -> 264 ms +- 1 ms: 1.01x slower
- deltablue: 4.20 ms +- 0.04 ms -> 4.22 ms +- 0.03 ms: 1.00x slower

Faster (24):
- scimark_sparse_mat_mult: 4.82 ms +- 0.20 ms -> 4.31 ms +- 0.37 ms: 1.12x 
faster
- spectral_norm: 97.0 ms +- 0.8 ms -> 89.3 ms +- 0.6 ms: 1.09x faster
- fannkuch: 418 ms +- 7 ms -> 385 ms +- 4 ms: 1.08x faster
- unpack_sequence: 48.6 ns +- 2.6 ns -> 46.1 ns +- 3.5 ns: 1.05x faster
- scimark_lu: 115 ms +- 4 ms -> 110 ms +- 2 ms: 1.05x faster
- scimark_monte_carlo: 72.2 ms +- 1.1 ms -> 69.9 ms +- 0.8 ms: 1.03x faster
- nbody: 99.4 ms +- 2.1 ms -> 96.9 ms +- 1.7 ms: 1.03x faster
- chaos: 72.5 ms +- 0.7 ms -> 70.9 ms +- 0.5 ms: 1.02x faster
- nqueens: 84.6 ms +- 0.7 ms -> 82.8 ms +- 0.5 ms: 1.02x faster
- pickle_dict: 27.1 us +- 0.1 us -> 26.7 us +- 0.1 us: 1.02x faster
- regex_v8: 24.3 ms +- 0.4 ms -> 24.0 ms +- 0.4 ms: 1.01x faster
- sqlalchemy_imperative: 19.1 ms +- 0.7 ms -> 18.8 ms +- 0.2 ms: 1.01x faster
- float: 77.4 ms +- 0.9 ms -> 76.7 ms +- 0.9 ms: 1.01x faster
- sqlalchemy_declarative: 147 ms +- 3 ms -> 146 ms +- 3 ms: 1.01x faster
- hexiom: 6.68 ms +- 0.06 ms -> 6.63 ms +- 0.03 ms: 1.01x faster
- sympy_sum: 169 ms +- 2 ms -> 168 ms +- 2 ms: 1.01x faster
- json_dumps: 12.8 ms +- 0.2 ms -> 12.7 ms +- 0.2 ms: 1.01x faster
- logging_format: 6.42 us +- 0.08 us -> 6.37 us +- 0.09 us: 1.01x faster
- python_startup_no_site: 5.81 ms +- 0.00 ms -> 5.77 ms +- 0.00 ms: 1.01x faster
- sympy_integrate: 21.5 ms +- 0.1 ms -> 21.4 ms +- 0.1 ms: 1.01x faster
- dulwich_log: 65.4 ms +- 0.5 ms -> 65.1 ms +- 0.5 ms: 1.00x faster
- crypto_pyaes: 83.5 ms +- 0.5 ms -> 83.1 ms +- 0.4 ms: 1.00x faster
- raytrace: 309 ms +- 3 ms -> 307 ms +- 2 ms: 1.00x faster
- python_startup: 8.18 ms +- 0.01 ms -> 8.15 ms +- 0.01 ms: 1.00x faster

Benchmark hidden because not significant (18): chameleon, django_template, 
logging_simple, mako, meteor_contest, pathlib, pyflate, regex_compile, 
richards, scimark_sor, sqlite_synth, sympy_expand, sympy_str, tornado_http, 
unpickle, unpickle_list, xml_etree_parse, xml_etree_iterparse

Geometric mean: 1.01x faster

--
assignee: brandtbucher
components: Interpreter Core
messages: 410544
nosy: Mark.Shannon, brandtbucher, gvanrossum
priority: normal
severity: normal
status: open
title: int/float specializations should mutate the LHS in-place when possible
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

[issue46368] faulthandler: add the ability to dump all interpreters, not only the current interpreter

[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

[issue37295] Possible optimizations for math.comb()

[Tim Peters]

Tim Peters  added the comment:

I was thinking about

comb(100, 50)

The simple "* --n / ++k" loop does 499,999 each of multiplication and division, 
and in all instances the second operand is a single Python digit. Cheap as can 
be.

In contrast, despite that it short-circuits all "small k" cases, comb_pole2.py 
executes

return C(n, j) * C(n-j, k-j) // C(k, j)   # Recursive case

7,299,598 times. Far more top-level arithmetic operations, including 
extra-expensive long division with both operands multi-digit. At the very top 
of the tree, "// C(50, 25)" is dividing out nearly half a million bits.

But a tiny Python function coding the simple loop takes about 150 seconds, 
while Raymond's C() about 30 (under the released 3.10.1). The benefits from 
provoking Karatsuba are major.

Just for the heck of it, I coded a complication of the simple loop that just 
tries to provoke Karatsuba on the numerator (prod(range(n, n-k, -1))), and 
dividing that just once at the end, by factorial(k). That dropped the time to 
about 17.5 seconds. Over 80% of that time is spent computing the "return" 
expression, where len(p) is 40 and only 7 entries pass the x>1 test:

return prod(x for x in p if x > 1) // factorial(k)

That is, with really big results, almost everything is mostly noise compared to 
the time needed to do the relative handful of * and // on the very largest 
intermediate results.

Stefan's code runs much faster still, but requires storage proportional to k. 
The crude hack I used needs a fixed (independent of k and n) and small amount 
of temp storage, basically grouping inputs into buckets roughly based on the 
log _of_ their log, and keeping only one int per bucket.

Here's the code:

def pcomb2(n, k):
from math import prod, factorial

assert 0 <= k <= n
k = min(k, n-k)
PLEN = 40 # good enough for ints with over a trillion bits
p = [1] * PLEN

def fold_into_p(x):
if x == 1:
return
while True:
i = max(x.bit_length().bit_length() - 5, 0)
if p[i] == 1:
p[i] = x
break
x *= p[i]
p[i] = 1

def showp():
for i in range(PLEN):
pi = p[i]
if pi > 1:
print(i, pi.bit_length())

for i in range(k):
fold_into_p(n)
n -= 1
showp()
return prod(x for x in p if x > 1) // factorial(k)

I'm not sure it's practical. For example, while the list p[] can be kept quite 
small, factorial(k) can require a substantial amount of temp storage of its own 
- factorial(50) in the case at hand is an int approaching 9 million bits.

Note: again in the case at hand, computing it via

factorial(100) // factorial(50)**2

takes about 10% longer than Raymond's C() function.

--

___
Python tracker 

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

[issue46280] About vulnerabilities in Cpython native code

[miss-islington]

miss-islington  added the comment:


New changeset ae6e255cb362557ff713ff2967aecb92f7eb069c by Miss Islington (bot) 
in branch '3.9':
bpo-46280: Fix tracemalloc_copy_domain() (GH-30591)
https://github.com/python/cpython/commit/ae6e255cb362557ff713ff2967aecb92f7eb069c


--

___
Python tracker 

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

[issue46280] About vulnerabilities in Cpython native code

[miss-islington]

miss-islington  added the comment:


New changeset 86d18019e96167c5ab6f5157fa90598202849904 by Miss Islington (bot) 
in branch '3.10':
bpo-46280: Fix tracemalloc_copy_domain() (GH-30591)
https://github.com/python/cpython/commit/86d18019e96167c5ab6f5157fa90598202849904


--

___
Python tracker 

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

[issue46280] About vulnerabilities in Cpython native code

[miss-islington]

Change by miss-islington :


--
pull_requests: +28791
pull_request: https://github.com/python/cpython/pull/30593

___
Python tracker 

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

[issue46280] About vulnerabilities in Cpython native code

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +28790
pull_request: https://github.com/python/cpython/pull/30592

___
Python tracker 

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

[issue46280] About vulnerabilities in Cpython native code

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7c770d3350813a82a639fcb3babae0de2b87aaae by Victor Stinner in 
branch 'main':
bpo-46280: Fix tracemalloc_copy_domain() (GH-30591)
https://github.com/python/cpython/commit/7c770d3350813a82a639fcb3babae0de2b87aaae


--

___
Python tracker 

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

[issue46371] A better way to resolve ForwardRefs in type aliases across modules

[Jelle Zijlstra]

Change by Jelle Zijlstra :


--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue46365] _ curses module is not installed

[simon28li]

Change by simon28li :


--
resolution:  -> fixed
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

[issue46280] About vulnerabilities in Cpython native code

[STINNER Victor]

STINNER Victor  added the comment:

#389
Modules/_tracemalloc.c:1245: error: Null Dereference
  pointer `traces2` last assigned on line 1243 could be null and is 
dereferenced by call to `_Py_hashtable_destroy()` at line 1245, column 9.
  1243. _Py_hashtable_t *traces2 = tracemalloc_copy_traces(traces);
  1244. if (_Py_hashtable_set(domains2, TO_PTR(domain), traces2) < 0) {
  1245. _Py_hashtable_destroy(traces2);
^
  1246. return -1;
  1247. }

That's a real bug: I wrote PR #30591 to fix it.


Whereas the following one must be ignored, since the function does crash (read 
at NULL) on purpose:

#360
Modules/faulthandler.c:1025: error: Null Dereference
  pointer `x` last assigned on line 1024 could be null and is dereferenced at 
line 1025, column 9.
  1023. faulthandler_suppress_crash_report();
  1024. x = NULL;
  1025. y = *x;
^
  1026. return PyLong_FromLong(y);
  1027.

--

___
Python tracker 

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

[issue46280] About vulnerabilities in Cpython native code

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner
nosy_count: 6.0 -> 7.0
pull_requests: +28789
pull_request: https://github.com/python/cpython/pull/30591

___
Python tracker 

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

[issue46308] Unportable test(1) operator in configure script

[STINNER Victor]

STINNER Victor  added the comment:

commit b962544594c6a7c695330dd20fedffb3a1916ba6
Author: Miss Islington (bot) <31488909+miss-isling...@users.noreply.github.com>
Date:   Sat Jan 8 17:08:20 2022 -0800

bpo-34602: Fix unportable test(1) operator in configure script (GH-30490) 
(GH-30491)

(cherry picked from commit 3d11c1b8b49800c5c4c295953cc3abf577f6065a)

Co-authored-by: Thomas Klausner 

--
nosy: +vstinner
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

___
Python tracker 

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

[issue45953] Statically allocate interpreter states as much as possible.

[STINNER Victor]

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Eric Snow  added the comment:


New changeset 322f962f3ee31d0dbde99e36379de8488ccc6804 by Eric Snow in branch 
'main':
bpo-45953: Statically initialize all the non-object PyInterpreterState fields 
we can. (gh-30589)
https://github.com/python/cpython/commit/322f962f3ee31d0dbde99e36379de8488ccc6804


--

___
Python tracker 

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Eric Snow  added the comment:


New changeset 324908ba936d5d262026deebb81f050803848c41 by Eric Snow in branch 
'main':
bpo-45953: Statically initialize all the PyThreadState fields we can. (gh-30590)
https://github.com/python/cpython/commit/324908ba936d5d262026deebb81f050803848c41


--

___
Python tracker 

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

[issue46371] A better way to resolve ForwardRefs in type aliases across modules

[Andreas H.]

New submission from Andreas H. :

(De)Serialization of in-memory data structures is an important application. 
However there is a rather unpleasant issue with ForwardRefs.


One cannot export type aliases when they contain ForwardRefs (and expect 
things to work).


Consider the example:

Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]


When used in another module the containing ForwardRefs cannot be resolved, or 
in the worst case, resolve to 
wrong types if in the caller namespace contains a symbol with the same name as 
ForwardRef refers to.

This of course only applies to inspection-based tools which utilize the 
run-time information, not the static type checkers.


Type aliases sometimes have to be used sometimes - they cannot be avoided in 
all cases, 
especially with recursive types as in the example above.  



There are several options to improve the situation. These are all that came to 
my mind and I want to expose them to discussion.



1. Guard with NewType

Json = NewType('Json', Union[ List['Json'], Dict[str, 'Json'], int, float, 
bool, None ] )
   
   Advantage: This could allow automatic cross-module ForwardRef resolution 
provided issue 46369 [1] is acknowledged as a bug and fixed. 
   Disadvantage: Does not create a true type alias, but a sub-type. Type casts 
have to be used all the time, e.g.   `data = Json(bool)`.
  So can only applied to a subset of use-cases (but is IMO a clean solution 
when it fits). 


2. Use the `module` parameter of ForwardRef

Json = Union[ List[ForwardRef('Json', module=__name__)], Dict[str, 
ForwardRef('Json', module=__name__)], int, float, bool, None ] )

   Advantage: Works in 3.10. 
   Disadvantage: Would require issue 46333 [2] to be fixed. ForwardRef is not 
meant to be instatiated by the user, 
   also `module` parameter is currently completely internal.


3. Modify ForwardRef so that it accepts a fully qualified name

Json = Union[ List[__name__+'.Json'], Dict[str, __name__+'.Json'], int, 
float, bool, None ] )

   Advantage: This is only a tiny change (because ForwardRef has the `module` 
parameter). ForwardRef would stay internal. Less ugly than 2.
   Disadvantage: Still a bit ugly. Would also require issue 46333 [2] to be 
fixed. Relative module specification (as in relative imports) 
  would not work.


4. Manual evaluation

Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]
resolve_type_alias(Json, globals(), locals() )


def resolve_type_alias(type, globalns, localns):
class dummy:
test: type
typing.get_type_hints(dummy, globalns, localns) # Note: this modifies 
ForwardRefs in-place

Advantage: Works in many versions.
Disadvantage: Requires user to explicily call function after the last 
referenced type is defined 
   (this may be physically separated from the type alias definition, which 
does not feel like a good solution especially since 
this ForwardRef export problem is only technical, and not even close to 
beeing obvious to most people)


5. Make `get_type_hints()` to work with type-aliases (essentially integrate 
above `resolve_type_alias`). The return value 
   of get_type_hints() would be the same as argument, just with ForwardRefs 
in-place resolved. 
 
 Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]
 get_type_hints(Json, globals(), locals())
 
   Advantage: same as 4) but hides useful (but ugly) code
   Disadvantage: same as 4)


 
6. Make all types in typing (such as List, Dict, Union, etc...) to capture 
their calling module and pass this information to ForwardRef, when 
   one is to be created. Then already during construction of ForwardRef the 
`module` will be correctly set.

 Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]

   Advantage: This requires no user intervention. Things will "just work"
   Disadvantage: This is rather big change. It is incompatible with the caching 
used inside typing.py (the new __module__ parameter would 
   need to be taken into account in __hash__ and/or __eq__). And maybe has 
other issues I do not see at the moment.


7. Extend `TypeAlias` hint so it can be used in bracket  way similar to e.g. 
`Annotated`

 Json = TypeAlias[ Union[ List['Json'], Dict[str, 'Json'], int, float, 
bool, None ]  ]
   

   I know, presently it is supposed to be used as  `Json: TypeAlias = Union[ 
 ]`. But that is of no help at run-time, because
   the variable Json contains no run-time information. So even if TypeAlias 
would capture the calling module, 
   this information is not passed on to the variable `Json`. This is different 
for the bracket notation TypeAlias[ .. ]. 

   Advantage: Similar usage to Annotated. Would not require a big change such 
as in 4).
   Disadvantage: TypeAlias is not supposed to be used that way.


8. Introduce function to define a type alias, which sets the module 

[issue46362] os.path.abspath() needs more normalization on Windows

[Steve Dower]

Steve Dower  added the comment:

Thanks for the patch!

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +28788
pull_request: https://github.com/python/cpython/pull/30590

___
Python tracker 

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +28787
pull_request: https://github.com/python/cpython/pull/30589

___
Python tracker 

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

[issue46362] os.path.abspath() needs more normalization on Windows

[Steve Dower]

Steve Dower  added the comment:


New changeset d4e64cd4b0ea431d4e371f9b0a25f6b75a069dc1 by neonene in branch 
'main':
bpo-46362: Ensure ntpath.abspath() uses the Windows API correctly (GH-30571)
https://github.com/python/cpython/commit/d4e64cd4b0ea431d4e371f9b0a25f6b75a069dc1


--

___
Python tracker 

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

[issue46362] os.path.abspath() needs more normalization on Windows

[Steve Dower]

Steve Dower  added the comment:

One thing to be aware of is that Windows 11 has changed the rules around these 
files, so here's my results with 3.10:

>>> for path in paths:
... print(os.path.abspath(path))
...
C:\CON
C:\PRN
C:\AUX
\\.\NUL
C:\COM1
C:\COM2
C:\COM3
C:\COM9
C:\LPT1
C:\LPT2
C:\LPT3
C:\LPT9
C:\foo

But this shouldn't be an issue with the proposed (about to be merged) change.

--

___
Python tracker 

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

[issue45953] Statically allocate interpreter states as much as possible.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +28786
pull_request: https://github.com/python/cpython/pull/30588

___
Python tracker 

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

[issue45797] AMD64 Arch Linux Asan Debug buildbot sometimes hangs before tests complete

[STINNER Victor]

STINNER Victor  added the comment:

I didn't notice this issue recently, but I didn't pay attention this buildbot 
worker neither. I close the issue.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue46370] Move runtime static init to its own header file.

[Eric Snow]

Change by Eric Snow :


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

[issue46370] Move runtime static init to its own header file.

[Eric Snow]

Eric Snow  added the comment:


New changeset bc02eac9d2cb36faffc5027b7ce09e6dd0922a7f by Eric Snow in branch 
'main':
bpo-46370: Move the static initializer for _PyRuntime to its own header file. 
(gh-30587)
https://github.com/python/cpython/commit/bc02eac9d2cb36faffc5027b7ce09e6dd0922a7f


--

___
Python tracker 

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

[issue46370] Move runtime static init to its own header file.

[Eric Snow]

Change by Eric Snow :


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

___
Python tracker 

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

[issue46370] Move runtime static init to its own header file.

[Eric Snow]

New submission from Eric Snow :

The static initializer for `_PyRuntime` is currently defined in 
Include/internal/pycore_runtime.h.  However, it is only needed by 
Python/pylifecycle.c (and Python/pystate.c for an optimization) and should only 
be used there.  (Also, the initializer is quite large.)  So I'm planning on 
moving it to it's own internal header file.

--
assignee: eric.snow
components: Interpreter Core
messages: 410529
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Move runtime static init to its own header file.
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

[issue46369] get_type_hints does not evaluate ForwardRefs inside NewType

[Andreas H.]

New submission from Andreas H. :

Consider the following: 

NewT = typing.NewType("NewT", typing.List[typing.Optional['Z']] )

class Z:
pass


Now get_type_hints() does not resolve the ForwardRef within NewType (but it 
does so for TypedDict, dataclasses, NamedTuple).


Neither of the following works.

1)  
class dummy:
test: NewT

get_type_hints(test,None,None)

print( NewT.__supertype__.__args__[0].__args__[0]__.__forward_evaluated__ )
# --> False

Note: investigating the return value of get_type_hints does not change the 
outcome. 
get_type_hints() patches ForwardRefs in-place.


2) 
get_type_hints(NewT,None,None)
# --> TypeError   is not a module, class, method, or function



For Python 3.10+ a workaround exists, but requires access to implementation 
details of NewType:
  
   class dummy:
   test: NewT.__supertype__
   get_type_hints( dummy, globalns=sys.modules[NewT.__module__].__dict__, 
localns=None )


Possible solution could be 
 A) to extent `get_type_hints` to explicitly handle NewType (basically call 
_eval_type for the __supertype__ member).
That makes approach 2) work (but not 1)
 or B) to extend _eval_type() to handle process NewType as well. This would 
make 1) work (but not 2).

I guess, since NewType is supposed to be semantically a subclass of the 
referred type, 2) is probably the preferred approach, which would suggest A). 


Strictly speaking this issue exits in all Python versions that have NewType, 
but it is easier to fix in 3.10 because there NewType has the __module__ member.

--
components: Library (Lib)
messages: 410528
nosy: andreash, gvanrossum, kj
priority: normal
severity: normal
status: open
title: get_type_hints does not evaluate ForwardRefs inside NewType
type: behavior
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

[issue46357] socket module fix warning build on FreeBSD

[David CARLIER]

Change by David CARLIER :


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

[issue46357] socket module fix warning build on FreeBSD

[David CARLIER]

David CARLIER  added the comment:

I get what you mean now I thought memset was enough.

--

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[miss-islington]

miss-islington  added the comment:


New changeset 537f16adfa31b5b1fe9d656d571d1e10fb115351 by Miss Islington (bot) 
in branch '3.9':
bpo-40479: Fix typo, flag must be set for OpenSSL < 3.0.0 (GH-30584)
https://github.com/python/cpython/commit/537f16adfa31b5b1fe9d656d571d1e10fb115351


--

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[miss-islington]

miss-islington  added the comment:


New changeset 47422a852de14a8ec11d058136c7c864d2cc7fc9 by Miss Islington (bot) 
in branch '3.10':
[3.10] bpo-40479: Fix typo, flag must be set for OpenSSL < 3.0.0 (GH-30584) 
(GH-30585)
https://github.com/python/cpython/commit/47422a852de14a8ec11d058136c7c864d2cc7fc9


--

___
Python tracker 

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

[issue46360] Inconsistent import behavior for (unusual) submodules

[Eric Snow]

Eric Snow  added the comment:

> I'm going to assume the "even though sys.modules has `None`" case,
> which I think is an oversight and should probably get fixed

Yep, I agree.  That's the case I was looking at in the first place.  I noticed 
the other two as I was hacking together code to verify the None behavior. :)  
Bothering to change those would be more trouble than its worth.

--

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 276c234ce0fa6732237f1b187989837324d9dea3 by Christian Heimes in 
branch 'main':
bpo-40479: Fix typo, flag must be set for OpenSSL < 3.0.0 (GH-30584)
https://github.com/python/cpython/commit/276c234ce0fa6732237f1b187989837324d9dea3


--

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[miss-islington]

Change by miss-islington :


--
pull_requests: +28784
pull_request: https://github.com/python/cpython/pull/30586

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[miss-islington]

Change by miss-islington :


--
pull_requests: +28783
pull_request: https://github.com/python/cpython/pull/30585

___
Python tracker 

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

[issue46357] socket module fix warning build on FreeBSD

[STINNER Victor]

STINNER Victor  added the comment:

> I took as initialized to avoid undefined behavior rather than anything.

I don't get what you mean.

Can you please show me which functions initialize sockaddr_l2cap structures and 
explain how the current code fills all members?

I don't know the code well enough to approve your PR 30560.

--

___
Python tracker 

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

[issue46368] faulthandler: add the ability to dump all interpreters, not only the current interpreter

[STINNER Victor]

STINNER Victor  added the comment:

Attached patch is an incomplete quick & dirty implementation to log all 
interpreters in _Py_DumpTracebackThreads().

A better implementation should leave the current behavior unmodified, add a new 
C function, and add all_interpreters=False parameter to the following 
faulthandler functions:

* dump_traceback()
* enable()
* register()

--
keywords: +patch
Added file: https://bugs.python.org/file50561/faulthandler.patch

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-46368: "faulthandler: add the ability to dump all interpreters, 
not only the current interpreter".

--

___
Python tracker 

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

[issue46368] faulthandler: add the ability to dump all interpreters, not only the current interpreter

[STINNER Victor]

New submission from STINNER Victor :

While debugging the sub-interpreter crash bpo-46070, I noticed that 
faulthandler only logs the Python thread state of a single interpreter. When a 
bug involves multiple interpreters, it is useful to log all interpreters.

--
components: Library (Lib)
messages: 410519
nosy: vstinner
priority: normal
severity: normal
status: open
title: faulthandler: add the ability to dump all interpreters, not only the 
current interpreter
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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

pyobject_ob_interp.patch: Quick & dirty patch that I wrote to add 
PyObject.ob_interp, store in which interpreter an object has been created.

--
Added file: https://bugs.python.org/file50560/pyobject_ob_interp.patch

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

Victor:
> (*) I made the GC state per-interpreter: commit 
> 7247407c35330f3f6292f1d40606b7ba6afd5700 (Nov 20, 2019)

Eric Snow:
> FYI, this was done by me in an earlier comment which we ended up
reverting.  Later you basically un.reverted that.

Well, I recall that your change had to be reverted 2 or 3 times because there 
were many crashes on FreeBSD, and no one understood why it crashed. The root 
cause was bugs related to the GIL and daemon threads. It took me a while (and 
multiple commits) to identify and fix all of them:
https://vstinner.github.io/gil-bugfixes-daemon-threads-python39.html

I decided to split your work into smaller changes to better debug these 
crashes. bpo-36854 contains a few changes, but these changes are based on work 
that I pushed earlier.

For example, there was a tricky bug related to clearing a Python thread state:
https://github.com/python/cpython/commit/9da7430675ceaeae5abeb9c9f7cd552b71b3a93a

Also, once the GC was made per interpreter, we started to discover more and 
more tricky reference leaks:
https://vstinner.github.io/subinterpreter-leaks.html

I spent a significant time to reorder code of Py_Finalize() and 
Py_EndInterpreter() to clear objects earlier or in a different order. Recently, 
I made sure that the free lists can no longer be used after they are cleared. 
It took some notes at:
https://pythondev.readthedocs.io/finalization.html

One of the hardest fix was the commit 9ad58acbe8b90b4d0f2d2e139e38bb5aa32b7fb6 
of bpo-19466. To make this change, first I had to fix a very old bug of 
PyThreadState_Clear() with commit 5804f878e779712e803be927ca8a6df389d82cdf 
(bpo-20526).

Well, it was a long journey and it's not done yet :-)

--

___
Python tracker 

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

[issue46360] Inconsistent import behavior for (unusual) submodules

[Brett Cannon]

Brett Cannon  added the comment:

So which inconsistency do you want to change because you listed three and this 
is only one issue. 

I'm going to assume the "even though sys.modules has `None`" case, which I 
think is an oversight and should probably get fixed, but I also don't know what 
promises the language spec makes around this.

As for the other two, you can open separate issues if you want to discuss them, 
but I double-check what the language spec says as I am tempted to say both are 
fine (and specifically in the latter case that's on you to have not messed up 
and left the attribute off).

--

___
Python tracker 

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

[issue41226] Supporting `strides` in `memoryview.cast`

[jakirkham]

jakirkham  added the comment:

The 2nd argument is the `strides`. IOW it is just specifying how to traverse 
the buffer in memory to visit each of the dimensions.

For the first example where `strides` is not specified, Python makes them 
C-ordered. IOW `m2.strides` would be `(3, 1)`. Effectively this is represented 
like this:

```
[[ b"a", b"c", b"e"],
 [ b"b", b"d', b"f"]]
```

For the second case where strides are overridden (so `m2.strides` would be `(1, 
2)`), we get something like this:

```
[[b"a", b"b", b"c"],
 [b"d", b"e", b"f"]]
```

In either case the `1` here has specified which dimension is fastest to 
traverse along. IOW that content is adjacent in memory.

Should add the reason it is `1` is that for `uint8_t` (or format "B"), this is 
that type's size. If we had a different format, this would be the size of that 
format.

HTH

--

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +28782
pull_request: https://github.com/python/cpython/pull/30584

___
Python tracker 

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

[issue46361] Small ints aren't always cached properly

[Brandt Bucher]

Brandt Bucher  added the comment:

The attached PR doesn't seem to have any impact on Decimal performance 
(non-optimized, non-debug build on a fairly quiet laptop):

main:

Convert 262,000 Decimals to "small" ints: 31.7 ms +- 5.3 ms
Convert 256,000 Decimals to 1-digit ints: 29.9 ms +- 3.1 ms
Convert 256,000 Decimals to 2-digit ints: 30.4 ms +- 2.8 ms
Convert 256,000 Decimals to 3-digit ints: 31.2 ms +- 3.1 ms

patched:

Convert 262,000 Decimals to "small" ints: 30.9 ms +- 4.0 ms
Convert 256,000 Decimals to 1-digit ints: 29.5 ms +- 3.0 ms
Convert 256,000 Decimals to 1-digit ints: 30.5 ms +- 2.5 ms
Convert 256,000 Decimals to 1-digit ints: 31.0 ms +- 2.3 ms

--

___
Python tracker 

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

[issue46361] Small ints aren't always cached properly

[Brandt Bucher]

Change by Brandt Bucher :


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

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

It would be nice to add some tests.

--

___
Python tracker 

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

[issue40066] Enum: modify __repr__, __str__; update docs

[Ethan Furman]

Change by Ethan Furman :


--
pull_requests: +28780
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30582

___
Python tracker 

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

[issue46367] multiprocessing's "spawn" doesn't actually use spawn

[jakirkham]

New submission from jakirkham :

Reporting an issue recently encountered by a colleague.

It appears the `multiprocessing`'s "spawn" mode doesn't actually use POSIX 
spawn, but instead uses fork+exec[1]. While this is certainly a useful feature 
in its own right, this not quite one would expect from something described as 
spawn. AFAICT the documentation doesn't point this out.

This is important as some libraries are not fork-safe and even fork+exec is not 
sufficient to protect them. Would be helpful if "spawn" did use POSIX spawn and 
the current behavior was covered under a clearer name (like "forkexec").


Ref:
1. 
https://github.com/python/cpython/blob/af6b4068859a5d0c8afd696f3c0c0155660211a4/Lib/multiprocessing/util.py#L448-L458

--
components: Library (Lib)
messages: 410512
nosy: jakirkham
priority: normal
severity: normal
status: open
title: multiprocessing's "spawn" doesn't actually use spawn
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

[issue45569] Drop support for 15-bit PyLong digits?

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, Stefan. I think I'm going to go ahead with the first step of making 
30-bit digits the default, then, but leaving the 15-bit digit option present.

> That said, if we decide to keep 15-bit digits in the end, I wonder if 
> "SIZEOF_VOID_P" is the right decision point. It seems more of a "has 
> reasonably fast 64-bit multiply or not" kind of decision

Agreed. And most platforms we care about _do_ seem to have such an instruction, 
so "30-bit digits unless the builder explicitly indicates otherwise - e.g., via 
configure options or pyconfig.h edits" seems reasonable.

My other worry is division. It's less important than multiplication in the 
sense that I'd expect division operations to be rarer than multiplications in 
typical code, but the potential impact for code that _does_ make heavy use of 
division is greater. With 30-bit digits, all the longobject.c source actually 
*needs* is a 64-bit-by-32-bit unsigned division for cases where the result is 
guaranteed to fit in a uint32_t. If we're on x86, there's an instruction for 
that (DIVL), so you'd think that we'd be fine. But without using inline 
assembly, it seems impossible to persuade current versions of either of GCC or 
Clang[*] to generate that DIVL instruction - instead, they both want to do a 
64-bit-by-64-bit division, and on x86 that involves making a call to a 
dedicated __udivti3 intrinsic, which is potentially multiple times slower than 
a simple DIVL.

The division problem affects x64 as well: GCC and Clang currently generate a 
DIVQ instruction when all we need is a DIVL.

> If we find a platform that would be fine with 30-bits but lacks a fast 64-bit 
> multiply, then we could still try to add a platform specific value size check 
> for smaller numbers. Since those are common case, branch prediction might 
> help us more often than not.

Yes, I think that could work, both for multiplication and division.

[*] Visual Studio 2019 _does_ apparently provide a _udiv64 intrinsic, which we 
should possibly be attempting to use: 
https://docs.microsoft.com/en-us/cpp/intrinsics/udiv64?view=msvc-170

--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 52937c26adc35350ca0402070160cf6dc838f359 by Victor Stinner in 
branch '3.9':
bpo-46070: _PyGC_Fini() untracks objects (GH-30577) (GH-30580)
https://github.com/python/cpython/commit/52937c26adc35350ca0402070160cf6dc838f359


--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[miss-islington]

miss-islington  added the comment:


New changeset e6bb17fe29713368e1fd93d9ac9611017c4f570c by Miss Islington (bot) 
in branch '3.10':
bpo-46070: _PyGC_Fini() untracks objects (GH-30577)
https://github.com/python/cpython/commit/e6bb17fe29713368e1fd93d9ac9611017c4f570c


--

___
Python tracker 

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

[issue1927] Change input() to always prompt to stderr

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Further discussion at 
https://discuss.python.org/t/builtin-function-input-writes-its-prompt-to-sys-stderr-and-not-to-sys-stdout/12955

--
nosy: +terry.reedy
versions: +Python 3.11 -Python 3.6

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

I tested manually my fix GH-30580 using:

* (1) attached  win_py399_crash_reproducer.py
* (2) https://bugs.python.org/issue46070#msg410447 mthod

Without my fix, I can easily reproduce the crash with (1) and (2).

With my fix, I can no longer reproduce the crash with (1) or (2).

--

___
Python tracker 

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

[issue45786] Avoid allocating when exiting frame; it may be unsafe.

[Mark Shannon]

Mark Shannon  added the comment:

With https://bugs.python.org/issue45963 both frame objects and generators 
contain space for the frame, so no allocation occurs on exit.

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +28779
pull_request: https://github.com/python/cpython/pull/30580

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[miss-islington]

Change by miss-islington :


--
pull_requests: +28778
pull_request: https://github.com/python/cpython/pull/30579

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[miss-islington]

Change by miss-islington :


--
pull_requests: +28777
pull_request: https://github.com/python/cpython/pull/30578

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 1a4d1c1c9b08e75e88aeac90901920938f649832 by Victor Stinner in 
branch 'main':
bpo-46070: _PyGC_Fini() untracks objects (GH-30577)
https://github.com/python/cpython/commit/1a4d1c1c9b08e75e88aeac90901920938f649832


--

___
Python tracker 

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

[issue44133] Some C-API symbols (e.g. Py_FrozenMain) are not always exported on Unix

[STINNER Victor]

Change by STINNER Victor :


--
title: Some C-API symbols (e.g. Py_FrozenMain) are not always exported -> Some 
C-API symbols (e.g. Py_FrozenMain) are not always exported on Unix

___
Python tracker 

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

[issue44133] Some C-API symbols (e.g. Py_FrozenMain) are not always exported

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset 6be848922bc0f4c632c255c39de82a45b6480286 by Victor Stinner in 
> branch 'main':
> bpo-44133: Link Python executable with object files (GH-30556)

Sadly, Py_FrozenMain() is still missing on Windows. See:
https://github.com/python/cpython/pull/30556#issuecomment-1012032712

Until Windows also exports the symbol, I don't think that we can add the symbol 
to the stable ABI.

I prefer to not backport the change since it's always risky to break the build 
system on a stable branch.

If someone wants to fix the Windows build to also export Py_FrozenMain(), 
please open a new issue.

I consider that the initial issue is fixed, so I close the issue.

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

[issue44133] Some C-API symbols (e.g. Py_FrozenMain) are not always exported

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6be848922bc0f4c632c255c39de82a45b6480286 by Victor Stinner in 
branch 'main':
bpo-44133: Link Python executable with object files (GH-30556)
https://github.com/python/cpython/commit/6be848922bc0f4c632c255c39de82a45b6480286


--

___
Python tracker 

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

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

I merged my PR so the doc can be reviewed online at 
https://docs.python.org/dev/whatsnew/3.11.html once it will be rendered ;-)

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

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0885999a8e5ffad3fae0302675ad0030e33a15af by Victor Stinner in 
branch 'main':
 bpo-46355: Document PyFrameObject and PyThreadState changes (GH-30558)
https://github.com/python/cpython/commit/0885999a8e5ffad3fae0302675ad0030e33a15af


--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[Eric Snow]

Eric Snow  added the comment:

> (*) I made the GC state per-interpreter: commit 
> 7247407c35330f3f6292f1d40606b7ba6afd5700 (Nov 20, 2019)

FYI, this was done by me in an earlier comment which we ended up
reverting.  Later you basically un.reverted that.

> The bug is that a C function object (_sre.compile) is created in an 
> interpreter, tracked by the GC list of this interpreter, and then it is 
> destroye and untracked in another interpreter.

FWIW, at one point I had a branch that supported sharing read-only
Py_Buffer data.  When the receiving interpreter was done with it I'd
call Py_AddPendingCall() to schedule the cleanup in the "owner"
interpreter.  However, this only worked because I kept track of the
owner.  Adding that pointer to every object wouldn't be feasible but I
suppose there are other things we could do that wouldn't be super
inefficient, like don't worry about it for the main interpreter, use a
hash table (Victor's idea), borrow some of the bits of the PyObject
head to store a flag or even an index into an array (if there are only
a few interpreters), or even make the allocator per-interpreter and
then extrapolate the interpreter based on the object's address.

Regardless, it is still much simpler to make all objects per-interpreter.

--

___
Python tracker 

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

[issue40533] [subinterpreters] Don't share Python objects between interpreters

[STINNER Victor]

STINNER Victor  added the comment:

Sharing objects between multiple interpreters can cause complex bugs leading to 
crashes: https://bugs.python.org/issue46070#msg410493 For this specific bug, I 
wrote a workaround (GH-30577).

--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

This issue has a complex history.

(*) I made the GC state per-interpreter: commit 
7247407c35330f3f6292f1d40606b7ba6afd5700 (Nov 20, 2019)

(*) This change triggered a _PyImport_FixupExtensionObject() bug in 
sub-interpreter, I fixed it with commit 
82c83bd907409c287a5bd0d0f4598f2c0538f34d (Nov 22, 2019)

(*) My _PyImport_FixupExtensionObject() fix introduced bpo-44050 regression, it 
was fixed by commit b9bb74871b27d9226df2dd3fce9d42bda8b43c2b (Oct 5, 2021)

(*) A race condition in the _asyncio extension has been identified and fixed by 
the commit b127e70a8a682fe869c22ce04c379bd85a00db67 (Jan 7, 2021)

(*) I identified a race condition introduced by the per-interpreter GC state 
cahnge: I proposed GH-30577 to fix it.


So far, the GC race condition has only been reproduced on Windows with Python 
3.9 and the _sre exception. On Python 3.10 and newer, it's harder to reproduce 
the crash using stdlib extensions since many of them have been ported to the 
multi-phase initializatioin API.

The GC race condition involves dangling pointers and depends on the memory 
allocator and when GC collections are triggered.

The bug is that a C function object (_sre.compile) is created in an 
interpreter, tracked by the GC list of this interpreter, and then it is 
destroye and untracked in another interpreter. The problem is that the object 
is untracked after the GC list has been destroyed and so "prev" and "next" 
objects of the PyGC_Head structure *can* become dangling pointers.

It's unclear to me what are the "prev" and "next" objects of the C function 
causing the crash (_sre.compile). At least, it seems like it's also used by 
more than one interpreter: it should *not* be done, see bpo-40533.

--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

Oh. I managed to write a simple fix which doesn't require to revert the whole 
"per-interpreter GC" change: GH-30577.

--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +28776
pull_request: https://github.com/python/cpython/pull/30577

___
Python tracker 

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

[issue32912] Raise non-silent warning for invalid escape sequences

[Daniel Carpenter]

Daniel Carpenter  added the comment:

I'm not sure if this is an issue or by design, but this DeprecationWarning 
behaves differently to other DeprecationWarnings.

A normal DeprecationWarning triggered by code in __main__ is printed by default:

$ python -c 'import warnings; warnings.warn("test", DeprecationWarning)'
:1: DeprecationWarning: test

But this one is silent:

$ python -c '"\,"'
[no output]

To see this DeprecationWarning at all, I need to type:

$ python -Wdefault -c '"\,"'
:1: DeprecationWarning: invalid escape sequence '\,'

But that enables this DeprecationWarning for all modules, not just __main__ .

I've tested this with Python 3.9 on debian bullseye and the 3.10 docker image.

--
nosy: +dansebcar

___
Python tracker 

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

[issue46318] asyncio and ssl: ResourceWarning: unclosed transport

[Julien Palard]

Julien Palard  added the comment:

Probably related to https://bugs.python.org/issue44011 and 
https://github.com/MagicStack/uvloop/pull/385

--

___
Python tracker 

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

[issue45729] [doc] "history and license" link has wrong target

[Julien Palard]

Julien Palard  added the comment:

> dev docs direct to `/license.html` which redirects to `/3/license.html`

All docs are redirecting to `/license.html`, this allow it to work also out of 
docs.python.org.

> 3.9 docs have the same; wouldn’t it be better to have `/3.9/license.html`?

It's maybe a slight better yes (the page should be the same so I don't know if 
it make real difference), but doing so means a bit of complexity, which I don't 
think is worth it.

I tried to keep it simple for this fix (the previous state was "links to the 
current page" which was worse).

--

___
Python tracker 

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

[issue46070] [subinterpreters] crash when importing _sre in subinterpreters in parallel (Python 3.9 regression)

[STINNER Victor]

STINNER Victor  added the comment:

When the crash occurs, the _sre.compile function is not destroyed in the 
interpreter which created the function.



The crash is related to _sre.compile method. This method is created in 
PyInit__sre() called by "import _sre".

On Windows, the _sre module is not imported at startup. So it's imported first 
in a subinterpreter.

In Python 3.9, the _sre module doesn't use the multiphase initialization API 
and PyModuleDef.m_size = -1. When the module is imported, 
_PyImport_FixupExtensionObject() copies the module dictionary into 
PyModuleDef.m_copy.

In Py_Finalize() and Py_EndInterpreter(), _PyImport_Cleanup() does two things:

* (1) set _sre.__dict__['compile'] to None -> kill the first reference to the 
function
* (2) call _PyInterpreterState_ClearModules() which does 
Py_CLEAR(def->m_base.m_copy), clear the cached copy of the _sre module dict -> 
kill the second reference

I modified Python to add an "ob_interp" member to PyObject to log in which 
interpreter an object is created. I also modified meth_dealloc() to log when 
_sre.compile function is deleted.

Extract of the reformatted output to see what's going on:
---
(...)

(1)
fixup: COPY _sre ModuleDef copy: def=7FFF19209810 interp=01EC1846F2A0

(2)
import: UPDATE(_sre ModuleDef copy): interp=01EC184AB790

(3)
_PyImport_Cleanup: interp=01EC1846F2A0
_PyInterpreterState_ClearModules: PY_CLEAR _sre ModuleDef m_copy: 
def=7FFF19209810 interp=01EC1846F2A0

(4)
_PyImport_Cleanup: interp=01EC184AB790
meth_dealloc(compile): m->ob_interp=01EC1846F2A0, 
interp=01EC184AB790

Windows fatal exception: access violation
(...)
---

Steps:

* (1)

  * interpreter #1 (01EC1846F2A0) creates the _sre.compile function
  * interpreter #1 (01EC1846F2A0) copies _sre module dict into 
PyModuleDef.m_copy
  * at this point, _sre.compile should have 2 references

* (2)

  * interpreter #2 (01EC184AB790) imports _sre: it creates a new module 
object and copies the function from PyModuleDef.m_copy
  * at this point, _sre.compile should have 3 references

* (3)

  * interpreter #1 exit: Py_EndInterpreter() calls _PyImport_Cleanup()
  * at this point, _sre.compile should have 1 reference

* (4)

  * interpreter #2 exit: Py_EndInterpreter() calls _PyImport_Cleanup()
  * the last reference to _sre.compile is deleted: 0 reference
  * meth_dealloc() is called

The first problem is that the function was created in the interpreter #1 but 
deleted in the interpreter #2.

The second problem is that the function is tracked by the GC and it is part of 
the GC list of the interpreter #1. When the interpreter #2 destroys the 
function, the GC list of interpreter #1 is already freed: PyGC_Head contains 
dangling pointers.

--

___
Python tracker 

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

[issue46326] 'venv --clear' should prompt user before nuking entire directory

[Ned Deily]

Change by Ned Deily :


--
nosy:  -ned.deily

___
Python tracker 

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

[issue46358] Modernize `test_asyncio/test_base_events.py`

[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

[issue46358] Modernize `test_asyncio/test_base_events.py`

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset f779faccd3a7a7e8c372492e858d021c449cdd85 by Nikita Sobolev in 
branch 'main':
bpo-46358: modernize `test_asyncio` (GH-30562)
https://github.com/python/cpython/commit/f779faccd3a7a7e8c372492e858d021c449cdd85


--
nosy: +corona10

___
Python tracker 

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

[issue46359] Continue to modernize `test_typing.py`

[Nikita Sobolev]

Change by Nikita Sobolev :


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

[issue46362] os.path.abspath() needs more normalization on Windows

[neonene]

neonene  added the comment:

Basically, PR30571 aims for compatibility with 3.10 and earlier. Using Windows 
API is the easiest and the same way as them:

import os.path
paths = [
r'C:\CON',
r'C:\PRN',
r'C:\AUX',
r'C:\NUL',
r'C:\COM1',
r'C:\COM2',
r'C:\COM3',
r'C:\COM9',
r'C:\LPT1',
r'C:\LPT2',
r'C:\LPT3',
r'C:\LPT9',
r'C:\foo. . .',
]
for path in paths:
print(os.path.abspath(path))

"""
3.11 before
C:\CON
C:\PRN
C:\AUX
C:\NUL
C:\COM1
C:\COM2
C:\COM3
C:\COM9
C:\LPT1
C:\LPT2
C:\LPT3
C:\LPT9
C:\foo. . .

3.11 after
\\.\CON
\\.\PRN
\\.\AUX
\\.\NUL
\\.\COM1
\\.\COM2
\\.\COM3
\\.\COM9
\\.\LPT1
\\.\LPT2
\\.\LPT3
\\.\LPT9
C:\foo

3.10.1
\\.\CON
\\.\PRN
\\.\AUX
\\.\NUL
\\.\COM1
\\.\COM2
\\.\COM3
\\.\COM9
\\.\LPT1
\\.\LPT2
\\.\LPT3
\\.\LPT9
C:\foo
"""

--

___
Python tracker 

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

[issue46359] Continue to modernize `test_typing.py`

[Ken Jin]

Ken Jin  added the comment:


New changeset 8c49d057bf8618208d4ed67c9caecbfa71f7a2d0 by Nikita Sobolev in 
branch 'main':
bpo-46359: Modernize `test_typing` by removing checks for EOL Python versions 
(GH-30563)
https://github.com/python/cpython/commit/8c49d057bf8618208d4ed67c9caecbfa71f7a2d0


--

___
Python tracker 

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

[issue40838] inspect.getsourcefile documentation doesn't mention it can return None

[Nikita Sobolev]

Change by Nikita Sobolev :


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

___
Python tracker 

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

[issue46328] add sys.exception()

[Irit Katriel]

Change by Irit Katriel :


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

[issue46328] add sys.exception()

[Irit Katriel]

Irit Katriel  added the comment:


New changeset c590b581bba517f81ced2e6f531ccc9e2e22eab5 by Irit Katriel in 
branch 'main':
bpo-46328: Add sys.exception() (GH-30514)
https://github.com/python/cpython/commit/c590b581bba517f81ced2e6f531ccc9e2e22eab5


--

___
Python tracker 

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

[issue46344] 3.11: except/else/if/raise traced incorrectly

[Irit Katriel]

Irit Katriel  added the comment:

Thank you Ned.

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

[issue46344] 3.11: except/else/if/raise traced incorrectly

[Irit Katriel]

Irit Katriel  added the comment:


New changeset 9c2ebb906d1c68c3d571b100c92ceb08805b94cd by Irit Katriel in 
branch 'main':
bpo-46344: Fix trace bug in else of try and try-star blocks (GH-30544)
https://github.com/python/cpython/commit/9c2ebb906d1c68c3d571b100c92ceb08805b94cd


--

___
Python tracker 

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

[issue22506] `dir` on Enum subclass doesn't expose parent class attributes

[Ethan Furman]

Ethan Furman  added the comment:

Ram asked:
-
> Also, aren't you excluding a lot of important magic methods from that `dir`?

Ethan replied:
-
> We decided the dunder methods were not interesting, so declined to include
> them in the listing.  And no, we are not changing our minds on that.  ;)

--

UPDATE:  We have changed our minds, but only for enums that have a data type, 
such as `int` or `str`, mixed in.  This behavior should be in 3.11.

--

___
Python tracker 

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

[issue37595] Python 3.7.4 does not build on Raspbian Buster with optimizations

[Christian Heimes]

Christian Heimes  added the comment:

./configure --enable-optimizations && make is passing for 3.9 branch on 
Raspbian Buster with latest updates. I tested it on one of my Raspberry Pi 3 
Model B Rev 1.2 in the morning. Python 3.7 and 3.8 are in security fix-only 
mode and therefore no longer in scope.

--
nosy: +christian.heimes
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue46363] Two typos in versions 3.7 document translation of zh_CN

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Translated documentation is maintained at 
https://github.com/python/python-docs-zh-cn/issues

--
nosy: +xtreak

___
Python tracker 

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

[issue46366] Recursively propagate the mode, in os.makedirs

[Daviddcc]

Daviddcc  added the comment:

This is the correct approach, with an umask configured

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

[issue46362] os.path.abspath() needs more normalization on Windows

[Eric V. Smith]

Eric V. Smith  added the comment:

Can you show various paths, before and after your change? It’s not clear to me 
what you’re proposing to change.

--
nosy: +eric.smith

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 4ddd5da2691bea39e36debbc7f53c7cc4f13904e by Christian Heimes in 
branch '3.9':
[3.9] bpo-40479: Fix hashlib's usedforsecurity for OpenSSL 3.0.0 (GH-30455) 
(GH-30574)
https://github.com/python/cpython/commit/4ddd5da2691bea39e36debbc7f53c7cc4f13904e


--

___
Python tracker 

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

[issue46366] Recursively propagate the mode, in os.makedirs

[Daviddcc]

New submission from Daviddcc :

os.makedirs do not propagate the requested rights, recursively creating 
directories with a 777 mode :

def makedirs(name, mode=0o777, exist_ok=False):
(...)
if head and tail and not path.exists(head):
try:
makedirs(head, exist_ok=exist_ok) # <= HERE

--
components: Library (Lib)
messages: 410480
nosy: dcasier
priority: normal
severity: normal
status: open
title: Recursively propagate the mode, in os.makedirs
type: behavior
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

[issue30569] Tutorial section 2.1 has *nix example at 3.7, but Windows at 3.6

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

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

[issue40479] Port _hashlib to OpenSSL 3.0.0

[Christian Heimes]

Christian Heimes  added the comment:

Something went wrong with Miss Islington. 
3ce6945f5f434806eea700eb5ff1bed6d39395e1 / GH-30573 is backport to 3.10.

--

___
Python tracker 

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