Thomas Heller wrote:
> Since on Windows binary extensions have to be compiled for the exact
> major version of Python, it seems logical (to me, at least), to include
> that version number into the filename. Say, _socket25.pyd.
This would be a major change; it might break the build process of many
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> But if you make the change to implement option 3, IMO it would be a
>> good idea to add the Python version number to the .pyd basename as
>> well.
>
> Can you please elaborate? In the name of what .pyd file do you want
> the Python version number?
Thomas Heller wrote:
> But if you make the change to implement option 3, IMO it would be a
> good idea to add the Python version number to the .pyd basename as
> well.
Can you please elaborate? In the name of what .pyd file do you
want the Python version number? And why? And why is that related
to
Martin v. Löwis wrote:
> I just tried creating a pysqlite VS project, and ran into a naming
> conflict: the Windows DLL is called sqlite3.dll. So if it is on
> sys.path
>
> import sqlite3
>
> might find the DLL, instead of finding the package. Python then
> finds that there is no entry point in s
Martin v. Löwis wrote:
> I see three options:
> 1. rename sqlite3 again
> 2. link sqlite3 statically into _sqlite3.pyd
> 3. stop treating .DLL files as extension modules
>
> I'm actually leaning towards option 3: what is the rationale
> for allowing Python extension modules to be named .DLL?
A d
I just tried creating a pysqlite VS project, and ran into a naming
conflict: the Windows DLL is called sqlite3.dll. So if it is on
sys.path
import sqlite3
might find the DLL, instead of finding the package. Python then
finds that there is no entry point in sqlite3, and raises an
ImportError.
I s
