Closed movermeyer closed 1 year ago
FWIW, I respect the attempt to clearly document when people should and shouldn't use your library.
If https://github.com/closeio/ciso8601/pull/70 gets merged, you'll have another reason to use this: strict parsing of RFC 3339. The standard library still doesn't support this in 3.7.
Closing this. I've documented the reasons not to use ciso8601
in https://github.com/closeio/ciso8601/blob/master/why_ciso8601.md (with snazzy Mermaid flow chart).
Aside: Once #140 is merged, the decision tree gets very simple 😁
When
ciso8601
was first created, there were no reasonable alternatives to it. By virtue of being implemented in C, it was simply much faster than Python implementations.However, time have moved on, and there are viable alternatives, so the choice is more nuanced.
For example, as of Python 3.7, there exists
datetime.fromisoformat
that provides the inverse ofdatetime.isoformat
. While it is not a complete replacement forciso8601
(ex. it doesn't support formats likeYYYYMMDD
), for users that were only ever using ciso8601 to provide that inverse, they might be better served by usingfromisoformat
.Further, the Pendulum project has implemented a fast C parser as well. While pendulum will be slower, they support a wider subset of the ISO 8601 spec.
So there is now a spectrum of quality parsers that users might want to use:
It might be time for
ciso8601
to change its marketing to be more nuanced. Originally, when there were no real alternatives, it made sense to say:But perhaps now we should be doing something similar to a flow-chart:
(Aside: I backported
fromisoformat
to pre-Python 3.7 versions: )From a practical standpoint, this would involve mentioning alternatives in
ciso8601
's README (or perhaps a new document). It would also mean rewriting any other docs to tone down any rhetoric.(Aside: In general, I'd like to see more collaboration between the various ISO 8601 parse projects, especially
Pendulum
andudatetime
)