[Python-ideas] Consistency in naming [was Re: ...ALL CAPS]

[Eric V. Smith]

On 2/2/2019 11:56 PM, James Lu wrote:
> 
> 
> Sent from my iPhone
> 
>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano <steve at pearwood.info> wrote:

>> Python has been around not quite 30 years now, so we can expect that it
>> will probably last another 30 years. But chances are not good that it
>> will be around in 300 years.
> 
> A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change.
> 
> This kind of readability issue, datetime.now, is an example of what’s contributing to Python’s decline.
> 
> Bottom line: if someone submits a PR for this, will anyone merge it?

I would not, and I don't think any other core dev would.

There should be one way to do things (insert quibbles about PEP 20 
here). I think it's detrimental to the language to introduce a new way 
of doing exactly the same thing that has existed for ages (maybe 
decades). And it would not be possible to remove the existing 
datetime.datetime.now without breaking tons of code, books, tutorials, 
Stack Overflow answers, etc.

I realize we disagree about this, and it frustrates you. But Python has 
a long history of not making gratuitous changes such as this. Maybe 
that's one reason it's so popular?

Besides: datetime.datetime.now is a pattern we use: classmethods that 
act as an alternate class constructor. There are tons of examples of 
this in the stdlib: pathlib.Path.home, factions.Fraction.from_float, and 
many, many others. These belong in the class that they return, not as a 
helper in the module.

There are plenty of things that annoy me about Python libraries. Some of 
them I even wrote. But we're not going to start changing things solely 
for style or consistency issues.

Eric