Also breaks randomgen. I don't think NumPy will ever directly use SeedlessSequence, but it was written with the purpose it is shows up downstream.

Ack, that is too bad that Cython checks for it even though it never exists.

Let's probably just do this. I think the slightly better fix will be to just move this to the .pyx file. That way, Cython will find it at runtime for the moment but when compiling new Cython modules against this, it is gone from the .pxd so that in the future we can actually remove it completly.

@bashtage SeedlessSequence was always a typo in the .pxd and was removed because the corresponding class didn't actually exist. SeedlessSeedSequence is the real class that was missing from the .pxd because of the typo.

In fixing this, we just didn't realize that downstream extension modules that linked in np.random's Cython API would always access everything declared in the .pxd it saw at buildtime even if they didn't actually use it at runtime (because, it doesn't actually exist).

Let's probably just do this. I think the slightly better fix will be to just move this to the .pyx file. That way, Cython will find it at runtime for the moment but when compiling new Cython modules against this, it is gone from the .pxd so that in the future we can actually remove it completly.

That's something we could always do at a later point, no?

in the future we can actually remove it completly.

That would be nice, we don't want to get stuck with an immortal typo.

That's something we could always do at a later point, no?

Yes, although the earlier we actually do it, the earlier the time comes when we technically might break someone, but in practice nobody will notice that when we remove it :).

I'm up for trying it if no one objects

I would recommend against trying that for 2.4.1 - always best to do a straight revert, and do anything else in main.

Let's just put it in, I think 2 lines with a clear way to test that it works doesn't matter for backporting, but 2.4.1 is basically identical anyway (normally I would prefer to not do this type of thin in a 2.4.x release though, while I don't think there would be a risk here).

But this whole thing is so risk free either way...

Ok, thanks for the help, all :)

I just hit this, and so was wondering what happened with the plan to yank and release 2.4.1? Thanks!!!

what happened with the plan to yank and release 2.4.1?

As far as I'm aware, that's still the plan.

@charris thanks for the 2.4.1 release! Are you planning to yank 2.4.0? Between the incoming links to this issue and scipy/scipy#24215, this clearly affects quite a few packages, and it's the first accidental ABI break in quite a while I believe, so yanking is the right to do. There shouldn't be any downsides to doing that - anyone who used == '2.4.0' will continue to have access to that version.

@rgommers I'll yank 2.4.0, but I am not convinced it will make much difference.

Yanked.

thanks!