[issue40780] str.format() handles trailing zeros inconsistently in “general” format

2020-05-26 Thread David Chambers

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

2013-11-10 Thread David Chambers

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

2013-10-12 Thread David Chambers

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

2013-10-05 Thread David Chambers

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

2010-04-01 Thread David Chambers

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