Expected behavior when installing on older python versions?

[bmcfee]

I'm in the process of making some conda-forge packages for a few libraries (aifc, sunau, chunk), and the differences between conda and pypi dependency specifications are raising some subtleties that I'd like to get some clarity on before moving forward.

Without getting into the minutiae of conda packaging, I'm wondering if there's some intended / guaranteed / documented behavior for these implementations if they are installed on an older python (<=3.12) where the standard lib still includes this functionality?

I've tried it, and it seems to "work" in that it imports the standard lib version. I suppose this is a consequence of the module import path search order, but relying on this - and only this - to ensure correct behavior seems a little iffy to me.

[youknowone]

Yes, thats how standard libraries work. Guess how volnurable the ecosystem will be if overriding standard libraries are allowed.
This library provide nothing more than standard library. So it will be fine.

[bmcfee]

Thanks for the response, but I think my question is not quite answered. The behavior of these packages seems fine on older pythons where they may not be needed, but it's not clear that this is verified or documented. (One could also subvert the import order by fiddling with sys.path and probably break this at runtime, but that's most likely a footgun beyond the scope of these packages to work around.)

I understand that the intent is to only install these on python 3.13+, but there are situations in which it may be necessary (or convenient) to allow installing them on older pythons as well, even if they are not needed functionally. So it would be helpful to have some documented clarity on what the intended behavior is for these situations.

[youknowone]

Oh, thank you for clarification.

As you said, I expected below by priority:

1. These libraries are expected to be installed on only 3.13+ (or 3.12+ for asyncore/asynchat)
2. Even if they are installed for older versions, it (safely) will not work.

Adding them to README will be reasonable. Will this be good enough?
Is your concern also including about number 3, none of those situation probably with odd environment?

I honestly never thought about that case. I will be happy if you have additional suggestions in that case.

[bmcfee]

Adding them to README will be reasonable. Will this be good enough?

I think it would be a good idea! 😁 But it would be even better if it could be clearly stated what is meant by "will not work". I also wonder about what could happen if these are installed in an old python distribution and then uninstalled - is it guaranteed that the standard library implementations would remain untouched?

Is your concern also including about number 3, none of those situation probably with odd environment?

Sorry, I don't see a number 3 in your post - did it get deleted?

I honestly never thought about that case. I will be happy if you have additional suggestions in that case.

I understand that the intention is to leave these modules as close to the original standard library implementation as possible. However, I wonder if it would be worth adding a bit of logic in each module to detect if it's operating in an older python than it's meant for, and at least throw a warning? As you note above, this should never actually end up as live code unless something has gone wrong (ie subverting the module search path), but it might be nice to have some means to identify if it does happen.

One could imagine more extreme versions of this idea, where it throws an ImportError or something in that case, or otherwise reverts itself under the hood to the standard library code instead. Those seem a bit overkill in my opinion, but I figured it's worth mentioning some alternatives here.