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

[Jon Ribbens]

On 2018-05-10, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> This whole thread is reminding me PHP 2, which would magically treat
>> the second parameter of ChMod() as octal, because clearly if weak
>> typing is good then *no* typing must be best of all!
>>
>>   ChMod($filename, 644); // second parameter is actually 420 base 10
>
> Bear in mind that Unix file modes are traditionally written in octal,
> because they have no meaning as numbers. They're more like
> enumerations, or bitfields. The second parameter happens to be equal
> to the base 10 number 420, but that's completely useless. A file mode
> of 100644 means something; a file mode of 0x81a4 or 33188 decimal
> means nothing. PHP went for crazy magic there, but if the API had been
> built such that the "644" is passed as a string, it would have been
> completely sane and entirely useful.

Or indeed if it was passed as 0644 or 0o644 as an octal literal.
The issue is not *why* Rasmus did this - that's obvious - the issue is
that he didn't know why he *shouldn't* make a language where 1234 is a
decimal integer literal except sometimes it isn't. The PHP manual even
recommended that you write the second parameter as 0644 to "remind you"
that it was treated as octal, although the leading 0 made no actual
semantic difference to the way the code was parsed by the language.