[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False

[Josh Meranda]

Josh Meranda  added the comment:

I agree with Bigbird and paul.j3.

> But I think this is a real bug in argparse, not a documentation problem.

> Off hand I can't think of clean way of refining the description without 
> getting overly technical about the error handling.

It seems like a reasonable conclusion to make that, "If the user would like to 
catch errors manually, the feature can be enabled by setting exit_on_error to 
False" indicates that wrapping any call to parser.parse_args() or 
parser.parse_known_args() will catch any known error that may raised. So 
outside of adding the workaround of subclassing ArgumentParser to the 
documentation, this probably needs a patch to the code.

Any solution will probably also need to implement a new error type to be able 
to handle these cases since they can be caused by multiple arguments being 
included / excluded, which is not something that ArgumentError can adequately 
describe by referencing only a single argument. Something like:

class MultipleArgumentError(ArgumentError):

def __init__(self, arguments, message):
self.argument_names = filter([_get_action_name(arg) for arg in 
arguments], lambda name: name)
self.message = message

def __str__(self):
if self.argument_names is None:
format = '%(message)s'
else:
format = 'argument %(argument_names): %(message)s'
return format % dict(message=self.message,
 argument_names=', '.join(self.argument_name))

I'm not sure I like the idea of changing the exit or error methods since they 
have a a clear purpose and don't need to be repurposed to also include error 
handling. It seems to me that adding checks to self.exit_on_error in 
_parse_known_args to handle the missing required arguments and in parse_args to 
handle unknown arguments is probably a quick and clean solution.

--
nosy: +joshmeranda
versions: +Python 3.9 -Python 3.10

___
Python tracker 

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

[issue44677] CSV sniffing falsely detects space as a delimiter

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Changing sniffer logic is risky because it risks breaking existing code that 
relies on the current predictions.

FWIW, in your example, the sniffer gets the desired result if given a delimiter 
hint:

>>> s = "a|b\nc| 'd\ne|' f"
>>> pprint.pp(dict(vars(Sniffer().sniff(s, '|'
{'__module__': 'csv',
 '_name': 'sniffed',
 'lineterminator': '\r\n',
 'quoting': 0,
 '__doc__': None,
 'doublequote': False,
 'delimiter': '|',
 'quotechar': "'",
 'skipinitialspace': False}

--
nosy: +rhettinger

___
Python tracker 

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

[issue44705] Support Windows file open modes for `open` built-in function

[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

[issue44705] Support Windows file open modes for `open` built-in function

[Dong-hee Na]

Change by Dong-hee Na :


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

[issue44705] Support Windows file open modes for `open` built-in function

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +methane

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 4194f1465fa85371dcbead57a54bb06d1f0b97d9 by Miss Islington (bot) 
in branch '3.10':
bpo-44704: Make Set._hash consistent with frozenset.__hash__ (GH-27281) 
(GH-27282)
https://github.com/python/cpython/commit/4194f1465fa85371dcbead57a54bb06d1f0b97d9


--

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset e0ef81600f4331299f61bbe3f7f08bb21d90315b by Miss Islington (bot) 
in branch '3.9':
bpo-44704: Make Set._hash consistent with frozenset.__hash__ (GH-27281) 
(GH-27283)
https://github.com/python/cpython/commit/e0ef81600f4331299f61bbe3f7f08bb21d90315b


--

___
Python tracker 

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

[issue44705] Support Windows file open modes for `open` built-in function

[Luke Deller]

New submission from Luke Deller :

Microsoft Windows supports some extra file open modes including:
 "S"Specifies that caching is optimized for, but not restricted to, 
sequential access from disk.
 "T"Specifies a file as temporary. If possible, it is not flushed to disk.
 "D"Specifies a file as temporary. It is deleted when the last file pointer 
is closed

Python 2 used to allow "T" and "D" flags in the built-in `open` function 
(though this was not documented):
https://github.com/python/cpython/blob/2.7/Objects/fileobject.c#L214

It would be great if these flags were allowed in Python 3.

I see that Python3 implementation uses `open`/`_wopen` rather than `fopen` now. 
 The mapping to numeric flags for `_wopen` is shown in the documentation here:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen 
(search for "Equivalent oflag value")

--
components: IO
messages: 397971
nosy: lukedeller1
priority: normal
severity: normal
status: open
title: Support Windows file open modes for `open` built-in function
type: enhancement
versions: Python 3.10, Python 3.11, 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

[issue44704] frozenset.__hash__ vs. Set._hash

[Raymond Hettinger]

Change by Raymond Hettinger :


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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +tim.peters

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +25826
pull_request: https://github.com/python/cpython/pull/27282

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[miss-islington]

Change by miss-islington :


--
pull_requests: +25827
pull_request: https://github.com/python/cpython/pull/27283

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset c878f5d81772dc6f718d6608c78baa4be9a4f176 by Dennis Sweeney in 
branch 'main':
bpo-44704: Make Set._hash consistent with frozenset.__hash__ (GH-27281)
https://github.com/python/cpython/commit/c878f5d81772dc6f718d6608c78baa4be9a4f176


--
nosy: +rhettinger

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue44703] deepcopy(frozenset()) returns a new object

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Returning the same object is just a micro-optimization and we've decided that 
it isn't worth it.  In bpo-40521, frozenset() stop being a singleton.  This 
costs a small bit of space but saves code complexity and a bit of execution 
time (especially given that we no longer have cheap access to global state).

Thanks for the suggestion, but we'll pass.

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

[issue44704] frozenset.__hash__ vs. Set._hash

[Dennis Sweeney]

Dennis Sweeney  added the comment:

I opened a PR. It looks like frozenset.__hash__ changed in GH-5194 and GH-5235, 
but Set._hash wasn't updated accordingly.

--

___
Python tracker 

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

[issue35183] os.path.splitext documentation needs typical example

[Jack DeVries]

Jack DeVries  added the comment:

@jstockwin, the process usually goes like this:

1. You open a PR
2. The discussion continues over there. non-core-dev volunteers review your PR 
and get it into a polished state.
3. A core dev will quickly take a look, provide feedback if necessary, or just 
merge if not.

There's no need to credit anyone – if Shaun wanted credit, he could have 
included a PR with his bug report! Plus, the commit will include this bpo#, so 
future onlookers can always trace the commit back to this thread.

Follow the dev guide as you go and don't hesitate to post any questions you 
have right here!

--
nosy: +jack__d

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[Dennis Sweeney]

Change by Dennis Sweeney :


--
keywords: +patch
nosy: +Dennis Sweeney
nosy_count: 1.0 -> 2.0
pull_requests: +25825
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27281

___
Python tracker 

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

[issue44671] Create a built-in yaml module

[Jarrod Price]

Jarrod Price  added the comment:

Could you please assist me with creating a PEP? I’ve not done it before and I’m 
not sure where to begin.

--

___
Python tracker 

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

[issue44435] There is no description of PY_SSIZE_T_CLEAN in docs

[Jack DeVries]

Jack DeVries  added the comment:

Looking back at this issue, I can see that there is documentation for this in 
the 'note' block. I'm just going to close this issue.

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

[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)

[Jack DeVries]

Jack DeVries  added the comment:

UGH I was experimenting with installing / compilingi gdb and had accidentally 
installed a different version of `ar` :/

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

[issue44703] deepcopy(frozenset()) returns a new object

[Svyatoslav]

Change by Svyatoslav :


--
type:  -> behavior

___
Python tracker 

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

[issue44704] frozenset.__hash__ vs. Set._hash

[Svyatoslav]

New submission from Svyatoslav :

In docstring of Set._hash in _collections_abc.py is written:
"We match the algorithm used by the built-in frozenset type."

But
>>> s = frozenset({i for i in range(10)})
>>> hash(s)
3895031357313128696
>>> Set._hash(s)
3914343279946282847

Looks like Set._hash is different.

--
components: Library (Lib)
messages: 397963
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: frozenset.__hash__ vs. Set._hash
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

[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)

[Jack DeVries]

Jack DeVries  added the comment:

I'm also getting this warning:

   ld: warning: object file (Programs/python.o) was built for newer 
   macOS version (11.5) than being linked (11.0)

--

___
Python tracker 

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

[issue44703] deepcopy(frozenset()) returns a new object

[Svyatoslav]

New submission from Svyatoslav :

from copy import copy, deepcopy
t = 1, 2
t1 = t, 3
t2 = t1, 4
t3 = t2, 5
assert copy(t3) is t3
assert deepcopy(t3) is t3

s = frozenset({1, 2})
assert s.copy() is s  # method .copy() always returns self, what its purpose?
assert copy(s) is s
assert deepcopy(s) is s  # raises AssertionError


Even a deepcopy of a tuple with many nested tuples is the the tuple itself, 
while a deepcopy of a frozenset which by definition cannot contain mutable 
objects is a new frozenset.
I think it is an error. A new frozenset is created because deepcopy() fallbacks 
to pickling.

--
components: Library (Lib)
messages: 397961
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: deepcopy(frozenset()) returns a new object
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

[issue44702] Fix weakref doc

[Svyatoslav]

New submission from Svyatoslav :

>From https://docs.python.org/3/library/weakref.html:
""
Not all objects can be weakly referenced; those objects which can include class 
instances, functions written in Python (but not in C), instance methods, sets, 
frozensets, some file objects, generators, type objects, sockets, arrays, 
deques, regular expression pattern objects, and code objects.
""

My first perception was that this is the list of objects without weakref 
support. Actually, the sentence lists objects which do support weakref. While 
writing this report I understood: "can" does not relate to "include" at all. 
The correct way of reading is "those objects | which can | include ...". 
Previously I had read it as "those objects | which can include ...". Even 
Google translates in such manner, commas do not help.

To remove ambguity, I suggest such fix:
""
Not all objects can be weakly referenced. Objects which support weak references 
include class instances, functions written in Python (but not in C), instance 
methods, sets, frozensets, some file objects, generators, type objects, 
sockets, arrays, deques, regular expression pattern objects, and code objects.
""
or
""
Not all objects can be weakly referenced. Сlass instances, functions written in 
Python (but not in C), instance methods, sets, frozensets, some file objects, 
generators, type objects, sockets, arrays, deques, regular expression pattern 
objects, and code objects support weak references.
""

--
assignee: docs@python
components: Documentation
messages: 397960
nosy: Prometheus3375, docs@python
priority: normal
severity: normal
status: open
title: Fix weakref doc
type: enhancement
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

[issue32635] test_crypt segfaults when using libxcrypt instead of libcrypt

[Geoffrey Thomas]

Geoffrey Thomas  added the comment:

Sorry to bump an old thread, but - does  need to be in the public 
Python.h header? Or would it be enough to be in _cryptmodule.c, which is the 
code that uses crypt_r()?

I can provide a quick patch to change that if that seems sound.

--
nosy: +geofft

___
Python tracker 

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

[issue44695] asdict use deep copy to dataclass instances

[Itay azolay]

Change by Itay azolay :


--
versions: +Python 3.10, 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

[issue44701] Create a @deprecated decorator (annotation)

[Leonardo Freua]

New submission from Leonardo Freua :

Would it be interesting to create a @deprecated decorator to avoid adding 
warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in 
methods body?

Using the decorator approach to indicate depreciation would make the methods 
cleaner (leaving only their responsibilities in the body) and would be easier 
to identify, as the cue would be close to the method signature and not mixed 
with the logic inside the body.

If everyone agrees, I could submit a PR (as a draft) for us to evaluate this 
functionality.

--
components: Library (Lib)
messages: 397958
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: Create a @deprecated decorator (annotation)
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue44695] asdict use deep copy to dataclass instances

[Ben Avrahami]

Change by Ben Avrahami :


--
nosy: +avrahami.ben

___
Python tracker 

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

[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)

[Jack DeVries]

Change by Jack DeVries :


--
type:  -> compile error
versions: +Python 3.11

___
Python tracker 

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

[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)

[Jack DeVries]

New submission from Jack DeVries :

I believe this is a problem with my machine because I've tried checking out to 
known good commits (which worked on my machine before) and have the same issue, 
but I've tried everything and don't really know what to do next. I'm hoping 
someone can help me, and who knows – maybe it is a bug!

This is the command that fails::

   gcc  -Wl,-stack_size,100  -framework CoreFoundation \
  -o Programs/_testembed Programs/_testembed.o libpython3.11d.a -ldl   \
  -framework CoreFoundation

The linker is ignoring `libpython3.11d.a`, providing the following warning::

   ignoring file libpython3.11d.a, building for macOS-arm64 but attempting to 
link with file 
   built for macOS-arm64

Of course, what follows is a ton of undefined symbol errors; no surprises 
there. I don't understand how to fix the error, why it is happening, or how 
this issue could have possibly cropped up overnight. These are the things I've 
tried to fix it:

1. Run autoconf to regenerate the configure script.
2. Delete everything. Reconfigure and rebuild from a clean slate.
3. Comment out `.zshenv`, `.zshrc`, and `.zprofile`
4. Try configuring and compiling on bash and sh instead of zsh

--
components: Build
messages: 397957
nosy: jack__d
priority: normal
severity: normal
status: open
title: Python fails to build (aarch64-apple-darwin20.5.0)

___
Python tracker 

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

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

[Guido van Rossum]

Guido van Rossum  added the comment:

Another task seems to have appeared, Nick Coghlan would like the typedef to be 
renamed to PyLocal_VarKind, and the getter/setter similarly.

--
nosy: +ncoghlan

___
Python tracker 

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

[issue42414] unable to document fields of dataclass

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I've added a new PR: https://github.com/python/cpython/pull/27279

(note it's a rough PoC draft at this point)

The output of inspect.getdoc() is the same:

A(total: int, num: int = 5)

total: int  -- number of widgets

num: int [5] -- total widgets

--

___
Python tracker 

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

[issue42414] unable to document fields of dataclass

[Andrei Kulakov]

Change by Andrei Kulakov :


--
pull_requests: +25824
pull_request: https://github.com/python/cpython/pull/27279

___
Python tracker 

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

[issue44634] Version is duplicated in name of app in list of installed apps

[Zachary Ware]

Zachary Ware  added the comment:

Agreed with Paul, it's more useful than confusing to have the version in the 
name.

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

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

[Eric Snow]

Change by Eric Snow :


--
assignee: eric.snow -> 
stage: patch review -> needs patch

___
Python tracker 

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

[issue44699] Simple regex appears to take exponential time in length of input

[János Brezniczky]

János Brezniczky  added the comment:

Hello! Thanks for the reply - you are probably right, and I accept that it's 
normal. However, there may be numerous frameworks getting built on the concept 
of collaboratively contributed regexes.

(Python likes prototyping, prototyping likes portable programming constructs, 
regular expressions are portable, for this and other factors and as past 
practice suggests, these will be a temptingly plausible choice as a basis for 
frameworks, etc.)

So I do accept it's normal (I haven't been deeply into regexes for cca 10 
years, but I vaguely recall what's complex depends a lot on the type of engine, 
maybe A or B? pass on that one).

However people make mistakes that attackers seek...

(Not to lose that point, I am otherwise okay to let it go as "not a bug" if 
you're certain! I guess something should be done though.)

--

___
Python tracker 

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

[issue44699] Simple regex appears to take exponential time in length of input

[Matthew Barnett]

Matthew Barnett  added the comment:

It's called "catastrophic backtracking". Think of the number of ways it could 
match, say, 4 characters: 4, 3+1, 2+2, 2+1+1, 1+3, 1+2+1, 1+1+2, 1+1+1+1. Now 
try 5 characters...

--

___
Python tracker 

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

[issue44699] Simple regex appears to take exponential time in length of input

[János Brezniczky]

János Brezniczky  added the comment:

I'd also raise for consideration the introduction a (default?) timeout on 
regexes, similarly to how such a feature seems available in .NET. 

Given the DOS vector vs. occasionally non-trivially complex expressions, this 
could draw developer attention to this security aspect and stimulate the 
evolution of a more secure ecosystem.

https://docs.microsoft.com/en-us/dotnet/api/system.text.regularexpressions.regex.matchtimeout?view=net-5.0

--

___
Python tracker 

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

[issue42414] unable to document fields of dataclass

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Eric: makes sense, I'll go with that.

John-Mark: I will go ahead and work on a PR along the lines Terry suggested, 
let us know if you have any objections or if you would prefer to work on a PR 
by yourself instead.

P.S. I understand now what you meant by 1 line vs. 2 lines in my first PR.

--

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Thomas Wouters]

Change by Thomas Wouters :


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

___
Python tracker 

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

[issue44699] Simple regex appears to take exponential time in length of input

[János Brezniczky]

János Brezniczky  added the comment:

Might be related to https://bugs.python.org/issue43075, as in would trigger 
ReDOSability had my syntax highlighting-related changes (which eventually broke 
golden master tests, fortunately :) ) hit the public.

(Meaning my reduced - possibly minimal - corner case stems from a practical 
scenario as well.)

--

___
Python tracker 

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

[issue44699] Simple regex appears to take exponential time in length of input

[János Brezniczky]

New submission from János Brezniczky :

I don't know if it's normal, but it's impractical.
I seem to have come by an expression consuming o(c^n) CPU cycles with c around 
2.

Regex:
\*([^*]+)*\*

Resulted in times (in seconds) of 

0.17   (* is there anybody out?)
0.34 1
0.69 12
1.36 123
2.73  1234
5.44  12345
11.1  123456  (* is there anybody123456 out?)


Please see the source for more details/repro.

--
components: Regular Expressions
files: regex_test.py
messages: 397948
nosy: brezniczky, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Simple regex appears to take exponential time in length of input
type: performance
versions: Python 3.8
Added file: https://bugs.python.org/file50169/regex_test.py

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Thomas Wouters]

New submission from Thomas Wouters :

Objects/complexobject.c's complex_pow uses undefined behaviour, by casting a 
float of unknown magnitude to a long:

int_exponent = (long)exponent.real;

At Google we build with clang and -fsanitize=float-cast-overflow by default, 
which catches this particular kind of undefined behaviour. We didn't notice, 
however, because the only code we've come across that exercises this behaviour 
was a commented-out test in test_complex, which was uncommented in 3.8. Running 
the test, or just '1e19+1j ** 1e19', is enough to trigger the undefined 
behaviour. I'll prepare a PR to fix it.

--
assignee: twouters
messages: 397947
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
status: open
title: Undefined behaviour in Objects/complexobject.c's complex_pow
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

[issue35183] os.path.splitext documentation needs typical example

[Jake Stockwin]

Jake Stockwin  added the comment:

Hello, I would like to submit a PR for this.

It'll be my first contribution to cPython and I am slightly unclear if this 
suggestion has been "accepted" in some sense (i.e. do the Devs agree it should 
be fixed as suggested)?

If so, I will go ahead and create PR (and credit shaungriffith for his provided 
examples).

--
nosy: +jstockwin

___
Python tracker 

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

[issue44697] Memory leak when asyncio.open_connection raise

[Artem]

New submission from Artem :

I write some short example.

import resource
import asyncio


class B:
def __init__(self, loop):
self.loop = loop
self.some_big_data = bytearray(1024 * 1024)  # 1Mb for memory bloating

async def doStuff(self):
if not await self.connect():
return
print('Stuff done')

async def connect(self) -> bool:
try:
_, writer = await asyncio.open_connection('127.0.0.1', 12345, 
loop=self.loop)
writer.close()
return True
except OSError as e:
pass
return False


class A:
def __init__(self, loop):
self.loop = loop

async def doBStuff(self):
b = B(self.loop)
await b.doStuff()

async def work(self):
print('Working...')
for _ in range(1000):
await self.loop.create_task(self.doBStuff())
print('Done.')
print(
'Memory usage {}kb'.format(
resource.getrusage(
resource.RUSAGE_SELF).ru_maxrss))


async def amain(loop):
a = A(loop)
await a.work()


if __name__ == "__main__":
loop = asyncio.get_event_loop()
loop.run_until_complete(amain(loop))


100 cycles
"Memory usage 41980kb"

1000 cycles
"Memory usage 55412kb"

1 cycles
"Memory usage 82880kb"

And so on...

Does anyone know workaround?

--
components: asyncio
messages: 397945
nosy: aeros, asvetlov, seer, yselivanov
priority: normal
severity: normal
status: open
title: Memory leak when asyncio.open_connection raise
type: resource usage
versions: Python 3.6

___
Python tracker 

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

[issue44693] Unclear definition of the "__future__" module in Docs

[Steven Hsu]

Steven Hsu  added the comment:

It sounds like that both descriptions (pseudo- and real) are true in different 
points of view on the __future__ module.

I have no idea how to resolve this contradiction of the original design of the 
module. Any suggestion?

Thanks for reply.

--

___
Python tracker 

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

[issue44696] Python 2.0.1 Installation:

[Steven D'Aprano]

Steven D'Aprano  added the comment:

If you really need to get Python 2.0.1 working on Windows 3.1 for some reason, 
you might find somebody interested in the problem on one of the various Python 
forums.

You could try the Python-Dev mailing list, or Python-List mailing list, or 
Reddit's r/python, or on IRC:

https://www.python.org/community/irc/

--

___
Python tracker 

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

[issue44696] Python 2.0.1 Installation:

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Python 2.0.1 is 20 years old and not supported.

I don't think that installing Python on Windows 3.1 has ever been supported. 
But even if it was, we're certainly not supporting it now.

--
nosy: +steven.daprano
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue44353] PEP 604 NewType

[Denis Laxalde]

Change by Denis Laxalde :


--
nosy: +dlax

___
Python tracker 

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

[issue44696] Python 2.0.1 Installation:

[chen-y0y0]

New submission from chen-y0y0 :

# I tried to install Python 2.0.1 onto my virtual machine(Windows 3.1) for 
low-version developing, but an error occurred while the installation:
# Error
# Could not load the DLL library
# C:\TEMP\~GLF256B.TMP.

--
components: IO, Installation, Library (Lib), Windows
messages: 397941
nosy: paul.moore, prasechen, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 2.0.1 Installation:
type: crash

___
Python tracker 

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

[issue44686] use pkgutil.resolve_name in unittest.mock

[miss-islington]

miss-islington  added the comment:


New changeset ab7fcc8fbdc11091370deeb000a787fb02f9b13d by Thomas Grainger in 
branch 'main':
bpo-44686 replace unittest.mock._importer with pkgutil.resolve_name (GH-18544)
https://github.com/python/cpython/commit/ab7fcc8fbdc11091370deeb000a787fb02f9b13d


--
nosy: +miss-islington

___
Python tracker 

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

[issue44671] Create a built-in yaml module

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

There was some discussion in 2013 : 
https://mail.python.org/archives/list/python-id...@python.org/thread/Y3Y5T54S2RSR6QW3HSEQV77EZPP7PWCX/#7H72ZRMSX74453GGURV26242UYM75VOW
 . This has to go through python-ideas and probably might need a PEP. There is 
also a request to add toml https://bugs.python.org/issue40059

--
nosy: +xtreak

___
Python tracker 

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

[issue44695] asdict use deep copy to dataclass instances

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +eric.smith

___
Python tracker 

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

[issue44695] asdict use deep copy to dataclass instances

[Itay azolay]

New submission from Itay azolay :

Hi, 
I noticed that 'asdict' use 'deepcopy' on all fields of the dataclass 
recursively. 
I believe this behavior can become optional with an argument, and shouldn't be 
decided for the user as the deepcopy takes significant amount of cpu and can 
have unexpected consequences on memory.

I don't mind taking this PR if you agree. 
Thanks

--
components: Library (Lib)
messages: 397938
nosy: Itayazolay
priority: normal
severity: normal
status: open
title: asdict use deep copy to dataclass instances
type: behavior
versions: 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

[issue44694] Message from BytesParser cannot be flattened immediately

[Vitas Ivanoff]

New submission from Vitas Ivanoff :

Hello. Here is my code:
#Parse message from file and immediately flatten it
cur_policy = email.policy.SMTPUTF8
with open("/tmp/0.tmp", "rb") as orig_message_file:
message_bytes = orig_message_file.read()
message_parser = BytesParser(policy=cur_policy)
msg = message_parser.parsebytes(message_bytes)
with open("/tmp/1.tmp", "wb") as new_message_file:
message_gen = BytesGenerator(new_message_file, policy=cur_policy)
message_gen.flatten(msg)

On some messages script raises the following error:

Traceback (most recent call last):
  File "/misc/parsemail/./1.py", line 34, in 
message_gen.flatten(msg)
  File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
  File "/usr/lib/python3.9/email/generator.py", line 199, in _write
self._write_headers(msg)
  File "/usr/lib/python3.9/email/generator.py", line 422, in _write_headers
self._fp.write(self.policy.fold_binary(h, v))
  File "/usr/lib/python3.9/email/policy.py", line 200, in fold_binary
folded = self._fold(name, value, refold_binary=self.cte_type=='7bit')
  File "/usr/lib/python3.9/email/policy.py", line 214, in _fold
return self.header_factory(name, ''.join(lines)).fold(policy=self)
  File "/usr/lib/python3.9/email/headerregistry.py", line 257, in fold
return header.fold(policy=policy)
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 156, in fold
return _refold_parse_tree(self, policy=policy)
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 2825, in 
_refold_parse_tree
last_ew = _fold_as_ew(tstr, lines, maxlen, last_ew,
  File "/usr/lib/python3.9/email/_header_value_parser.py", line 2913, in 
_fold_as_ew
encoded_word = _ew.encode(to_encode_word, charset=encode_as)
  File "/usr/lib/python3.9/email/_encoded_words.py", line 222, in encode
bstring = string.encode('ascii', 'surrogateescape')
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: 
ordinal not in range(128)

Policies 'default' and 'SMTP' are also affected. 

How to fix:

#For broken messages
message_gen = BytesGenerator(new_message_file, policy=cur_policy, 
maxheaderlen=0)

Well, but parsing and flattening the same *unmodified* message should be 
completed without using any additional parameters, isn't it?
Thanks.

--
components: email
messages: 397937
nosy: barry, r.david.murray, vitas1
priority: normal
severity: normal
status: open
title: Message from BytesParser cannot be flattened immediately
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

[issue44671] Create a built-in yaml module

[Jurj Andrei George]

Jurj Andrei George  added the comment:

I would also like to have yaml in the stdlib.

I reckon it would make sense to at least discuss yaml given that toml is on its 
way in the stdlib.

By the time a toml parser gets added, yaml will be the only major data 
serialization language to not be included in the stdlib.

--
nosy: +TheOneTheOnlyJJ

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset c8e35abfe304eb052a5220974006072c37d4b06a by Miss Islington (bot) 
in branch '3.9':
bpo-30511: Add note on thread safety to shutil.make_archive() (GH-26933) 
(GH-27275)
https://github.com/python/cpython/commit/c8e35abfe304eb052a5220974006072c37d4b06a


--

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 54d387105a5f0c3825a0f4fa607b58d55d05e572 by Miss Islington (bot) 
in branch '3.8':
bpo-30511: Add note on thread safety to shutil.make_archive() (GH-26933) 
(#27276)
https://github.com/python/cpython/commit/54d387105a5f0c3825a0f4fa607b58d55d05e572


--

___
Python tracker 

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

[issue44693] Unclear definition of the "__future__" module in Docs

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I agree that the contradiction should be resolved.

There is an actual `__future__.py` module, which on my system it is at 
/usr/local/lib/python3.9/__future__.py

But when we use the special syntax:

from __future__ import 

it doesn't do a normal import of the `__future__.py` module, it is actually a 
compiler directive.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset d17449f31d4af7a735e81b587bb329481764412f by Miss Islington (bot) 
in branch '3.10':
bpo-30511: Add note on thread safety to shutil.make_archive() (GH-26933) 
(GH-27274)
https://github.com/python/cpython/commit/d17449f31d4af7a735e81b587bb329481764412f


--

___
Python tracker 

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

[issue44693] Unclear definition of the "__future__" module in Docs

[Steven Hsu]

New submission from Steven Hsu :

In Doc/glossary.rst, the first sentence of the entry "__future__" is that "A 
pseudo-module which programmers can use to enable new language features which 
are not compatible with the current interpreter."

However, in Doc/library/__future__.rst, the first sentence is that 
":mod:`__future__` is a real module, and serves three purposes:"

Is there any contradiction of these two descriptions, that "pseuso-module" and 
"real module" refer to the same module?

And if so, should we fix one of them?

Thanks for review!

--
assignee: docs@python
components: Documentation
messages: 397931
nosy: StevenHsuYL, docs@python
priority: normal
severity: normal
status: open
title: Unclear definition of the "__future__" module in Docs
type: enhancement
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

[issue44689] MacOS: Python binaries not portable between Catalina and Big Sur

[Tobias Bergkvist]

Tobias Bergkvist  added the comment:

An alternative to using _dyld_shared_cache_contains_path is to use dlopen to 
check for library existence (which is what Apple recommends in their change 
notes: 
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes).

> New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker 
> cache of all system-provided libraries. As part of this change, copies of 
> dynamic libraries are no longer present on the filesystem. Code that attempts 
> to check for dynamic library presence by looking for a file at a path or 
> enumerating a directory will fail. Instead, check for library presence by 
> attempting to dlopen() the path, which will correctly check for the library 
> in the cache. (62986286)

I have created a PR which modifies the current find_library from using 
_dyld_shared_cache_contains_path to dlopen. It passes all of the existing 
find_library-tests:
https://github.com/python/cpython/pull/27251

There might be downsides to using dlopen (performance?) or something else I 
haven't considered. The huge upside however, is that the function is basically 
available on all Unix-systems.

--

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[miss-islington]

Change by miss-islington :


--
pull_requests: +25821
pull_request: https://github.com/python/cpython/pull/27276

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[miss-islington]

Change by miss-islington :


--
pull_requests: +25820
pull_request: https://github.com/python/cpython/pull/27275

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue30511] shutil.make_archive should not need to chdir (alternatively: make shutil.make_archive thread-safe)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 64f54b7ccd49764b0304e076bfd79b5482988f53 by andrei kulakov in 
branch 'main':
bpo-30511: Add note on thread safety to shutil.make_archive() (#26933)
https://github.com/python/cpython/commit/64f54b7ccd49764b0304e076bfd79b5482988f53


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44689] MacOS: Python binaries not portable between Catalina and Big Sur

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Anyways, the solution for "build on older macOS version, deploy to Big Sur" is 
to dynamically look for the relevant API (``_dyld_shared_cache_contains_path``) 
and use it when available. But only in that scenario, the current code path 
using explicit weak linking should be kept for those building using a recent 
SDK (cleaner code, better error reporting).

This should be a fairly easy patch, but I don't know when I'll get around to 
looking into this further.

Alternatively we could require that Python is build using the macOS 11 SDK (or 
later) when targeting Big Sur.

I'm dropping 3.8 from the list of versions because it is in "bug fix only" mode 
and won't receive a patch for this.  IIRC 3.8 also doesn't support Big Sur in 
the first place, we've only back ported Big Sur support to 3.9.

--
stage:  -> needs patch
versions:  -Python 3.8

___
Python tracker 

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

[issue44689] MacOS: Python binaries not portable between Catalina and Big Sur

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The problem with moving from Catalina to Big Sur is a known issue, AFAIK 
there's an open issue for this.

The problem is that Big Sur moved system libraries into a big blob (which Apple 
calls the shared library cache). Ctypes uses an API that's new in macOS 11 to 
check if a library is in that cache, but only when compiled with the the macOS 
11 SDK or later as the API is not available in earlier SDKs.

Moving from Big Sur to earlier version should work fine, but only if you set 
the deployment target correctly during the build. This is how the "universal2" 
installers on python.org are build.

--

___
Python tracker 

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