[issue45102] unittest: add tests for skipping and errors in cleanup

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 28264269de9ff88d9ee7110fc56ac2d2db275bec by Serhiy Storchaka in 
branch 'main':
bpo-45102: unittest: add tests for skipping and errors in cleanup (GH-28166)
https://github.com/python/cpython/commit/28264269de9ff88d9ee7110fc56ac2d2db275bec


--

___
Python tracker 

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

[issue45102] unittest: add tests for skipping and errors in cleanup

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +26601
pull_request: https://github.com/python/cpython/pull/28174

___
Python tracker 

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

[issue45102] unittest: add tests for skipping and errors in cleanup

[miss-islington]

Change by miss-islington :


--
pull_requests: +26602
pull_request: https://github.com/python/cpython/pull/28175

___
Python tracker 

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

[issue45100] Teach help about typing.overload()

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I agree that this would be nice to have, but wonder how help() could access 
that information.  The two @overload definitions will be overwritten by the 
non-overload one at runtime, and hence will ever been seen by help().

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue45102] unittest: add tests for skipping and errors in cleanup

[miss-islington]

miss-islington  added the comment:


New changeset 8342c526e9cf138a10668fa9e487d92ee1a3a42c by Miss Islington (bot) 
in branch '3.10':
bpo-45102: unittest: add tests for skipping and errors in cleanup (GH-28166)
https://github.com/python/cpython/commit/8342c526e9cf138a10668fa9e487d92ee1a3a42c


--

___
Python tracker 

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

[issue45102] unittest: add tests for skipping and errors in cleanup

[miss-islington]

miss-islington  added the comment:


New changeset f91d974ce61b2a9922391f723b388a623284fb0a by Miss Islington (bot) 
in branch '3.9':
bpo-45102: unittest: add tests for skipping and errors in cleanup (GH-28166)
https://github.com/python/cpython/commit/f91d974ce61b2a9922391f723b388a623284fb0a


--

___
Python tracker 

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

[issue44863] Allow TypedDict to inherit from Generics

[Ken Jin]

Ken Jin  added the comment:

Guido, OP has kindly written a mini PEP for this. Do you think just updating 
PEP 589 is sufficient, or do we need a full PEP?

(PS. Changed version to 3.11 since we've missed the train for 3.10 
enhancements).

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

[issue45100] Teach help about typing.overload()

[Ken Jin]

Change by Ken Jin :


--
nosy: +gvanrossum, kj

___
Python tracker 

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

[issue45102] unittest: add tests for skipping and errors in cleanup

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue45105] Incorrect handling of unicode character \U00010900

[Max Bachmann]

New submission from Max Bachmann :

I noticed that when using the Unicode character \U00010900 when inserting the 
character as character:
Here is the result on the Python console both for 3.6 and 3.9:
```
>>> s = '0𐤀00'
>>> s
'0𐤀00'
>>> ls = list(s)
>>> ls
['0', '𐤀', '0', '0']
>>> s[0]
'0'
>>> s[1]
'𐤀'
>>> s[2]
'0'
>>> s[3]
'0'
>>> ls[0]
'0'
>>> ls[1]
'𐤀'
>>> ls[2]
'0'
>>> ls[3]
'0'
```

It appears that for some reason in this specific case the character is actually 
stored in a different position that shown when printing the complete string. 
Note that the string is already behaving strange when marking it in the 
console. When marking the special character it directly highlights the last 3 
characters (probably because it already thinks this character is in the second 
position).

The same behavior does not occur when directly using the unicode point
```
>>> s='000\U00010900'
>>> s
'000𐤀'
>>> s[0]
'0'
>>> s[1]
'0'
>>> s[2]
'0'
>>> s[3]
'𐤀'
```

This was tested using the following Python versions:
```
Python 3.6.0 (default, Dec 29 2020, 02:18:14) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux

Python 3.9.6 (default, Jul 16 2021, 00:00:00) 
[GCC 11.1.1 20210531 (Red Hat 11.1.1-3)] on linux
```
on Fedora 34

--
components: Unicode
messages: 401078
nosy: ezio.melotti, maxbachmann, vstinner
priority: normal
severity: normal
status: open
title: Incorrect handling of unicode character \U00010900
type: behavior
versions: Python 3.6, Python 3.9

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Max Bachmann]

Max Bachmann  added the comment:

This is the result of copy pasting example posted above on windows using 
```
Python 3.7.8 (tags/v3.7.8:4b47a5b6ba, Jun 28 2020, 08:53:46) [MSC v.1916 64 bit 
(AMD64)] on win32
```
which appears to run into similar problems:
```
>>> s = '0��00' 
>>> 
>>> 
>>> 
>>>   >>> s 
>>> 
>>> 
>>> 
>>> 
>>> '0𐤀00'  
>>> 
>>> 
>>> 
>>>   >>> ls = list(s)  
>>> 
>>> 
>>> 
>>> 
>>> >>> ls  
>>> 
>>> 
>>> 
>>>   ['0', '𐤀', '0', '0']  
>>> 
>>> 
>>> 
>>> 
>>> >>> s[0]
>>> 
>>> 
>>> 
>>>   '0'   
>>> 
>>> 
>>> 
>>> 
>>> >>> s[1]
>>> 
>>> 
>>> 
>>>   '𐤀'
```

