This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author aubmoon
Recipients aubmoon, ned.deily
Date 2014-03-01.00:48:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAM8Gk7q6-UCyL2S7viXMQKMJg2qOKQcyDDKidG9BwcAUiZP4Kw@mail.gmail.com>
In-reply-to <1393626724.02.0.301898191611.issue20811@psf.upfronthosting.co.za>
Content
Admittedly maximum is not correct; however, minimum is not right either.
The 10 is the desired (or target) width. Fixed width prints are commonly
used with very legacy systems that die a painful death when fixed width
strings are parsed by index and a field has spilled over a column. The
point is that the format returns a string that is longer than the desired
length when a perfectly valid version meets both the format and desired
length (making it more correct). The desired length should only be exceeded
when no solutions can be found. Note the below statement parses without
error. For this reason I feel this is a valid but minor issue. By using a
regular expression or slicing the desired result can be achieved, but with
extra code.
Thanks for the quick response!

-Mark

>>> float('+.12345678')

On Friday, February 28, 2014, Ned Deily <report@bugs.python.org> wrote:

>
> Ned Deily added the comment:
>
> I think you are misunderstanding the meaning of the width component (e.g.
> the 10 in your example) of a format specification.  As described in the
> documentation, width is a decimal integer defining the *minimum* field
> width, not the *maximum* field width.  As necessary, the generated field
> will be as long as necessary to represent the item as requested by the
> format spec, but it will be at least "width" characters long.
>
>
> http://docs.python.org/3.3/library/string.html#format-specification-mini-language
>
> ----------
> nosy: +ned.deily
> resolution:  -> invalid
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue20811>
> _______________________________________
>
History
Date User Action Args
2014-03-01 00:48:53aubmoonsetrecipients: + aubmoon, ned.deily
2014-03-01 00:48:53aubmoonlinkissue20811 messages
2014-03-01 00:48:53aubmooncreate