Irritation regarding the padding of the date in the startup text for Python

[PedanticHacker]

The startup text of Python 3.11.1 in a command-line interface produces the text like this (well, at least for me):

Python 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

Have you spotted the issue? Well, then you're not as pedantic as you think.

HINT: There a 2 spaces (instead of just 1) lurking in that text. There's a too big of a gap between Dec and 6, see? The date is not formatted properly, so the __DATE__ macro of C has a formatting issue.

Does anyone care to fix this?

And while you're at it, there's also a missing Oxford comma in Type "help", "copyright", "credits" or "license" for more information., so the text should be Type "help", "copyright", "credits", or "license" for more information..

[PedanticHacker]

Additional note: This date gap issue is only present in Python 3.11.1. No prior version of Python had this. So, this came with the micro release of Python 3.11.1.

[iritkatriel]

Please use meaningfully descriptive titles when reporting issues on the bug tracker.

[eryksun]

No prior version of Python had this.

Actually, it appears to be a consistent formatting problem for single-digit days of the month. For example, Python 3.10.1:

Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 18:54:59) [MSC v.1929 32 bit (Intel)] on win32
>>>

It's padded for two digits.

[PedanticHacker]

Ah, then you’re even more pedantic than me. I have only spotted this today after upgrading to Python 3.11.1 and starting it up in the command-line interface.

So, how can we fix this? It looks awful!

[eryksun]

there's also a missing Oxford comma in Type "help", "copyright", "credits" or "license" for more information., so the text should be Type "help", "copyright", "credits", or "license" for more information..

That's a matter of opinion and one's dialect of English. In British English, normally the serial comma is omitted after the penultimate word or phrase in a series. The conjunction between the last two items is enough to separate them.

[eryksun]

Py_GetBuildInfo() uses the standard __DATE__ macro. It's specified as follows:

The date of translation of the preprocessing translation unit: a character
string literal of the form "Mmm dd yyyy", where the names of the
months are the same as those generated by the asctime function, and the
first character of dd is a space character if the value is less than 10. If the
date of translation is not available, an implementation-defined valid date
shall be supplied.

Personally, I don't think it's something to worry about. Anything that uses __DATE__ will have the same formatting. It's not specific to Python.

[ericvsmith]

I agree this is not worth changing. And changing it may well break something that's expecting this format.

[PedanticHacker]

Well, then live with erroneous formatting. But it is obvious that this is unprofessional. When the format is such that it substitues a space for a non-existent value, that's bad formatting. It should at least prepend a 0 if it's a requirement that the value for a day in a date should include a 2-character integer. That way, no one's code would break even if they rely on a 2-character value for a day in a date.

Thoughts?

[PedanticHacker]

The specification for the __DATE__ macro in C is such that [...] the first character of dd is a space character if the value is less than 10, but I personally think that's bad. There should be a 0 as the padding character in the absence of the first character of dd. That's the standard way dates are written in formal texts. I'm not sure why C specifies it with a space.