After merging#107 the tests now pass.

Hey@wnienhaus , tested with the ulp programs on my s2, and had no issues 👍

Specifying base 0 was not a solution, as this resulted in parsing behaviour different from GNU as.

I guess the simplest fix here would be to just replaceint(x) withint(x, 0). That should restore the existing behaviour. But it looks like you want to improve things further, which is great!

Yes,int(x, 0) would have restored the previous behaviour, but it wasn't the behaviour we needed. Of course it wasn't the behaviour we needed even before, so this PR technically fixes 2 things - adapt to the new MicroPython behaviour and fix parsing behaviour to match GNU as.

That said, sinceint(x, 0) exists, and because it's really just octal parsing we need extra, I just tried this simpler approach:

defparse_int(literal):iflen(literal)>2:prefix_start=1ifliteral[0]=='-'else0# skip over negative sign if presentifliteral[prefix_start]=='0'andliteral[prefix_start+1]in'123456789':returnint(literal,8)returnint(literal,0)

and all tests still pass.

So it's really just the octal case that's different (and theoretically we should disallow python style octal (0b..), but I had already decided to support it).

Now I am starting the overthink this:

• what is better for clarity and/or long-term stability? To handle all cases we support explicitly (as I am doing now)? Or to just handle the extra octal case we need?
• I see very little performance difference, and the shorter code saves perhaps a few bytes of memory, but it's probably not worth quibbling over.

I think I'll keep the current approach, as it's very explicit about what we support (including explicitly supporting python style octal). I'll just remove the comment about legacy octal format, because from the GNU as perspective, it's the currently valid and only possible octal format.

(Happy to get feedback on my chosen approach)

Ok. Fixes pushed. Will squash-merge this once approved.

That said, sinceint(x, 0) exists, and because it's really just octal parsing we need extra, I just tried this simpler approach:

IMO that's quite a bit simpler and easier to read/understand. I would vote for this approach.

Or a little simpler still:

defparse_int(literal):iflen(literal)>=2andliteral.startswith(("0","-0"))andliteral.lstrip("-0").isdigt():returnint(literal,8)returnint(literal,0)

Note: I think you need the>= 2 to cover cases like07.

Thanks for that feedback. Shorter is nice, so let's go with that. MicroPython'sstartswith does not support multiple values (tuple), so I expanded that into two separate conditions.

The>=2 is indeed needed in the shorter version of the code (both yours and also my earlier test code - well spotted). In the previous longer version all<=2 cases were also valid decimal, so they worked fine via the fall-through case.

I added some extra tests to show more cases that (should) work as expected, e.g.07 as you mentioned. I also noticed, my short version did not handle000010 correctly, i.e. octal with extra zero padding. GNU as understands that as decimal 8. My long parsing code worked correctly for that case, but my short version did not.

Anyway, your proposed code handles all cases correctly, so I used it now. And now there are tests to verify they all work as intended.

Thanks.

MicroPython'sstartswith does not support multiple values (tuple), so I expanded that into two separate conditions.

Ah, it will in the next release! But in the interest of backwards compatibility, best not to rely on that yet.

Anyway, your proposed code handles all cases correctly, so I used it now. And now there are tests to verify they all work as intended.

Very good!

Force-pushed after squashing the commits. Will merge next.