Subclassing datetime.datetime

[MarkKoz]

Can #133 be reconsidered?

There are two ways in which implementing the interface without subclassing is causing problems:

1. Type checkers error when arrow.Arrow is used where datetime.datetime or datetime.date is expected.
2. arrow.Arrow does not pass an isinstance(datetime.datetime) check. Arguably such check shouldn't be done, but if I am using a library that does this, then there's nothing I can do but use arrow.Arrow.datetime.

Using arrow.Arrow.datetime is a solution, but it's not as elegant as being able to pass arrow.Arrow directly.

The downside might be that despite implementing the same interface, some functions may have different semantics than datetime.datetime. This could lead to unexpected results when expecting a datetime.datetime. I haven't analysed it thoroughly, but it seems that most of the differences would be with classmethods rather than instance methods; it's rare to pass the type around rather than an instance, or to use classmethods on an instance.

Is the stance still the same as it was 7 years ago? What are everyone's thoughts now?

[MarkKoz]

There may be a solution with a custom ArrowFactory, but there doesn't seem to be a public API to replace the factory used by arrow.api. The idea is to subclass Arrow with a custom metaclass that uses __instancecheck__ and __subclasscheck__ to return True for datetime.datetime.

[onerandomusername]

Found some more discrepancies, the most glaring of which is timestamp is a property on arrow.arrow.Arrow, but is a callable on datetime.datetime....

this leads to some fun issues with TypeError: 'int' object is not callable

[jadchaar]

Hey @onerandomusername, in Arrow 1.0+ time stamp is now a function to align with the datetime API. We still support time stamps as properties through int_timestamp and float_timestamp for backward compatibility purposes, but timestamp() is now the primary invocation.

[onerandomusername]

Yeah, I was using a very old version to check on, sorry for the confusion here! 🙃