[issue42944] random.Random.sample bug when counts is not None

[Jon FRANCO]

Change by Jon FRANCO :


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

___
Python tracker 

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

[issue42944] random.Random.sample bug when counts is not None

[Jon FRANCO]

Jon FRANCO  added the comment:

PR submitted. 
Let me know if I missed something, this is also my first PR.
Regards.

--

___
Python tracker 

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

[issue42942] Feature request: Add decdigest() to hashlib

[Christian Heimes]

Christian Heimes  added the comment:

Do you have any benchmarks that back up your claim that integers are faster 
than using digest or hexdigests? Python's str and bytes types are highly 
optimized.

Hash digests don't fit into native integers, because they are larger than 
uint64_t and therefore have to be converted into arbitrary size integers (aka 
bigints). Arbitrary size integers have an overhead. For example it's slower to 
convert bytes to an integer than to hex string. Comparison of long its takes 
about as much time as comparing bytes.

By the way int(h.hexdigest(), 16) is a slow and inefficient way to convert a 
hash digest into an integer. int.from_bytes(h.digest(), endian) is much faster.

$ ./python -m timeit -s "from hashlib import sha256; s = sha256()" "s.digest()"
50 loops, best of 5: 450 nsec per loop
$ ./python -m timeit -s "from hashlib import sha256; s = sha256()" 
"s.hexdigest()"
50 loops, best of 5: 615 nsec per loop
$ ./python -m timeit -s "from hashlib import sha256; s = sha256()" 
"int.from_bytes(s.digest(), 'big')"
50 loops, best of 5: 809 nsec per loop
$ ./python -m timeit -s "from hashlib import sha256; s = sha256()" 
"int(s.hexdigest(), 16)"
20 loops, best of 5: 1.03 usec per loop

--
nosy: +christian.heimes, gregory.p.smith

___
Python tracker 

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

[issue42942] Feature request: Add decdigest() to hashlib

[Christian Heimes]

Christian Heimes  added the comment:

Is there any particular reason you are using bisect search with sorted list of 
integers? Why don't you use a simple approach with a dict of digest bytes? 
bisect search is O(log(n)), dict lookup is O(1) and therefore scales much 
better.

--

___
Python tracker 

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

[issue42705] Intercepting thread lock objects not working under context managers

[Jeremy Kloth]

Change by Jeremy Kloth :


--
components:  -Distutils

___
Python tracker 

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

[issue42923] Py_FatalError(): dump the list of extension modules

[STINNER Victor]

STINNER Victor  added the comment:

Example of a Pillow crash in Python 3.10:
https://mail.python.org/archives/list/python-...@python.org/message/5DCR2R6POCOHTPFUOY4F5G7GTBYX6OPO/

--

___
Python tracker 

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

[issue42946] email: ValueError in get_section when parsing header with non-ASCII digit

[Florian Bruhin]

New submission from Florian Bruhin :

Found mostly by accident:

>>> import email.headerregistry
>>> reg = email.headerregistry.HeaderRegistry()
>>> h = reg('Content-Disposition', 'inline; 0*²')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.10/email/headerregistry.py", line 608, in __call__
return self[name](name, value)
  File "/usr/lib/python3.10/email/headerregistry.py", line 196, in __new__
cls.parse(value, kwds)
  File "/usr/lib/python3.10/email/headerregistry.py", line 452, in parse
kwds['parse_tree'] = parse_tree = cls.value_parser(value)
  File "/usr/lib/python3.10/email/_header_value_parser.py", line 2705, in 
parse_content_disposition_header
disp_header.append(parse_mime_parameters(value[1:]))
  File "/usr/lib/python3.10/email/_header_value_parser.py", line 2569, in 
parse_mime_parameters
token, value = get_parameter(value)
  File "/usr/lib/python3.10/email/_header_value_parser.py", line 2431, in 
get_parameter
token, value = get_section(value)
  File "/usr/lib/python3.10/email/_header_value_parser.py", line 2384, in 
get_section
section.number = int(digits)
ValueError: invalid literal for int() with base 10: '²'