--

___
Python tracker 

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

[issue45100] Teach help about typing.overload()

[Alex Waygood]

Alex Waygood  added the comment:

There is a similar issue with `functools.singledispatch`

```
>>> from functools import singledispatch
>>> @singledispatch
... def flip(x: str) -> int:
... """Signature when given a string"""
... return int(x)
... 
>>> @flip.register
... def _(x: int) -> str:
... """Signature when given an int"""
... return str(x)
... 
>>> flip(5)
'5'
>>> flip('5')
5
>>> help(flip)
Help on function flip in module __main__:
flip(x: str) -> int
Signature when given a string
```

--
nosy: +AlexWaygood

___
Python tracker 

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

[issue44892] [configparser] Module configparser fails when the config file contains a "%" inside a commentary

[Diego Ramirez]

Diego Ramirez  added the comment:

Any commentaries about this issue?

--

___
Python tracker 

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

[issue45100] Teach help about typing.overload()

[Diego Ramirez]

Change by Diego Ramirez :


--
nosy: +DiddiLeija

___
Python tracker 

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

[issue44892] [configparser] Module configparser fails when the config file contains a "%" inside a commentary

[Diego Ramirez]

Change by Diego Ramirez :


--
type: crash -> behavior

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Eryk Sun]

Eryk Sun  added the comment:

AFAICT, there is no bug here. It's just confusing how Unicode right-to-left 
characters in the repr() can modify how it's displayed in the console/terminal. 
Use the ascii() representation to avoid the problem.

> The same behavior does not occur when directly using the unicode point
> ```
> >>> s='000\U00010900'

The original string has the Phoenician right-to-left character at index 1, not 
at index 3. The "0" number characters in the original have weak directionality 
when displayed. You can see the reversal with a numeric sequence that's 
separated by spaces. For example:

s = '123\U00010900456'
>>> print(*s, sep='\n')
1
2
3
𐤀
4
5
6
>>> print(*s)
1 2 3 𐤀 4 5 6

Latin letters have left-to-right directionality. For example:

>>> s = '123\U00010900abc'
>>> print(*s)
1 2 3 𐤀 a b c

You can check the bidirectional property [1] using the unicodedata module:

>>> import unicodedata as ud
>>> ud.bidirectional('\U00010900')
'R'
>>> ud.bidirectional('0')
'EN'
>>> ud.bidirectional('a')
'L'

---

[1] 
https://en.wikipedia.org/wiki/Unicode_character_property#Bidirectional_writing

--
nosy: +eryksun

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I'm afraid I cannot reproduce the problem.

>>> s = '000𐤀'  # \U00010900
>>> s
'000𐤀'
>>> s[0]
'0'
>>> s[1]
'0'
>>> s[2]
'0'
>>> s[3]
'𐤀'
>>> list(s)
['0', '0', '0', '𐤀']


That is using Python 3.9 in the xfce4-terminal. Which xterm are you using?

I am very confident that it is a bug in some external software, possibly the 
xterm, possibly the browser or other application where you copied the 
PHOENICIAN LETTER ALF character from in the first place. It looks like it is 
related to mishandling of the Right-To-Left character:

>>> unicodedata.bidirectional(s[3])
'R'


Using Firefox, when I attempt to select the text s = '000...' in Max's initial 
message with the mouse, the selection highlighting jumps around. See the 
screenshot attached. (selection.png) Depending on how I copy the text, 
sometimes I get '000 ALF' and sometimes '0 ALF 00' which hints that something 
is getting confused by the RTL character, possibly the browser, possible the 
copy/paste clipboard, possibly the terminal. But regardless, I cannot replicate 
the behaviour you show where list(s) is different from indexing the characters 
one by one.

It is very common for applications to mishandle mixed RTL and LTR characters, 
and that can have all sorts of odd display and copy/paste issues.

--
nosy: +steven.daprano
Added file: https://bugs.python.org/file50260/selection.png

___
Python tracker 

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

[issue45026] More compact range iterator

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +26603
pull_request: https://github.com/python/cpython/pull/28176

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Eryk Sun said:

> The original string has the Phoenician right-to-left character at index 1, 
> not at index 3.


I think you may be mistaken. In Max's original post, he has

s = '000X'

where the X is actually the Phoenician ALF character. At least that is how it 
is displayed in my browser.

(But note that in the Windows terminal, Max has '0X00' instead.)

Max's demonstration code shows a discrepancy between extracting the chars one 
by one using indexing, and with list. Simulating his error:

s = '000X'  # X is actually ALF
list(s)
# --> returns [0 0 0 X]
[s[i] for i in range(4)]  # indexing each char one at a time
# --> returns [0 X 0 0]

I have not yet been able to replicate that reported behaviour.

I agree totally with Eryk Sun that this is probably not a Python bug. He thinks 
it is displaying the correct behaviour. I think it is probably a browser or 
xterm bug.

But unless someone can replicate the mismatch between list and indexing, I 
doubt it is something we can do anything about.

--

___
Python tracker 

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

[issue45026] More compact range iterator

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 28176 implements idea proposed by Dennis in msg400396. It keeps the current 
and stop values instead of the initial start, index and initial length. I do 
not have data yet, but it is expected that it's iteration may be faster (for 
large integers), but __lenght_hint__ should be slower.

--

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Eryk Sun]

Eryk Sun  added the comment:

> I think you may be mistaken. In Max's original post, he has
>   s = '000X'

It displays that way for me under Firefox in Linux, but what's really there 
when I copy it from Firefox is '0\U000109', which matches the result Max 
gets for individual index operations such as s[1]. 

The "0" characters following the R-T-L character have weak directionality. So 
the string displays the same as "000\U00010900". If you print with spaces and 
use a number sequence, the substring starting with the R-T-L character should 
display reversed, i.e. print(*'123\U00010900456') should display the same as 
print(*'123654\U00010900'). But "abc" in print(*'123\U00010900abc') should not 
display reversed since it has L-T-R directionality.

--

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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

[issue44863] Allow TypedDict to inherit from Generics

[Guido van Rossum]

Guido van Rossum  added the comment:

Updating an existing (standards track) PEP significantly is not
traditional. I recommend writing a new PEP.

On Sun, Sep 5, 2021 at 01:24 Ken Jin  wrote:

>
> Ken Jin  added the comment:
>
> Guido, OP has kindly written a mini PEP for this. Do you think just
> updating PEP 589 is sufficient, or do we need a full PEP?
>
> (PS. Changed version to 3.11 since we've missed the train for 3.10
> enhancements).
>
> --
> versions:  -Python 3.10
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Max Bachmann]

Max Bachmann  added the comment:

> That is using Python 3.9 in the xfce4-terminal. Which xterm are you using?

This was in the default gnome terminal that is pre-installed on Fedora 34 and 
on windows I directly opened the Python Terminal. I just installed 
xfce4-terminal on my Fedora 34 machine which has exactly the same behavior for 
me that I had in the gnome terminal.

> But regardless, I cannot replicate the behavior you show where list(s) is 
> different from indexing the characters one by one.

That is what surprised me the most. I just ran into this because this was 
somehow generated when fuzz testing my code using hypothesis (which uncovered 
an unrelated bug in my application). However I was quite confused by the 
character order when debugging it.

My original case was:
```
s1='00'
s2='9010𐤀000\x8dÀĀĀĀ222Ā'
parts = [s2[max(0, i) : min(len(s2), i+len(s1))] for i in range(-len(s1), 
len(s2))]
for part in parts:
print(list(part))
```
which produced
```
[]
['9']
['9', '0']
['9', '0', '1']
['9', '0', '1', '0']
['9', '0', '1', '0', '𐤀']
['9', '0', '1', '0', '𐤀', '0']
['0', '1', '0', '𐤀', '0', '0']
['1', '0', '𐤀', '0', '0', '0']
['0', '𐤀', '0', '0', '0', '\x8d']
['𐤀', '0', '0', '0', '\x8d', 'À']
['0', '0', '0', '\x8d', 'À', 'Ā']
['0', '0', '\x8d', 'À', 'Ā', 'Ā']
['0', '\x8d', 'À', 'Ā', 'Ā', 'Ā']
['\x8d', 'À', 'Ā', 'Ā', 'Ā', '2']
['À', 'Ā', 'Ā', 'Ā', '2', '2']
['Ā', 'Ā', 'Ā', '2', '2', '2']
['Ā', 'Ā', '2', '2', '2', 'Ā']
['Ā', '2', '2', '2', 'Ā']
['2', '2', '2', 'Ā']
['2', '2', 'Ā']
['2', 'Ā']
['ĀÀ]
```
which has a missing single quote:
  - ['ĀÀ]
changing direction of characters including commas:
  - ['1', '0', '𐤀', '0', '0', '0']
changing direction back:
  - ['𐤀', '0', '0', '0', '\x8d', 'À']

> AFAICT, there is no bug here. It's just confusing how Unicode right-to-left 
> characters in the repr() can modify how it's displayed in the 
> console/terminal.

Yes it appears the same confusion occurs in other applications like Firefox and 
VS Code.
Thanks at @eryksun and @steven.daprano for testing and telling me about 
Bidirectional writing in Unicode (The more I know about Unicode the more it 
scares me)

--
status: pending -> open

___
Python tracker 

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

[issue45106] Issue formating for log on Linux machines

[Andrew Suttle]

New submission from Andrew Suttle :

Using the format option for Python logging works fine on all windows machines:

logging.basicConfig(filename='log.log', encoding='utf-8', 
level=logging.DEBUG,format='%(asctime)s : %(message)s ')

But error occurs on Linux mint 64 20.2 using Python 3.8 when the % symbol in 
the format causes a problem.

Traceback (most recent call last):
File "/usr/lib/python3.8/idlelib/run.py", line 559, in runcode
exec(code, self.locals)
File "/media/victor/B694-5211/python now git/prototype server3.py", line 14, in
logging.basicConfig(filename='log.log', encoding='utf-8', 
level=logging.DEBUG,format='%(asctime)s:%(message)s')
File "/usr/lib/python3.8/logging/init.py", line 2009, in basicConfig
raise ValueError('Unrecognised argument(s): %s' % keys)
ValueError: Unrecognised argument(s): encoding

--
files: program.txt
messages: 401089
nosy: andrewsuttle56
priority: normal
severity: normal
status: open
title: Issue formating for log on Linux machines
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file50261/program.txt

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> what's really there when I copy it from Firefox is '0\U000109', 
> which matches the result Max gets for individual index operations such as 
> s[1]. 

But *not* the result that Max got from calling list().

Can you reproduce that difference between indexing and list?

Also you say "what's really there", but what is your reasoning for that? 
How do you know that Firefox is displaying the string wrongly, rather 
than displaying it correctly and copying it to the clipboard wrongly?

When I look at the page source of the b.p.o page, I see:

I noticed that when using the Unicode character \U00010900 when 
inserting the character as character:
Here is the result on the Python console both for 3.6 and 3.9:
```
>>> s = '000X'

again, with X standing in for the Phoenician ALF character. But when I 
copy and paste it into my terminal, I see

>>> s = '0X00'

--

___
Python tracker 

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

[issue41031] Inconsistency in C and python traceback printers

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9e31b3952f6101ef71ec029481b972169ab0e0f1 by Irit Katriel in 
branch 'main':
bpo-41031: Match C and Python code formatting of unprintable exceptions and 
exceptions in the __main__ module. (GH-28139)
https://github.com/python/cpython/commit/9e31b3952f6101ef71ec029481b972169ab0e0f1


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue45105] Incorrect handling of unicode character \U00010900

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Hmmm, digging deeper, I saved the page source code and opened it with 
hexdump. The relevant lines are:

7780  60 60 0d 0a 26 67 74 3b  26 67 74 3b 26 67 74 3b  |``..>>>|
7790  20 73 20 3d 20 27 30 f0  90 a4 80 30 30 27 0d 0a  | s = '000'..|

which looks like Eryk Sun is correct, what is really there is '0X00' and 
Firefox just displays it in RTL order '000X'.

Mystery solved :-)

So now that only leaves the (unreproduced?) bug report of the difference 
in order between indexing and list(). Max, are you still certain that 
this difference exists? Can you replicate it with other strings, 
preferably with distinct characters?

--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Jack O'Connor]

Jack O'Connor  added the comment:

Hi Michał, no I haven't done any more work on this since my comments back in 
April. If you wanted to get started on a PyPI implementation, I think that 
would be fantastic. I'd be happy to collaborate over email: 
oconnor...@gmail.com. The branches I linked are still up, but I'm not sure my 
code will be very useful to someone who actually knows what they're doing :) 
Larry also had several ideas about how multithreading could fit in (which would 
be API changes in the Rust case, and forward-looking design work in the C 
case), and if I get permission from Larry I'll forward those emails.

--

___
Python tracker 

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

[issue45100] Teach help about typing.overload()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> The two @overload definitions will be overwritten by 
> the non-overload one at runtime, and hence will ever 
> been seen by help().

We can fix this by adding an __overloads__ attribute.  The overload decorator 
can accumulate the chain in an external namespace and function creation can 
move that accumulation into the new attribute.

- Proof of concept -

from typing import Union, _overload_dummy

def create_function(func):
namespace = func.__globals__
key = f'__overload__{func.__qualname__}__'
func.__overloads__ = namespace.pop(key, [])
return func

def overload(func):
namespace = func.__globals__
key = f'__overload__{func.__qualname__}__'
namespace[key] = func.__overloads__ + [func.__annotations__]
return _overload_dummy

class Smudge(str):

@overload
@create_function
def __getitem__(self, index: int) -> str:
...

@overload
@create_function
def __getitem__(self, index: slice) -> 'Smudge':
...

@create_function
def __getitem__(self, index: Union[int, slice]) -> Union[str, 'Smudge']:
'Return a smudged character or characters.' 
if isinstance(index, slice):
start, stop, step = index.indices(len(self))
values = [self[i] for i in range(start, stop, step)]
return Smudge(''.join(values))
c = super().__getitem__(index)
return chr(ord(c) ^ 1)

@create_function
def other_method(self, x:str) -> tuple:
pass

print(f'{Smudge.__getitem__.__annotations__=}')
print(f'{Smudge.__getitem__.__overloads__=}')
print(f'{Smudge.other_method.__annotations__=}') 
print(f'{Smudge.other_method.__overloads__=}')

--

___
Python tracker 

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

[issue45100] Improve help() by making typing.overload() information accessible at runtime

[Raymond Hettinger]

Change by Raymond Hettinger :


--
title: Teach help about typing.overload() -> Improve help() by making 
typing.overload() information accessible at runtime
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

[issue45105] Incorrect handling of unicode character \U00010900

[Max Bachmann]

Max Bachmann  added the comment:

As far as a I understood this is caused by the same reason:

```
>>> s = '123\U00010900456'
>>> s
'123𐤀456'
>>> list(s)
['1', '2', '3', '𐤀', '4', '5', '6']
# note that everything including the commas is mirrored until ] is reached
>>> s[3]
'𐤀'
>>> list(s)[3]
'𐤀'
>>> ls = list(s)
>>> ls[3] += 'a'
>>> ls
['1', '2', '3', '𐤀a', '4', '5', '6']
```

Which as far as I understood is the expected behavior when a right-to-left 
character is encountered.

--

___
Python tracker 

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

