Paul Ganssle <p.gans...@gmail.com> added the comment: > Still, this feature is not appealing enough to try to squeeze into 3.7 > release schedule. I think this should go through a round of discussion > either on datetime-sig or python-ideas.
Agreed. I will put together some summary in the next week or so and send it to one of those (probably python-ideas, I guess). > Why not start with that? Remember: python standard library is where code > goes to die. By implementing this feature in dateutil you will not be tied > to relatively slow python release schedule. Of course, you cannot change > datetime.now from a 3rd party module, but you can provide your own > dateutil.now with the desired features. This is sort of independent of whether it is implemented in `datetime`, but it's a bit more complicated than that. I have already, for example, implemented a `today()` utility that does what `datetime.today()` should do if it weren't leaking implementation details from how `date.today()` is implemented (i.e. gives you the current date at midnight), because I think that's a very common use. The reasons I brought this here are: 1. I would *prefer* it if what I implement is more or less in line with what is implemented in the standard library if a standard library solution is going to be provided so that my `dateutil` function is more of a version-independent backport than a "second way of doing things", so the direction that Python is going can inform how I choose to implement my `dateutil` backport. 2. The solution in `dateutil`, which provides functions and classes that manipulate `datetime`, will likely be different from how it is handled upstream, so it's worth having a discussion about what to do in the standard library - the standard library, for example, can overload existing operators on `datetime`, provide alternate constructors, or modify the arguments to existing alternate constructors. The semantics of this are somewhat different from a `dateutil` function that constructs a datetime (for example, there was a lot of discussion in `dateutil.utils.today` about what the function should be called - it would be cleanly namespaced if it were `datetime.today()`, but `today()` seems like it might return a `date`, etc). For something like this, where `dateutil` is acting more like `boltons` in that it is providing little convenience functions and extensions to the `datetime` library, I think it makes sense to see whether this might get an implementation upstream and what that implementation might look like upstream, even if what happens is that I go off and implement something similar in `dateutil` and we give it a year or two in `pip` to see what problems arise. I'll also note that even though `dateutil` has a less constrained release schedule and gets to backport features from later Python versions (allowing for earlier adoption), it's widely-used enough that I'm not very comfortable making backwards-incompatible releases. As a result, once an interface is released, it's more or less set, so it's more or less just as important to get this right in dateutil as it is in datetime. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32522> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
