On Wednesday, October 25, 2017, Chris Barker <chris.bar...@noaa.gov> wrote:
> On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky < > alexander.belopol...@gmail.com > <javascript:_e(%7B%7D,'cvml','alexander.belopol...@gmail.com');>> wrote: > >> > times. The only difference is that instead of calling the type directly, >> > you call the appropriate classmethod. >> > >> > What am I missing? >> >> Nothing. The only annoyance is that the data processing code typically >> needs to know the type anyway, so the classmethod is one more variable >> to keep track of. > > > I don't think anyone is arguing that is is hard to do either way, or that > hard to use either way. > > I think it comes down to a trade-off between: > > Having an API for datetime that is like the datetime for number types: > > int(str(an_int)) == an_int > > so: > > datetime(str(a_datetime)) == a_datetime > > Alexander strongly supports that. > > Or an API that is perhaps more like the rest of the datetime api, which > has a number of alternate constructors: > > datetime.now() > > datetime.fromordinal() > > datetime.fromtimestamp() > > And has: > > datetime.isoformat() > > So a > > datetime.fromisoformat() > > would make a lot of sense. > > I would note that the number types don't have all those alternate > constructors Also, the number types mostly have a single parameter (except > int has an optional base parameter). So I'm not sure the parallel is that > strong. > > Would it be horrible if we did both? > > After all, right now, datetime has: > > In [16]: dt.isoformat() > Out[16]: '2017-10-25T16:30:48.744489' > > and > In [18]: dt.__str__() > Out[18]: '2017-10-25 16:30:48.744489' > > which do almost the same thing (I understand the "T" is option in iso 8601) > > However, maybe they are different when you add a time zone? > > ISO 8601 support offsets, but not time zones -- presumably the __str__ > supports the full datetime tzinfo somehow. Which may be why .isoformat() > exists. > ISO8601 does support timezones. https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators I might be wrong, but I think many of the third party libraries listed here default to either UTC or timezone-naieve timezones: https://github.com/vinta/awesome-python/blob/master/README.md#date-and-time Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it with my local time. Here's an example with a *custom* GMT1 tzinfo subclass: https://docs.python.org/3/library/datetime.html#datetime.time.tzname > Though I don't think that means you couldn't have the __init__ parse > proper ISO strings, in addition to the full datetime __str__ results. > What would you call the str argument? Does it accept strptime args or only ISO8601? Would all of that string parsing logic be a performance regression from the current constructor? Does it accept None or empty string? ... Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601)) types is nasty, regardless (try/except, *custom* schema awareness). And pickle is dangerous. AFAIU, we should not ever eval(repr(dt: datetime)). ... Should the date time constructor support nanos= (just like time_ns())? ENH: Add nanosecond support to the time and datetime constructors ... The astropy Time class supports a string argument as the first parameter sometimes: http://docs.astropy.org/en/stable/time/#inferring-input-format Astropy does support a "year zero". >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com