[issue45107] Improve LOAD_METHOD specialization

[Ken Jin]

New submission from Ken Jin :

I plan to do two improvements over the initial implementation:

1. General comments cleanup and optimize LOAD_METHOD_CLASS.

2. Implement LOAD_METHOD_SUPER, for super().meth() calls.

See Issue44889 for the precursor.

--
components: Interpreter Core
messages: 401096
nosy: kj
priority: normal
severity: normal
status: open
title: Improve LOAD_METHOD specialization
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

[issue45107] Improve LOAD_METHOD specialization

[Ken Jin]

Change by Ken Jin :


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

___
Python tracker 

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

[issue45100] Improve help() by making typing.overload() information accessible at runtime

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Note, I'm not proposing a create_function() decorator.  That is just for the 
proof of concept.  The actual logic would go into normal function creation, the 
same place that __annotations__ gets added.

Also, there may be a better place than func.__globals__ to accumulate the 
overloads.  For the proof-of-concept, it was just the easiest way to go.

--

___
Python tracker 

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

[issue45108] frame.f_lasti points at DICT_MERGE instead of CALL_FUNCTION_EX in Windows only

[Alex Hall]

New submission from Alex Hall :

In this script:

import inspect
import dis

def foo(**_):
frame = inspect.currentframe().f_back
print(frame.f_lasti)
dis.dis(frame.f_code)

d = {'a': 1, 'b': 2}
foo(**d)

dis shows these instructions for `foo(**d)`:

 10  34 LOAD_NAME2 (foo)
 36 BUILD_TUPLE  0
 38 BUILD_MAP0
 40 LOAD_NAME3 (d)
 42 DICT_MERGE   1
 44 CALL_FUNCTION_EX 1
 46 POP_TOP
 48 LOAD_CONST   1 (None)
 50 RETURN_VALUE

On Linux/OSX, frame.f_lasti is 44, pointing to the CALL_FUNCTION_EX as I'd 
expect.

But on Windows it's 42, which is the preceding instruction DICT_MERGE.

The bytecode itself is identical on the different systems, it's just the frame 
offset that differs.

This manifested as a test failure in a debugging tool here: 
https://github.com/samuelcolvin/python-devtools/pull/93

--
components: Interpreter Core, Windows
messages: 401098
nosy: alexmojaki, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: frame.f_lasti points at DICT_MERGE instead of CALL_FUNCTION_EX in 
Windows only
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

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

[issue45034] Improve struct.pack out of range error messages

[Nikita Sobolev]

Change by Nikita Sobolev :


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

___
Python tracker 

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

[issue1705520] API for excluding methods from unittest stack traces

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What to do with comprehensions and classes? Corresponding code objects are not 
easily accessible and they do not have corresponding function. It would be 
difficult to use the locals of the frame with comprehensions.

Maybe use per-module registries of qualnames?