This probably happens because:

>>> '²'.isdigit()
True
>>> int('²')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: '²'

--
components: Library (Lib)
messages: 385162
nosy: The Compiler, barry, maxking, r.david.murray
priority: normal
severity: normal
status: open
title: email: ValueError in get_section when parsing header with non-ASCII digit
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue42947] email: Handling when both extended/ascii parameter (filename*/filename) are present?

[Florian Bruhin]

New submission from Florian Bruhin :

Consider this reproducer:

>>> import email.headerregistry
>>> reg = email.headerregistry.HeaderRegistry()
>>> parsed = reg('Content-Disposition', """attachment; 
filename="foo-ae.html"; filename*=UTF-8''foo-%c3%a4.html""")
>>> parsed.defects
(InvalidHeaderDefect('duplicate parameter name; duplicate(s) ignored'),)
>>> parsed.params['filename']
'foo-ae.html'

However, the relevant section of RFC 5987 says:

https://greenbytes.de/tech/webdav/rfc5987.html#rfc.section.4.2

> This specification suggests that a parameter using the extended syntax takes 
> precedence. This would allow producers to use both formats without breaking 
> recipients that do not understand the extended syntax yet.

And RFC 6266 says:

https://greenbytes.de/tech/webdav/rfc6266.html#rfc.section.4.3

> Many user agent implementations predating this specification do not 
> understand the "filename*" parameter. Therefore, when both "filename" and 
> "filename*" are present in a single header field value, recipients should 
> pick "filename*" and ignore "filename". This way, senders can avoid 
> special-casing specific user agents by sending both the more expressive 
> "filename*" parameter, and the "filename" parameter as fallback for legacy 
> recipients (see Section 5 for an example).

Also see the related attfnboth and attfnboth2 test cases here:
http://test.greenbytes.de/tech/tc2231/#attfnboth

I'm aware those two RFCs are specific to HTTP - but given that there's a "HTTP" 
policy and "utils.py" has some HTTP-specific date/time handling, I suppose 
correct handling of this might be in scope as well?

--
components: Library (Lib)
messages: 385163
nosy: The Compiler
priority: normal
severity: normal
status: open
title: email: Handling when both extended/ascii parameter (filename*/filename) 
are present?
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue42948] bytearray.copy is undocumented

[wim glenn]

New submission from wim glenn :

bytearray type has a copy method which seems to be undocumented

https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations

--
assignee: docs@python
components: Documentation
messages: 385164
nosy: docs@python, wim.glenn
priority: normal
severity: normal
status: open
title: bytearray.copy is undocumented
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue42942] Feature request: Add decdigest() to hashlib

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Agreed, using a dict or set hash table lookup is more appropriate for such an 
algorithm.

Also agreed: comparing python integers (30-bit digit bignums internally) cannot 
be faster than comparing a binary bytes object.

--

___
Python tracker 

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

[issue42942] Feature request: Add decdigest() to hashlib

[Arnim Rupp]

Arnim Rupp  added the comment:

oh, you're absolutely right about digest(), sorry, mixed the representation 
with the data. closing this, thanks.

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

[issue42948] bytearray.copy is undocumented

[Patrick Haller]

Patrick Haller  added the comment:

You will see this on every bytes and bytearray type as the behaviour described 
is the same for both.

--
nosy: +HallerPatrick

___
Python tracker 

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

[issue42949] pdb & multiprocessing.Pool: AttributeError: module '__main__' has no attribute '__spec__'

[Freek Dijkstra]

New submission from Freek Dijkstra :

Summary:

multiprocessing.Pool contains a bug when the script is invoked with pdb.



Steps to reproduce:

Consider the following script:

```
from multiprocessing import Pool

def f(x):
return x*x

if __name__ == '__main__':
with Pool(5) as p:
print(p.map(f, [1, 2, 3]))
```

When called as `python3.10 test.py`, this works fine, and returns `[1, 4, 9]`

When called as `python3.10 -m pdb test.py`, it gives the following exception:

