Doesn't this change remove the only way to convert from a numpy date scalar to a built-in one?

Doesn't this change remove the only way to convert from a numpy date scalar to a built-in one?

If it does, then we'll have to add a method. I forgot to mark this PR as a draft (actually, even less: just a start for iterating on one based on @seberg's input) - I hope that's clearer now.

Yeah, you are right. Need to change only the "to object" casting... to not rely on getitem. I have a half plan to make the getpyobject and getitem two distinct methods more clearly (since we have both right now). But the thing is that most of our scalars do use getitem for their object casts (i.e. float64arr.astype(object) returns python floats!

So, this needs special cased casting, so you need to change the casting in this file, and then override that the casting is actually always used as well!

Doesn't this change remove the only way to convert from a numpy date scalar to a built-in one?

I'm not sure if this is a pattern we want to encourage, but this works in 1.20.2

import numpy as np
from datetime import datetime

arr = np.arange(10).view("M8[s]")

>>> arr[2].astype(datetime)
datetime.datetime(1970, 1, 1, 0, 0, 2)

The point is that arr.item() (and arr.tolist() I guess) should probably return the Python scalar (or error), while arr.astype(object) does currently the same as arr.item(), but based on the other issue the idea was that it should change to return NumPy date-time scalars.
The patch would have changed both, but I guess the idea was to only change the astype().

Note that .astype(datetime) is the same as .astype(object).

I suspect this is be de-facto superseded by @jbrockmendel new start in gh-23205 (and otherwise is stalled anyway). So closing for now, we can reopen at any point though!

Yeah, sorry, this never made it to the top of my to-do list 🥲