Paul Moore <p.f.mo...@gmail.com> added the comment:
> > This bothers me - how will backward compatibility work in that case? > > The new search order is compatible with the old search order, so you can > update all your layouts to have DLL dependencies in suitable locations and > you'll be fine. OK, cool. But one thing I'm not clear on, will this change just affect the embedded Python, or will it affect the whole process - which would mean that supporting an embedded Python 3.8 interpreter would mean potentially reorganising the application layout. That may be quite a cost, in some applications. Note that this is all on the basis of "I don't understand the implications, they should be documented" rather than being a specific problem that I know will happen. My particular scenario, though, is an application like Vim, that provides optional support for an "embedded scripting" which may be any one of a number of Python versions, or even other languages. In an application like that, costs for supporting Python 3.8 may simply result in no (or delayed) support for Python 3.8, rather than the application getting fixed. > And if you're still writing code for Windows 7 with no security updates > installed, Python 3.8 isn't going to save you anyway. Nobody's suggesting that it will. But maintaining *existing* code that supports older Windows versions, while still allowing Python 3.8 to be used as an embedded scripting language on systems that support it, is an entirely reasonable proposal. > > I really have no feel as to what practical impact there would be on an > > embedded application. > > Since we're not going to change the default search directories for the entire > process when embedding OK, if that's the case, then that alleviates most of my concerns. But it really wasn't obvious to me, and it's something that I think should be made clear in the docs, if only to reassure embedding applications that Python isn't making global changes. The docs for SetDllDirectory seem to imply that there *is* a global impact - "The SetDllDirectory function affects all subsequent calls to the LoadLibrary and LoadLibraryEx functions" (note - *all* subsequent calls, which implies that behaviour will change for the embedding application once Python has been loaded). > the only practical impact is that your extension modules need to have their > dependent DLLs either: > * in the system directory > * adjacent to the .pyd file > * in a directory added using AddDllDirectory That seems fine, so let's just state that and keep things simple for embedders to understand. > And if the embedding application is already calling SetDefaultDllDirectories, > as has been recommended for years, then they're already experiencing this > change and won't have to update a thing. Sadly, in my experience, an awful lot of projects (specifically, open source projects that write mostly cross-platform code, with the minimum of OS-specific differences) don't follow recommendations like this. They use LoadLibrary without digging too deeply into the implications or complexities, as long as it does what they want. And I don't think MS helped themselves much here, either - the whole business with SxS installs and assemblies was (IMO) *way* too much complexity for most cross platform projects to bother with, and went ignored. Even once things got simpler again, there remained a sense of "don't go there, just get something that works". (And to be clear, I'm not bashing on MS here - I find the Linux machinery around all of this to be just as complex and confusing). Anyhow, if as you say the only impact is that when a pyd file depends on a DLL, that DLL needs to be located in one of three places, all of which are equally valid on Python <=3.7, and there's no impact on the non-Python part of the embedded application, then it's not a big deal. Let's make the change, write up those points in What's New (at least), and leave it at that. ---------- _______________________________________ 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