```
freek@minnie ~ » python3.9 -m pdb test.py
> /Users/freek/test.py(3)()
-> from multiprocessing import Pool
(Pdb) c
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/pdb.py",
 line 1704, in main
pdb._runscript(mainpyfile)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/pdb.py",
 line 1573, in _runscript
self.run(statement)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/bdb.py",
 line 580, in run
exec(cmd, globals, locals)
  File "", line 1, in 
  File "/Users/freek/test.py", line 3, in 
from multiprocessing import Pool
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py",
 line 119, in Pool
return Pool(processes, initializer, initargs, maxtasksperchild,
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/pool.py",
 line 212, in __init__
self._repopulate_pool()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/pool.py",
 line 303, in _repopulate_pool
return self._repopulate_pool_static(self._ctx, self.Process,
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/pool.py",
 line 326, in _repopulate_pool_static
w.start()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/process.py",
 line 121, in start
self._popen = self._Popen(self)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py",
 line 284, in _Popen
return Popen(process_obj)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py",
 line 32, in __init__
super().__init__(process_obj)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_fork.py",
 line 19, in __init__
self._launch(process_obj)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py",
 line 42, in _launch
prep_data = spawn.get_preparation_data(process_obj._name)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py",
 line 183, in get_preparation_data
main_mod_name = getattr(main_module.__spec__, "name", None)
AttributeError: module '__main__' has no attribute '__spec__'
```

I can reproduce this in Python 3.8.7, 3.9.1, 3.10.0a3. It works fine in Python 
3.7.9.

A workaround is to define `__spec__` in __main__:

```
from multiprocessing import Pool

def f(x):
return x*x

if __name__ == '__main__':
__spec__ = None
with Pool(5) as p:
print(p.map(f, [1, 2, 3]))
```

I'd say that multiprocessing/spawn.py", line 183, in get_preparation_data is 
flawed
main_mod_name = getattr(main_module.__spec__, "name", None)

--
components: Library (Lib)
messages: 385168
nosy: macfreek
priority: normal
severity: normal
status: open
title: pdb & multiprocessing.Pool: AttributeError: module '__main__' has no 
attribute '__spec__'
versions: Python 3.10, 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

[issue41972] bytes.find consistently hangs in a particular scenario

[Dennis Sweeney]

Dennis Sweeney  added the comment:

PR 22904 now adds a text document explaining how the Two-Way algorithm works in 
much more detail.

I was looking at more benchmarking results, and I came to a couple of 
conclusions about cutoffs.

There's a consistent benefit to using the two-way algorithm whenever both 
strings are long enough and the needle is less than 20% the length of the 
haystack. If that percentage is higher, the preprocessing cost starts to 
dominate, and the Two-Way algorithm is slower than the status quo in average 
such cases. This doesn't change the fact that in cases like OP's original 
example, the Two-way algorithm can be thousands of times faster than the status 
quo, even though the needle is a significant percentage of the length of the 
haystack.

So to handle that, I tried an adaptive/introspective algorithm like Tim 
suggested: it counts the number of matched characters that don't lead to full 
matches, and once that total exceeds O(m), the Two-Way preprocessing cost will 
surely be worth it. The only way I could figure out how to not damage the speed 
of the usual small-string cases is to duplicate that code. See comparison.jpg 
for how much better the adaptive version is as opposed to always using two-way 
on this Zipf benchmark, while still guaranteeing O(m + n).

--
Added file: https://bugs.python.org/file49746/comparison.jpg

___
Python tracker 

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

[issue42950] Incorrect exception behavior in handling recursive call.

[Xinmeng Xia]

New submission from Xinmeng Xia :

Seeing the following programs, we try to catch a recursive call error in 
exception handling.  The behaviors between Python 3.10.0a4 and older version 
are inconsistent. The outputs are attached in the end. The output on Python 
3.10.0a4 is very weird. Two "print statements" lie in same "except" block to 
print "exception info" and a string "kk". "kk" is printed once while "exception 
info" is printed twice! I think a bug probably exists in Python 3.10.0a4 parser 
on handling stacks. 


