[issue40780] str.format() handles trailing zeros inconsistently in “general” format
New submission from David Chambers :
According to
https://docs.python.org/3/library/string.html#format-specification-mini-language,
“insignificant trailing zeros are removed from the significand” when 'g' is
specified. I encountered a situation in which a trailing zero is not removed:
$ python3
Python 3.7.7 (default, Mar 10 2020, 15:43:03)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{0:.3g}'.format(1504)
'1.5e+03'
>>> '{0:.3g}'.format(1505)
'1.50e+03'
>>> '{0:.3g}'.format(1506)
'1.51e+03'
Is this behaviour intentional? If so, why is the trailing zero in 1.50
considered significant for 1505 but insignificant for 1504?
--
messages: 369983
nosy: davidchambers
priority: normal
severity: normal
status: open
title: str.format() handles trailing zeros inconsistently in “general” format
type: behavior
___
Python tracker
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19238] Misleading explanation of fill and align in format_spec
David Chambers added the comment: These commits contain a typo: s/preceeded/preceded/ -- ___ Python tracker <http://bugs.python.org/issue19238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19238] Misleading explanation of fill and align in format_spec
New submission from David Chambers:
>From http://docs.python.org/3/library/string.html#formatspec:
> The presence of a fill character is signaled by the character
> following it, which must be one of the alignment options. If the
> second character of format_spec is not a valid alignment option,
> then it is assumed that both the fill character and the alignment
> option are absent.
The fact that the second character in the format_spec is not an
alignment option is not sufficient to declare that the alignment
option is absent: the alignment option may be the first character
in the format_spec. For example:
>>> '{:^10}'.format(42)
'42'
I suggest the following wording:
The presence of a fill character is signaled by the character
following it, which must be one of the alignment options. Unless
the second character of format_spec is a valid alignment option,
the fill character is assumed to be absent.
--
assignee: docs@python
components: Documentation
messages: 199633
nosy: davidchambers, docs@python
priority: normal
severity: normal
status: open
title: Misleading explanation of fill and align in format_spec
___
Python tracker
<http://bugs.python.org/issue19238>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19175] Erroneous reference to "integer" in format string grammar
New submission from David Chambers:
I first raised this issue on Stack Overflow:
http://stackoverflow.com/questions/19203194
The [replacement field grammar][1] states that an [integer][2] is a valid
field_name, but this is inaccurate:
>>> '{0}'.format('zero')
'zero'
>>> '{0x0}.format('zero')
KeyError: '0x0'
>>> '{0o0}.format('zero')
KeyError: '0o0'
>>> '{0b0}.format('zero')
KeyError: '0b0'
This [comment][3] by Eric Smith suggests that the above is the intended
behaviour:
> get_integer uses the narrowest possible definition for integer indexes,
> in order to pass all other strings to mappings.
The documentation should be updated to match the actual behaviour. abarnert on
Stack Overflow suggested the following change:
-arg_name ::= [identifier | integer]
+arg_name ::= [identifier | digit+]
[1]: http://docs.python.org/2/library/string.html#format-string-syntax
[2]:
http://docs.python.org/2/reference/lexical_analysis.html#grammar-token-integer
[3]: http://bugs.python.org/issue8985#msg107705
--
assignee: docs@python
components: Documentation
messages: 199024
nosy: davidchambers, docs@python
priority: normal
severity: normal
status: open
title: Erroneous reference to "integer" in format string grammar
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue19175>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7132] Regexp: capturing groups in repetitions
David Chambers added the comment:
I would find this functionality very useful. While I agree that it's often
simpler to extract the relevant information in several steps, there are
situations in which I'd prefer to do it all in one go.
The application I'm writing at the moment needs to extract metadata from text
files. This metadata actually appears as text at the top of each file. For
example:
title: Example title
tags: Django, Python, regular expressions
Example title
=
Here is the first paragraph.
I had expected something like this to get the job done:
meta = re.match(r'(?ms)(?:^(\S+):\s*(.*?)$\n)+^\s*$', contents_of_file)
Ideally in this case, meta.groups() would return:
('title', 'Example title', 'tags', 'Django, Python, regular expressions')
--
nosy: +davidchambers
___
Python tracker
<http://bugs.python.org/issue7132>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
