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
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