Leading 0's syntax error in datetime.date module (Python 3.6)

[bartc]

On 11/05/2018 14:24, Chris Angelico wrote:
> On Fri, May 11, 2018 at 9:09 PM, bartc <bc at freeuk.com> wrote:

>>      when 101'11010'000'B then ...
>>
>> Try /that/ in hex /or/ octal.)
> 
> I've no idea what this is supposed to mean, or why you have groups of
> three, five, and three. Looks like a possible bug to me. I'm sure it
> isn't, of course, since you're one of those perfect programmers who
> simply doesn't _make_ errors, but if it were my code, I would be
> worried that it isn't correct somewhere.

The data-sheet for the 8087 numeric co-processor displays instructions 
of the two-byte opcodes in formats like this (high to low bits):

   [escape 1 0 1] [1 1 0 1 0 ST(i)]

'escape' is the 5-bit sequence 11011. ST(i) is a 3-bit register code. So 
considered as a one 16-bit value, it's divided into groups of 5:3:5:3. 
The escape sequence has already been detected, and the middle two groups 
have been isolated by masking with 111'11111'000B.

So it is checking for combinations of those middle 3:5 groups of bits in 
a way that exactly matches how it's presented in the data sheet. And 
this instruction encoding is still used in current AMD/Intel x64 processors.

The xxxxx-101-11010-xxx pattern corresponds to the FST ST(0) to ST(i) 
instruction:

     when 101'11010'000B then
         genstr("fst ")
         genstr(strfreg(freg))

It's not a bug. Just a good example of the use of binary where hex or 
octal doesn't cut it because the grouping isn't purely in threes or fours.

(I understand that binary literals were added to Python from version 
2.6. The question is why it took so long. They are not a heavyweight 
feature.)

> Cool. So what's the native integer size for the real world? Use that
> as your primary data type.
> 
> Oh, can't decide how many digits? That's a pity.

What's this got to do with octal? Because many languages impose a limit 
on the widths of numeric types, that somehow makes it OK to implement 
octal using leading zeros? Just to catch people out because octal is 
used so rarely.

> Go get a time machine. Spend some time in the 1980s. See what kinds of
> programming people were doing. HINT: It wasn't web app development.

I was doing lots of development in the 1980s. I just didn't use C.

> Yeah, which is why your personal pet language has approximately one
> user. The more things you change when you create a new language, the
> more likely that it'll be utterly useless to anyone but yourself.
> 
> Consistency is a lot more important than many people give it credit for.

That's why 0100 is sixty four in Python 2, and an error in Python 3? 
Instead of being one hundred in both, as common sense would have dictated.

And, for that matter, one hundred in any of my languages, some of which 
did have more than one user.

BTW here is one C-ism that /didn't/ make it into Python 1:

  print (0xE-1)

This prints 13 (0xE is 14, minus 1). But it would be an error in 
conforming C compilers:

    printf("%d", 0xE-1);

"error: invalid suffix "-1" on integer constant"

Perhaps consistency isn't always as important as you say, not for 
something which is crazily stupid.

At least 0xE-1 generates an error (on some compilers; on others, only 
years later when you switch compiler). 0100, if not intended as octal, 
is an undetectable error in C and Python 2.

-- 
bartc