Mark Dickinson <dicki...@gmail.com> added the comment:
Thanks for the report. I think most of this is a documentation issue: we either need to make clear that the formatting documentation applies only to the float type and that Decimal follows its own rules (usually for good reason, namely that it's required to follow Mike Cowlishaw's General Decimal Arithmetic Specification), or adjust the main string formatting documentation to make sure it covers the Decimal type as well as float. Michael: thank you for including both the _pydecimal and decimal results here. Just to double check, I'm not seeing any differences between just those two here (other than the exact exception messages); are you seeing differences just between those two types that you think shouldn't exist? In more detail: Cases 1-2: these look like a documentation issue. The decimal behaviour is definitely desirable here: when possible, we want the string representation to preserve the information about the decimal exponent. Case 3: This looks like a bug in the float formatting to me: the "0" prefix for the width implies "=" for the alignment, which conflicts with the explicit ">". But making something that previously worked a ValueError is hazardous; perhaps we can accept that in this case the explicitly-given alignment overrides the implicit "=", and modify decimal accordingly. Case 4: This is a weaker case than case 3, where the implicit alignment matches the explicitly given one; I think we should fix decimal to accept this, since there's no ambiguity. Case 5: Same reasoning as case 4: let's fix decimal. Case 6: Like case 3: there's a conflict between the implicit fill of "0" and the explicitly given fill of " ". Again, it seems reasonable to let the explicit win over the implicit here. Case 7: like case 3 and case 6 combined; if we fix those, we might as well also fix this one for consistency, even though at that point the "0" prefix for the width is doing nothing at all. Cases 8-10: the space in case 8 isn't being interpreted as a fill character here; it's being interpreted as the sign character. I don't think there's anything to fix for these cases. Cases 11-12: I don't think there's anything to be fixed here: yes, padding on the right with zeros creates misleading results, but I don't think it's Python's job to prevent the user from doing that. Case 13: This is a doc issue; that ---------- nosy: +facundobatista, rhettinger, skrah _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39077> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
