Automatically regenerate platform-specific modules #56828
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = None closed_at = <Date 2016-09-09.16:41:42.138> created_at = <Date 2011-07-23.09:43:32.302> labels =  title = 'Automatically regenerate platform-specific modules' updated_at = <Date 2016-09-09.16:41:42.136> user = 'https://bugs.python.org/Arfrever'
activity = <Date 2016-09-09.16:41:42.136> actor = 'zach.ware' assignee = 'none' closed = True closed_date = <Date 2016-09-09.16:41:42.138> closer = 'zach.ware' components =  creation = <Date 2011-07-23.09:43:32.302> creator = 'Arfrever' dependencies =  files = ['23423'] hgrepos =  issue_num = 12619 keywords = ['patch'] message_count = 27.0 messages = ['140952', '140957', '140958', '140962', '140969', '140984', '145653', '145659', '145667', '145759', '145762', '145948', '145953', '145956', '145958', '145961', '145970', '145971', '145977', '145981', '145987', '146021', '146027', '146360', '156157', '202627', '275335'] nosy_count = 20.0 nosy_names = ['lemburg', 'loewis', 'doko', 'amaury.forgeotdarc', 'pitrou', 'vstinner', 'jwilk', 'ned.deily', 'djc', 'ezio.melotti', 'eric.araujo', 'rpetrov', 'Arfrever', 'r.david.murray', 'Neurogeek', 'neologix', 'rosslagerwall', 'python-dev', 'Ramchandra Apte', 'zach.ware'] pr_nums =  priority = 'normal' resolution = 'out of date' stage = 'resolved' status = 'closed' superseder = '28027' type = None url = 'https://bugs.python.org/issue12619' versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']
The text was updated successfully, but these errors were encountered:
For example, Lib/plat-linux/IN.py was regenerated at Nov 23 12:09:28 2002 (revision c2604d69aa5d) for the last time, and nobody complained. These modules are inconsistent. For example, the IN module contains constants of 64 bits platforms, whereas it can be used on 32 bits platforms.
In my opinion, we should just drop these modules with h2py.py, I (re)opened a thread on python-dev.
Regeneration of platform-specific modules fixes concerns about their outdateness and architecture differences (32-bit vs 64-bit, big endian vs little endian).
Regeneration of given module could be performed only when corresponding header is available.
Eventually regeneration of platform-specific modules could be controlled by an option of
What do you do for platforms like OS X where we support one set of binary files that contain multi-architecture C-files that can run as Intel-64, Intel-32 or PPC-32 on the same machine at user option at run time? For example, the Apple-suppled system Python on OS X 10.6 has all three and you can use
$ file /usr/bin/python2.6 /usr/bin/python2.6: Mach-O universal binary with 3 architectures /usr/bin/python2.6 (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/python2.6 (for architecture i386): Mach-O executable i386 /usr/bin/python2.6 (for architecture ppc7400): Mach-O executable ppc
The static IN.py currently shipped in plat-darwin is misleading at best. And you can't improve the situation by regenerating at installation time.
I don't see why these modules should be auto-generated. The constants
If you think they need to be auto-generated, you should make a case by
Note that we cannot simply drop the modules. Some of the constants are
Did you read comments of this issue and my email thread on python-dev? There are differents examples:
Ah? I removed all plat-* directories and ran the full test suite: no failure. The Python socket modules contain many constants (SOCK_, AF_, SO_*, ...):
Which constants are used by the ctypes modules or can be used by modules using ctypes? Can you give examples? I listed usages of plat-* modules in the first message of my thread on python-dev.
By "ldd", you mean "ld.so" (dlopen)? Yes, I agree that we need to expose dl constants. But the other constants are not used.
Victor, please accept that this entire infrastructure was originally added because there was a need for it, and the need did not go away. It's probably relevant only for a minority of applications, but you would make this minority's lifes much more complicated by removing the modules. If they don't hurt, why remove them?
STINNER Victor wrote:
That's because the h2py.py script doesn't know anything about conditional
PTRDIFF_MIN = (-9223372036854775807-1) PTRDIFF_MAX = (9223372036854775807) PTRDIFF_MIN = (-2147483647-1) PTRDIFF_MAX = (2147483647)
Not all constants are really useful because of this, but some are, e.g.
Right, the modules are not tested at all, AFAIK.
True, but you probably agree that it's easier to parse a header file
Not constants used by the ctypes, but constants which can be used
Not in the standard lib, that's true.
Also note that the plat-* directories can contain platform specific code,
Finally, the list of standard files to include in those directories
Why may fix h2py.py, but regenerating plat-/.py files on build is not an
And it doesn't solve the Mac OS X issue.
INT16_MAX and INT32_MAX are not platform dependent. I'm not sure that Python
One more reason to remove them. By the way, there are not documented.
It's not exactly the purpose of this issue. We are first trying to get correct
I don't think that it's really useful to expose all constants. I prefer to
Sorry, I don't see which constants are useful with the ctypes module?
See my issue bpo-13226 for these constants.
(OS/2 has been deprecated in Python 3.3, see the PEP-11.)
Except plat-os2emx, I don't see other platform specific code.
Is it cdsuite? (http://offog.org/code/cdsuite.html)
I found policykit (it uses IN.INT_MAX). What are the 2 others? Which constants are used?
Oh, so many? Which projects? Which constants are used?
No, Freevo <http://freevo.sourceforge.net/\>.
Not in Debian, apparently...
(That's only 12; we have two versions of Ecasound in the archive, and
For Freevo: yes, it uses the CDROM module. But this module doesn't look to be perfect because Freevo has a fallback for FreeBSD and another for... Linux (because of missing CDROM.CDROM_DRIVE_STATUS?):
So Freevo does stil work if we remove the CDROM module. I still think that the Python standard library is not the right place for such constants. A third party module providing an API would be a better idea.
socket.SO_PEERCRED has been added to Python 3.3 by c64216addd7f:
"Add support for the send/recvmsg API to the socket module. Patch by David Watson and Heiko Wundram. (Closes bpo-6560)"
socket.SO_PEERCRED is not listed in socket documentation.
socket has no SO_BINDTODEVICE constant yet.
RTLD_NOW, RTLD_GLOBAL and RTLD_LAZY will added to the posix module if my issue bpo-13226 is accepted.