Sent from my iPhone
On Feb 2, 2019, at 3:41 AM, Steven D'Aprano<st...@pearwood.info> wrote:
On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovmöller wrote:
- the status quo means "no change", so there is no hassle there;
Not quite true. There is a constant hassle of "do I need to write
datetime.datetime.now() or datetime.now()?"
My point was that there is no hassle from *making a change* if you don't
actually make a change. (There may, or may not, be other, unrelated
hassles.)
Besides, I'm not seeing that this is any worse than any other import. Do
I call spam.Eggs.make() or Eggs.make()? If you don't remember what you
imported, the names don't make much difference.
I accept that datetime.datetime reads a bit funny and is a bit annoying.
If we had the keys to the time machine and could go back a decade to
version 3.0, or even further back to 1.5 or whenever the datetime module
was first created, it would be nice to change it so that the class was
DateTime. But changing it *now* is not free, it has real, serious costs
which are probably greater than the benefit gained.
Why can’t we put “now” as a property of the module itself, reccomend that, and
formally deprecate but never actually remove datetime.datetime.now?
I solved this at work by changing all imports to follow the "from
datetime import datetime" pattern and hard banning the other
statically in CI. But before that people suffered for years.
Oh how they must have suffered *wink*
I'm surprised that you don't do this:
from datetime import datetime as DateTime
I have a colleague who likes to point that the future is longer than
the past. It's important to keep that perspective.
Actually, no, on average, the projected lifespan of technologies,
companies and cultural memes is about the same as their current age. It
might last less, or it might last more, but the statistical expectation
is about the same as the current age. So on average, "the future" is
about the same as "the past".
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?
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:http://python.org/psf/codeofconduct/
