[issue43624] Add underscore as a decimal separator for string formatting
Terry Davis added the comment: If no one else has any comments, I'll assume there is consensus and start working on this. I have not contributed to CPython before, nor have I worked on production C code, so it may be a while before I get anywhere. -- versions: +Python 3.11 -Python 3.10 ___ Python tracker <https://bugs.python.org/issue43624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43624] Add underscore as a decimal separator for string formatting
Terry Davis added the comment: Current behavior: >>> format(1234.1234, '_f') '1_234.123400' >>> format(1234.1234, ',f') '1,234.123400' New behavior: >>> format(1234.1234, ',._f') '1,234.123_400' >>> format(1234.1234, '_._f') '1_234.123_400' >>> format(1234.1234, '._f') '1234.123_400' >>> format(1234.1234, '._4f') '1234.123_4' >>> format(1234.1234, '.f') # still not allowed '1234.123_4' >>> format(1234.1234, '_.f') # still not allowed -- ___ Python tracker <https://bugs.python.org/issue43624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43624] Add underscore as a decimal separator for string formatting
Terry Davis added the comment: Victor, > '_.f' would be the same as '_f'? No, the example in my original post is wrong, '_.f' isn't allowed now. The proposal should use '_f' to describe the current behavior. > Should "._f" be allowed to only add underscores in the fractional part? (for > consistency?) Yes, but not for consistency with the above usage, instead it's so both fractional and integral underscores can be specified on their own. Here is my attempt at updating the format spec. The only problem I have with it is that it allows a naked '.'; I don't know how to specify "dot must be followed by one or both of 'float_grouping' and 'precision'". Current: format_spec ::= [[fill]align][sign][#][0][width][grouping_option][.precision][type] Proposed: format_spec ::= [[fill]align][sign][#][0][width][grouping_option][.[float_grouping][precision]][type] fill::= align ::= "<" | ">" | "=" | "^" sign::= "+" | "-" | " " width ::= digit+ grouping_option ::= "_" | "," float_grouping ::= "_" precision ::= digit+ type::= "b" | "c" | "d" | "e" | "E" | "f" | "F" | "g" | "G" | "n" | "o" | "s" | "x" | "X" | "%" -- ___ Python tracker <https://bugs.python.org/issue43624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43624] Add underscore as a decimal separator for string formatting
Terry Davis added the comment: Good point Victor, though I wonder how likely it is that a person using 3.10 would only use this particular new feature, and have an otherwise backwards-compatible codebase. This isn't something that I asked about out of necessity, and there hasn't been any other discussion of this idea that anyone can remember. On the other hand, I suppose it would be possible to have a feature flag that can be used to disable decimal underscores in 3.10 to prevent test failures. Just spitballing... -- ___ Python tracker <https://bugs.python.org/issue43624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43624] Add underscore as a decimal separator for string formatting
New submission from Terry Davis : Proposal: Enable this >>> format(12_34_56.12_34_56, '_._f') '123_456.123_456' Where now only this is possible >>> format(12_34_56.12_34_56, '_.f') '123_456.123456' Based on the discussion in the Ideas forum, three core devs support this addition. https://discuss.python.org/t/add-underscore-as-a-thousandths-separator-for-string-formatting/7407 I'm willing to give this a try if someone points me to where to add tests and where the float formatting code is. This would be my first CPython contribution. The feature freeze for 3.10 is 2021-05-03. https://www.python.org/dev/peps/pep-0619/#id5 -- components: Interpreter Core messages: 389508 nosy: Terry Davis priority: normal severity: normal status: open title: Add underscore as a decimal separator for string formatting type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41231] Type annotations lost when using wraps by default
Terry Davis added the comment: I don't understand this use-case, but would it make sense to `ChainMap` the wrapper's __annotations__ on top of the wrapped __annotations__? -- nosy: +Terry Davis ___ Python tracker <https://bugs.python.org/issue41231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40012] Avoid Python 2 documentation to appear in Web search results
Terry Davis added the comment: It seems like using "noindex" to tell search engines not to look at Python 2 docs at all would have the side-effect of breaking Python 2 documentation searches. I have gotten into the habit of searching for "python 3" explicitly, which I think is a reasonable work-around. Especially since python 2 and 3 could be considered different languages. ------ nosy: +Terry Davis ___ Python tracker <https://bugs.python.org/issue40012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
Terry Davis added the comment: I'd like to re-raise this issue. Should I cross-post to "discuss.python.org - Ideas"? -- nosy: +Terry Davis ___ Python tracker <https://bugs.python.org/issue12782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36591] Should be a typing.UserNamedTuple
New submission from Terry Davis : There should be a builtin alias for `Type[NamedTuple]` so that library authors user-supplied `NamedTuple`s can properly type-check their code. Here's a code sample that causes an issue in my IDE (PyCharm) from typing import NamedTuple, Type def fun(NT: NamedTuple, fill): # Complains that NamedTuple is not callable nt = NT(*fill) return nt UserNamedTuple = Type[NamedTuple] def fun(NT: UserNamedTuple, fill): # No complaints nt = NT(*fill) return nt This could just be an issue with PyCharm (I don't use mypy), but the correct to annotate this is with a Type[NamedTuple], so I hope mypy et. al. wouldn't this as a special case... -- components: Library (Lib) messages: 339893 nosy: Terry Davis priority: normal severity: normal status: open title: Should be a typing.UserNamedTuple type: enhancement ___ Python tracker <https://bugs.python.org/issue36591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
