This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Arfrever, Neurogeek, Ramchandra Apte, amaury.forgeotdarc, djc, doko, eric.araujo, ezio.melotti, jwilk, lemburg, loewis, ned.deily, neologix, petri.lehtinen, pitrou, python-dev, r.david.murray, rosslagerwall, rpetrov, vstinner
Date 2011-10-19.22:24:56
SpamBayes Score 5.551115e-17
Marked as misclassified No
Message-id <201110200025.59548.victor.stinner@haypocalc.com>
In-reply-to <4E9F43B8.9010000@egenix.com>
Content
> > There are differents examples:
> >  - LONG_MAX is 9223372036854775807 even on 32 bits system
> >  - On Mac OS X, FAT programs contains 32 and 64 binaries, whereas
> >  constants are changed for 32 or 64 bits
> 
> That's because the h2py.py script doesn't know anything about conditional
> definitions, e.g.
> 
> PTRDIFF_MIN = (-9223372036854775807-1)
> PTRDIFF_MAX = (9223372036854775807)
> PTRDIFF_MIN = (-2147483647-1)
> PTRDIFF_MAX = (2147483647)

Why may fix h2py.py, but regenerating plat-*/*.py files on build is not an 
option according to Martin (msg145659).

And it doesn't solve the Mac OS X issue.

> Not all constants are really useful because of this, but some are, e.g.
> INT16_MAX, INT32_MAX, etc.

INT16_MAX and INT32_MAX are not platform dependent. I'm not sure that Python 
should provide such constants.

> Right, the modules are not tested at all, AFAIK.

One more reason to remove them. By the way, there are not documented.

> > The Python socket modules contain many constants (SOCK_*, AF_*,  SO_*,
> > ...): http://docs.python.org/library/socket.html#socket.AF_UNIX
> 
> True, but you probably agree that it's easier to parse a header file
> into a Python module than to add each and every socket option on
> the planet to the C socket module, don't you ? :-)

It's not exactly the purpose of this issue. We are first trying to get correct 
constants.

I don't think that it's really useful to expose all constants. I prefer to 
expose more constants on demand. When we add new constants, we try to use it, 
test it and document it (e.g. O_CLOEXEC).

> > 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.
> 
> Not constants used by the ctypes, but constants which can be used
> with the ctypes module.

Sorry, I don't see which constants are useful with the ctypes module?

> > By "ldd", you mean "ld.so" (dlopen)?
> 
> Yes.

See my issue #13226 for these constants.

> Also note that the plat-* directories can contain platform specific code,
> e.g. the OS2 dirs have replacements for the pwd and grp modules.

(OS/2 has been deprecated in Python 3.3, see the PEP 11.)

Except plat-os2emx, I don't see other platform specific code.
History
Date User Action Args
2011-10-19 22:24:56vstinnersetrecipients: + vstinner, lemburg, loewis, doko, amaury.forgeotdarc, pitrou, jwilk, ned.deily, djc, ezio.melotti, eric.araujo, rpetrov, Arfrever, r.david.murray, Neurogeek, neologix, rosslagerwall, python-dev, petri.lehtinen, Ramchandra Apte
2011-10-19 22:24:56vstinnerlinkissue12619 messages
2011-10-19 22:24:56vstinnercreate