Re: [Python-Dev] Renaming sqlite3
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? And why? 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. And why is that related to not supporting extensions with .DLL names anymore? IMO changing that would require a PEP (but I may be wrong), and this is only another idea which should be considered when writing or discussing that. If you don't like the idea, or don't see any advantages in this, I retract the request. pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. I think this is a very special case: it could have been implemented with separate DLLs which just provide the COM entry points, and find the location of pythoncom.pyd from the registry. I would discourage people from providing additional entry points to an extension module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
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 existing extensions. Also, I fail to see the point: since _socket.pyd for Python 2.5 is in a directory that is only on the Python 2.5 sys.path, it is unlikely that the files are ever confused for belonging to a different version. And why is that related to not supporting extensions with .DLL names anymore? IMO changing that would require a PEP (but I may be wrong), and this is only another idea which should be considered when writing or discussing that. If you don't like the idea, or don't see any advantages in this, I retract the request. Ok - it's not that I dislike it. It would be technically feasible. It would be some effort to implement. However, I would expect that other people object more strongly. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Renaming sqlite3
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 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? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
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 datapoint specific to OS/2 which probably has little relevance to Windows or to the specific case at hand: In order to get the curses_panel module to work, I have to forward the necessary curses entry points from the _curses module DLL. On OS/2, this only works for DLLs with the extension .DLL, so I ship _curses.pyd as _curses.dll. As a consequence, I can't implement option 3 for the OS/2 port but I can live with the nasty side-effects given the modest userbase and by documenting the issue in the port README. If you can make option 3 work for Windows, then I would do it now during the alpha to see whether it flushes any problems out. I must admit to being uncomfortable with including version numbers in module names, especially when they reflect a version outside the scope of Python. Ending up with a module name that can match a 3rd party dynamically linkable file would seem problematic no matter which way you look at it. FWIW, Andrew. - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
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 sqlite3, and raises an ImportError. 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? Don't know. 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. pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. There have been other conflicts reported before: I remember Windows\system32\wmi.dll conflicting with Tim Golden's wmi.py module. In addition, wmi.dll is very special, since it doesn't have an import table, IIRC. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
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 not supporting extensions with .DLL names anymore? pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. I think this is a very special case: it could have been implemented with separate DLLs which just provide the COM entry points, and find the location of pythoncom.pyd from the registry. I would discourage people from providing additional entry points to an extension module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