class MyAssertions:
def assertComplexState(self, inputs):
self.assertEqual('42', inputs[0], 'the input %s is not the right 
answer' % inputs)

__unittests = {'MyAssertions.assertComplexState'}

The frame is skipped if f_globals['__unittests'] contains co_qualname or any 
parents of co_qualname.

We can even add a decorator:

def assertion(func):
mod = sys.modules[func.__module__]
mod.__dict__.setdefault('__unittests', set())
mod.__setdefault.add(func.__qualname__)
return func

--
nosy: +serhiy.storchaka
versions: +Python 3.11 -Python 3.4

___
Python tracker 

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

[issue45108] frame.f_lasti points at DICT_MERGE instead of CALL_FUNCTION_EX in Windows only

[Samuel Colvin]

Samuel Colvin  added the comment:

Perhaps worth adding that the tests don't fail on python 3.6, 3.7 or 3.8.

--
nosy: +samuelcolvin

___
Python tracker 

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

[issue25894] unittest subTest failure causes result to be omitted from listing

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Any suggestions for the format of output? Currently PR 28082 formats lines for 
subtest skipping, failure or error with a 2-space identation. Lines for 
skipping, failure or error in tearDown() or functions registered with 
addCallback() do not differ from a line skipping, failure or error in the test 
method itself.

I am not sure about backporting this change. On one hand, it fixes an old flaw 
in the unittest output. On other hand, the change affects not only subtests and 
can confuse programs which parse the unittest output because the test 
descriptions can occur multiple times.

--
versions: +Python 3.11 -Python 3.5, Python 3.6

___
Python tracker 

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

[issue30856] unittest.TestResult.addSubTest should be called immediately after subtest finishes

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 4.0 -> 5.0
pull_requests: +26606
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28180

___
Python tracker 

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

[issue30856] unittest.TestResult.addSubTest should be called immediately after subtest finishes

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Before b3468f79efa45c8adaf86c0b9b797b9b3d4c12a2 the TestResult methods 
(addFailure, addError, addSkip, addExpectedFailure, addUnexpectedSuccess) were 
called immediately after running the test method. After that change all skips, 
failures and errors were accumulated separately and TestResult was updated only 
after the test cleanup. I do not know whether there were reasons for this or it 
is just an implementation artifact.

The proposed PR makes addFailure, addError, addSkip and addSubTest be called 
immediately after raising an exception or finishing a subtest. 
addExpectedFailure, addUnexpectedSuccess and addSuccess still need to wait the 
end of the test cleanup.

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

[issue45109] pipes seems designed for bytes but is str-only

[Richard Tollerton]

New submission from Richard Tollerton :

1. https://github.com/python/cpython/blob/3.9/Lib/pipes.py#L6

> Suppose you have some data that you want to convert to another format,
> such as from GIF image format to PPM image format.

2. https://docs.python.org/3.9/library/pipes.html

> Because the module uses /bin/sh command lines, a POSIX or compatible shell 
> for os.system() and os.popen() is required.

3. https://docs.python.org/3.9/library/os.html#os.popen

> The returned file object reads or writes text strings rather than bytes.


(1) and (3) are AFAIK mutually contradictory: you can't reasonably expect to 
shove GIFs down a str file object. I'm guessing that pipes is an API that never 
got its bytes API fleshed out?

My main interest in this is that I'm writing a large CSV to disk and wanted to 
pipe it through zstd first. And I wanted something like perl's open FILE, 
"|zstd -T0 -19 > out.txt.zst". But the CSV at present is all bytes. 
(Technically the content is all latin1 at the moment, so I may have a 
workaround, but I'm not 100% certain it will stay that way.)

What I'd like to see is for pipes.Template.open() to accept 'b' in flags, and 
for that to be handled in the usual way.

--
components: Library (Lib)
messages: 401103
nosy: rtollert
priority: normal
severity: normal
status: open
title: pipes seems designed for bytes but is str-only
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

[issue35741] unittest.skipUnless(time._STRUCT_TM_ITEMS == 11, "needs tm_zone support") doesn't work

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

_STRUCT_TM_ITEMS was always set to 11 since issue25283.

On what platform test_localtime_timezone fails now?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue36674] "unittest.TestCase.debug" should honour "skip" (and other test controls)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are too many issues with TestResult.debug(). It does not call tearDown() 
and doCleanups() if the test is skipped, failed or raises other exception 
(including errors in cleanup). It does not support skipping decorators. It does 
not support the expectedFailure decorator. It does not work at all in 
IsolatedAsyncioTestCase.

--

___
Python tracker 

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

[issue44848] Upgrade macOS and Windows installers to use SQLite 3.36.0

[Ned Deily]

Ned Deily  added the comment:


New changeset 5024dc1c6e08247693aea6ad6e225ec5dcaf0721 by Erlend Egeberg 
Aasland in branch 'main':
bpo-44848: Update macOS installer to use SQLite 3.36.0 (GH-27621)
https://github.com/python/cpython/commit/5024dc1c6e08247693aea6ad6e225ec5dcaf0721


--

___
Python tracker 

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

[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

[Benjamin Szőke]

Benjamin Szőke  added the comment:

Can you review my final implementation?
https://github.com/python/cpython/pull/28111

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

[issue39355] The Python library will not compile with a C++2020 compiler because the code uses the reserved “module” keyword

[Keith]

Keith  added the comment:

the word "module" should be treated as a reserved keyword.

Any use of "module" as an argument name should be changed to something else
throughout the code base.

On Fri, Aug 20, 2021 at 11:28 PM Hasan  wrote:

>
> Hasan  added the comment:
>
> We have tested with cxx-modules that issue.
> module is just a specifier for export (only export is a compiler-based
> keyword in >= C++20)
> That's why we can use module as argument name and there's no need to
> rename or delete *module arguments from header files.
>
> What do you recommend to do?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1103r3.pdf
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

New submission from Forest :

When argparse actions have multiple option strings and at least one argument, 
the default formatter presents them like this:

  -t ARGUMENT, --task ARGUMENT
Perform a task with the given argument.
  -p STRING, --print STRING
Print the given string.

By repeating the metavars, the formatter wastes horizontal space, making the 
following side-effects more likely:

- The easy-to-read tabular format is undermined by overlapping text columns.
- An action and its description are split apart, onto separate lines.
- Fewer actions can fit on the screen at once.
- The user is presented with extra noise (repeat text) to read through.


I think the DRY principle is worth considering here. Help text would be 
cleaner, more compact, and easier to read if formatted like this:

  -t, --task ARGUMENT   Perform a task with the given argument.
  -p, --print STRINGPrint the given string.

Obviously, actions with especially long option strings or metavars could still 
trigger line breaks, but they would be much less common and still easier to 
read without the repeat text.


I am aware of ArgumentParser's formatter_class option, but unfortunately, it is 
of little help here.  Since the default formatter class reserves every stage of 
its work as a private implementation detail, I cannot safely subclass it to get 
the behavior I want.  My choices are apparently to either re-implement an 
unreasonably large swath of its code in my own formatter class, or override the 
private _format_action_invocation() method in a subclass and risk future 
breakage (and still have to re-implement more code than is reasonable.)

Would it make sense to give HelpFormatter a "don't repeat yourself" option?  
(For example, a boolean class attribute could be overridden by a subclass and 
would be a small change to the existing code.)

Alternatively, if nobody is attached to the current behavior, would it make 
sense to simply change HelpFormatter such that it never repeats itself?

--
components: Library (Lib)
messages: 401110
nosy: forest
priority: normal
severity: normal
status: open
title: argparse repeats itself when formatting help metavars
type: behavior
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

[issue45110] argparse repeats itself when formatting help metavars

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +paul.j3, rhettinger

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I don't agree this should be changed.  The repetition helps improve 
understanding because not everyone would assume that a METAVAR shown once would 
automatically also apply to its long form.   

Also, showing the METAVAR more than one is a norm.  For example, see this 
excerpt from "man grep":

 -B num, --before-context=num
 Print num lines of leading context before each match.  See also 
the -A and -C options.

 -b, --byte-offset
 The offset in bytes of a matched pattern is displayed in front of 
the respective matched line.

 -C[num, --context=num]
 Print num lines of leading and trailing context surrounding each 
match.  The default is 2 and is equivalent to
 -A 2 -B 2.  Note: no whitespace may be given between the option 
and its argument.

 -c, --count
 Only a count of selected lines is written to standard output.

 --colour=[when, --color=[when]]
 Mark up the matching text with the expression stored in GREP_COLOR 
environment variable.  The possible values of
 when can be `never', `always' or `auto'.

 -D action, --devices=action
 Specify the demanded action for devices, FIFOs and sockets.  The 
default action is `read', which means, that
 they are read as if they were normal files.  If the action is set 
to `skip', devices will be silently skipped.

 -d action, --directories=action
 Specify the demanded action for directories.  It is `read' by 
default, which means that the directories are read
 in the same manner as normal files.  Other possible values are 
`skip' to silently ignore the directories, and
 `recurse' to read them recursively, which has the same effect as 
the -R and -r option.

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

[issue45110] argparse repeats itself when formatting help metavars

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Except that the output in question is not for manpages but for the 
command-line.  The analogous would be for `grep --help` (again an excerpt):

Context control:
  -B, --before-context=NUM  print NUM lines of leading context
  -A, --after-context=NUM   print NUM lines of trailing context
  -C, --context=NUM print NUM lines of output context
  -NUM  same as --context=NUM
  --color[=WHEN],
  --colour[=WHEN]   use markers to highlight the matching strings;
WHEN is 'always', 'never', or 'auto'

[using grep (GNU grep) 3.1]

--
nosy: +jkloth

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

Forest  added the comment:

On Mon, 06 Sep 2021 03:11:16 +, Raymond Hettinger wrote:

>The repetition helps improve understanding because not everyone would assume
>that a METAVAR shown once would automatically also apply to its long form.

I'm struggling to think of a real-world example that would lead someone to
think otherwise.  Is there a program with a short & long form option where
only one of those accepts an argument?

If such a thing does exist somewhere, the current behavior seems even worse
in that case: it shows the METAVAR alongside both forms, despite only one
form accepting an argument.

>Also, showing the METAVAR more than one is a norm.  For example, see this
>excerpt from "man grep":

I disagree about that being a norm. Counterexamples include:

cp -t, --target-directory=DIRECTORY
mv -S, --suffix=SUFFIX
ls -T, --tabsize=COLS
man -L, --locale=LOCALE

And, as Jeremy pointed out, we are not discussing man pages here, but
command line help text.  Even grep does it the way I suggest:

grep -e, --regexp=PATTERNS
grep -f, --file=FILE
grep -m, --max-count=NUM
(etc.)

More importantly, even if we do accept the current behavior as potentially
useful, do we really want Python's standard library to prescribe it?  Should
the application developer not be given an easy way for her program to
display cleaner, simpler, more space-efficient help text?

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

Forest  added the comment:

By the way, I would be happy to submit a patch, either to remove the repeat
text or to make it optional via an easily overridden class attribute.

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[paul j3]

paul j3  added the comment:

This is has been requested various times on StackOverflow, and possibly here 
(I'd have to do a search).

The closest thing to making a compact action_invocation is to set the metavar 
to '', and even thing we get a space, eg.

 -f , --foo   Help text

This repeat has been a part of argparse from the beginning, so I can't see 
changing the default behavior.  But we could add a HelpFormatter subclass that 
changes one (or two methods) such as _format_action_invocation.  Subclassing 
the formatter is the accepted way of adding help features.   I, and possibly 
others, must have suggested such a change on SO.

Of course people can use such a subclass without it being part of the standard 
module.

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[paul j3]

paul j3  added the comment:

https://bugs.python.org/issue42980 argparse: GNU-style help formatter

https://bugs.python.org/issue33389 argparse redundant help string

https://bugs.python.org/issue29626
Issue with spacing in argparse module while using help

https://bugs.python.org/issue27303
[argparse] Unify options in help output

https://stackoverflow.com/questions/23936145/python-argparse-help-message-disable-metavar-for-short-options

https://stackoverflow.com/questions/18275023/dont-show-long-options-twice-in-print-help-from-argparse

--

___
Python tracker 

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

[issue40512] [subinterpreters] Meta issue: per-interpreter GIL

[hai shi]

hai shi  added the comment:

> PyStructSequence_InitType2() is not compatible with subinterpreters: it uses 
> static types. Moreover, it allocates tp_members memory which is not released 
> when the type is destroyed. But I'm not sure that the type is ever destroyed, 
> since this API is designed for static types.

IMO, I suggest to create a new function, 
PyStructSequence_FromModuleAndDesc(module, desc, flags) to create a heaptype 
and don't aloocates memory block for tp_members,something like 
'PyType_FromModuleAndSpec()`.

I don't know there have any block issue to do this converting operation. But I 
can take a look.

@petr ping, Petr, do you have any better idea about this question :)

--
nosy: +petr.viktorin

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

Forest  added the comment:

On Mon, 06 Sep 2021 04:58:38 +, paul j3 wrote:

>This repeat has been a part of argparse from the beginning, so I can't
>see changing the default behavior.

Yes, I guessed as much, which is why I first suggested making it optional.

>But we could add a HelpFormatter subclass that changes one (or two methods)
>such as _format_action_invocation.  Subclassing the formatter is the accepted
>way of adding help features.

If it was done in a subclass, how would people be expected to get the new
behavior *and* that of the other subclasses?  For example, someone with
pre-formatted description and epilog text is currently directed to use the
RawDescriptionHelpFormatter subclass.  If they also wanted to avoid repeat
metavars, and that behavior was implemented in another subclass, would they
be expected to write a third subclass inheriting from both module-defined
subclasses?

To me, multiclassing seems rather heavyweight for a simple behavior change
like this one, but yes, I recognize that argparse's current code uses that
approach.  Pity, that.

>Of course people can use such a subclass without it being part of the
>standard module.

Technically: sure. But practically: not so much.  An application would have
to subclass and override _format_action_invocation(), which (judging by the
leading underscore) appears to be intended as private to the module.  Even
the module doc string says so:

"""
(Also note that HelpFormatter and RawDescriptionHelpFormatter are only
considered public as object names -- the API of the formatter objects is
still considered an implementation detail.)
"""

So, a subclass that isn't part of the standard module is implicity and
explicitly discouraged by the module itself.

If we're married to the module's current policy for formatter tweaks, I
guess that leaves a module-defined subclass as the only option.  Here is
an example that works:

class OneMetavarHelpFormatter(argparse.HelpFormatter):
"""A formatter that avoids repeating action argument metavars.
"""
def _format_action_invocation(self, action):
"Format action help without repeating the argument metavar"
if not action.option_strings or action.nargs == 0:
return super()._format_action_invocation(action)

default = self._get_default_metavar_for_optional(action)
args_string = self._format_args(action, default)
return ', '.join(action.option_strings) + ' ' + args_string

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

Forest  added the comment:

Here's another working example, allowing alternate separator strings (as
requested in #33389) via subclassing:

class OneMetavarHelpFormatter(argparse.HelpFormatter):
"""A formatter that avoids repeating action metavars.
"""
OPTION_SEPARATOR = ', '
METAVAR_SEPARATOR = ' '

def _format_action_invocation(self, action):
"""Format action help without repeating the argument metavar
"""
if not action.option_strings or action.nargs == 0:
return super()._format_action_invocation(action)

default = self._get_default_metavar_for_optional(action)
args_string = self._format_args(action, default)
options_string = self.OPTION_SEPARATOR.join(action.option_strings)
return options_string + self.METAVAR_SEPARATOR + args_string

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

Forest  added the comment:

To be clear, I wrote those examples to be non-invasive, not patch proposals.
A cleaner approach would be possible if patching argparse is an option.  (I
believe the patch in #42980 proposes such an approach.)

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[paul j3]

paul j3  added the comment:

The idea of combining help features by defining a subclass that inherits from 
other subclasses was endorsed by the original developer (we could dig up an old 
bug/issue to prove that).

The provided subclasses all tweak a "private" method, often one that's buried 
deep in the calling stack.

I can't quote any official policy, but my sense is that Python developers are 
ok with users subclassing and modifying "private" methods.  Methods, functions 
and classes (and variables) with leading '_' aren't documented, or imported via 
`__all__`, but otherwise the boundary between what is part of the user API and 
what's "hidden" is loose in Python.  

Apparently some corporate policies prohibit use or modification of things that 
aren't in the public API, but I don't think that policy protects you from 
changes.  'argparse' changes at a glacial rate, with a lot of concern for 
backward compatibility.  In fact it's that fear of unintended consequences that 
slows down the pace of change.  Subclassing a help formatter is preferred 
because it minimizes the chance of hurting existing users.

--

___
Python tracker 

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

[issue45110] argparse repeats itself when formatting help metavars

[Forest]

Forest  added the comment:

>Subclassing a help formatter is preferred because it minimizes the chance of 
>hurting existing users.

Fair enough.

Whatever the approach, I hope argparse can be made to support this through a
simple, documented interface.  I had to grovel through standard library code
to figure out what to override and what to duplicate in order to get the
output I want.  That seems like a needlessly high barrier for such a common
(and apparently oft-requested) format.

--

___
Python tracker 

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

[issue42238] Deprecate suspicious.py?

[Julien Palard]

Julien Palard  added the comment:


New changeset 37272f5800ee1e9fcb2da4a1766366519b9b3d94 by Julien Palard in 
branch 'main':
bpo-42238: [doc] remove unused, and deduplicate, suspicious ignore rules. 
(GH-28137)
https://github.com/python/cpython/commit/37272f5800ee1e9fcb2da4a1766366519b9b3d94


--

___
Python tracker 

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