=
def foo(c):
 try:
 c = c + 1
 print("ss"+str(c))
 foo(c)
 except Exception as e:
 print(str(e))
 print("kk")
 print(c)
c = 0
foo(c)
=

Output in Python 3.10.0a2 and older version(expected)

ss1
ss2

ss996
maximum recursion depth exceeded while calling a Python object
kk
996
995
..
3
2
1


Output in Python 3.10.0a4 (unexpected)

ss1
ss2

ss996
maximum recursion depth exceeded while calling a Python object
maximum recursion depth exceeded while calling a Python object
kk
995
..
3
2
1


--
components: Interpreter Core
messages: 385170
nosy: xxm
priority: normal
severity: normal
status: open
title: Incorrect exception behavior in handling recursive call.
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue42951] Random and infinite loop in dealing with recursion error for "try-except "

[Xinmeng Xia]

New submission from Xinmeng Xia :

In issue 42500, recursive calls in "Try-except" are resolved. This PR has fixed 
the crashes of some programs, such as program 1. And the core dump error is 
replaced with RecursiveError.  
However, program 2 will not report a RecursiveError. The program will fall into 
an infinite loop. Even "Ctrl C" cannot stop the infinite loop. I try to track 
the execution of this program and insert "print" information(see program 3). 
The output seems random in execution between try branch and except branch!  I 
think this is a new bug after fixing 42500. I believe the program should also 
return RecursiveError.


Program 1
=== 
def foo():
try:
1/0
except:
foo()
foo()


Program 2

def foo():
try:
foo()
except:
foo()
foo()



Program 3

def foo():
try:
print("a")
foo()
except:
print("b")
foo()

foo()

Output for program3( unexpected infinite random loop. ):
..bbbbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbabbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbaabbabbaabbabbaaabbabbaabbabbbb..

>>python -V
Python 3.10.0a4

--
components: Interpreter Core
messages: 385171
nosy: xxm
priority: normal
severity: normal
status: open
title: Random and infinite loop in dealing with recursion error for "try-except 
"
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

[Xinmeng Xia]

Xinmeng Xia  added the comment:

It seems that this bug won't be fixed. Should this issue be closed now?

--

___
Python tracker 

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

[issue42952] Incorrect handling of EC_KEY_new_by_curve_name() in the _ssl module

[Zackery Spytz]

New submission from Zackery Spytz :

A EC_KEY_new_by_curve_name() call in the _ssl__SSLContext_impl() function is 
not checked for failure.

--
assignee: christian.heimes
components: Extension Modules, SSL
messages: 385173
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: Incorrect handling of EC_KEY_new_by_curve_name() in the _ssl module
versions: Python 3.10, 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

[issue42952] Incorrect handling of EC_KEY_new_by_curve_name() in the _ssl module

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue42950] Incorrect exception behavior in handling recursive call.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +Mark.Shannon, serhiy.storchaka

___
Python tracker 

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

[issue42953] After the subclass of enum.Enum is imported in some diffenent ways, the same enumeration value is judged as False

[Chenxi Liu]

New submission from Chenxi Liu :

When you run the test.py in attachment, it will print a False but the two 
enumeration value which are acquired in different ways is same

--
components: Library (Lib)
files: test.zip
messages: 385174
nosy: Lcx994611818
priority: normal
severity: normal
status: open
title: After the subclass of enum.Enum is imported in some diffenent ways, the 
same enumeration value is judged as False
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49747/test.zip

___
Python tracker 

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

[issue42952] Incorrect handling of EC_KEY_new_by_curve_name() in the _ssl module

[Christian Heimes]

Christian Heimes  added the comment:

Thanks!

The block is dead code. OpenSSL 1.0.2 and newer always defines 
SSL_CTX_set_ecdh_auto. All supported LibreSSL versions define 
SSL_CTX_set_ecdh_auto, too. I'll remove the block when PEP 644 is accepted.

--

___
Python tracker 

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

[issue42939] Linux's chattr i.e. ioctl(FS_IOC_SETFLAGS) is not supported in os.chflags()

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +christian.heimes

___
Python tracker 

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