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 terry.reedy
Recipients eric.smith, georg.brandl, mark.dickinson, terry.reedy
Date 2009-05-08.01:37:37
SpamBayes Score 1.1657342e-15
Marked as misclassified No
Message-id <1241746659.03.0.695063574208.issue5963@psf.upfronthosting.co.za>
In-reply-to
Content
Whoops, I believe my suggested replacement.
"A precision is not allowed for integer values."
should really be
"A precision is not allowed for integer presentation types."
or something similar.

If you did not change the end of the sentence, please do.  A precision 
*is* allowed for integer values (integers) if a float presentation type
is used, because they are auto-converted (though floats are not).

This is not documented but I think it should be.  See #5965 for this and
related suggestions.

For future reference, in case anyone ever objects, I agree with
remaining strict and changing the doc.
1) Given that the code is strict about the other 'only valid'
restrictions (I checked some and it seems to be), it seems reasonable to
be consistency strict with precision and ints also.
2) Given that there are 7 presentation types for int and 8 for floats,
it is easily possible to make an error.  Best to catch it early.

The only possible use case I can think of for precision with ints is
something like
'{0:10.3{1}}'.format(val, typ) # fails for int typs

but we fail-proof that, we should also fail-proof '#' with floats:
'{0:#10{1}}'.format(val, typ)# fails for float typs
History
Date User Action Args
2009-05-08 01:37:39terry.reedysetrecipients: + terry.reedy, georg.brandl, mark.dickinson, eric.smith
2009-05-08 01:37:39terry.reedysetmessageid: <1241746659.03.0.695063574208.issue5963@psf.upfronthosting.co.za>
2009-05-08 01:37:38terry.reedylinkissue5963 messages
2009-05-08 01:37:37terry.reedycreate