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 <st...@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
