Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numbers with a fixed field width/precision are not parsed properly #107

Open
rgeorgiev583 opened this issue Mar 8, 2020 · 1 comment
Open
Labels

Comments

@rgeorgiev583
Copy link

rgeorgiev583 commented Mar 8, 2020

There are several issues with the parsing of numeric fields with a fixed width and/or precision. The common pattern for all of them is that the width/precision specification is applied inconsistently for different numeric representations (i.e. decimal, hexadecimal, etc):

>>> from parse import parse

>>> parse("#{:2.2x}{:2.2x}{:2.2x}", "#FFFFFF")
<Result (65535, 15, 15) {}>
>>> parse("#{:2.2x}{:2.2x}{:2.2x}", "#FFFF")
<Result (255, 15, 15) {}>
>>> parse("#{:2.2x}{:2.2x}{:2.2x}", "#FFF")
<Result (15, 15, 15) {}>
>>> parse("{:2.2d}{:2.2d}{:2.2d}", "9999")
<Result (99, 9, 9) {}>
>>> parse("{:2.2d}{:2.2d}{:2.2d}", "999")
<Result (9, 9, 9) {}>

As per the documentation: Width specifies a minimum size and precision specifies a maximum.
In all of the cases, we both have a width and a precision field. However, in the first case the parsing of the first number field consumes four hexadecimal digits despite the fact that the precision should specify a maximum field length. What is more, we also have a width specifier which says that the numbers should be at least two digits long, and yet the latter two numbers are represented using only one digit.
The rest of the cases demonstrate the same issue with the width specifier.

@r1chardj0n3s
Copy link
Owner

This is quite likely related to #99

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants