Paul Moore <p.f.mo...@gmail.com> added the comment:
> Also, if I'm understanding your intention, loading an extension may fail when > Python is embedded if the process is using the legacy DLL search path. So, > like with ctypes, we'll be forcing embedding applications to update how they > load DLLs in order to comply with us, else they'll have to accept that some > packages won't work without the SetDefaultDllDirectories call. This bothers me - how will backward compatibility work in that case? There are applications (for example, Vim) that can embed Python, and it's possible to pick the Python version at compile time. Would Vim need additional code (possibly guarded by some sort of "If this is Python 3.8 or later" flag, which from my knowledge of the Vim code would not be particularly easy to add in a backward compatible way) to handle this change? Actually, as a more general point, I have been following this discussion, but I really have no feel as to what practical impact there would be on an embedded application. I get that this is OS functionality, and therefore it's not Python's place to explain the details to users, but IMO it *is* Python's responsibility to explain how embedding applications will need to change if we change how we configure things. Even if users are currently using an approach that is no longer encouraged (which is *I think* what you're saying about putting DLLs on PATH) they are still using something that works right now, and we're breaking it - so we need to describe what changed, *why* we felt we should break their code, and what they need to do, both to switch to the new model, and (if they have a requirement to do so) to support the old and new models simultaneously in their code (very few people, not even embedders, can suddenly say "we're dropping support for Python 3.7 and older, we only allow 3.8+ from now on"). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36085> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
