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.

Title: Python 3.6 unnecessarily requires inttypes.h
Type: compile error Stage:
Components: Build Versions: Python 3.7, Python 3.6
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, brett.cannon, rdb, zach.ware
Priority: normal Keywords:

Created on 2017-01-11 18:11 by rdb, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg285250 - (view) Author: rdb (rdb) * Date: 2017-01-11 18:11
Python 3.6 now requires inttypes.h on all platforms.  However, this is not provided by MSVC 2010 and 2012, which is still used by some people who build extension modules for Python.

MSVC 2010 does provide stdint.h, and replacing the inttypes.h include with an include to stdint.h seems to work fine.

I would suggest a fix along the lines of this:

#if defined(_MSC_VER) && _MSC_VER < 1800
#include <stdint.h>
#include <inttypes.h>

Alternatively, the HAVE_INTTYPES_H definition could be used to fall back to stdint.h, and it could be undefined for the MSVC build.
msg285258 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2017-01-11 18:40
VS 2010 is not a supported compiler version for 3.6 (or 3.5) and VS 2012 is not a supported compiler for any version of Python. Extension modules built by those versions for use with Python 3.6 as supplied by will only work in very particular circumstances which cannot be relied upon. Furthermore, VS 2015 community edition is free (as in beer) and perfectly suitable for building both Python and extension modules.

I'd recommend closing as won't fix, but if another committer feels strongly enough about it I'll defer to them.
msg285260 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-01-11 18:44
Everything Zach said is accurate, so closing as "wont fix".
msg285261 - (view) Author: rdb (rdb) * Date: 2017-01-11 18:46
As far as I know, there should not be any ABI issues.  We've been building extension modules with non-matching MSVC versions for years without issues.

I find it hard to think of downsides to such a trivial fix.  It is somewhat frustrating that we will have to resort to shipping custom Python versions with patched headers.  Some people are constrained to older MSVC versions for reasons not in their control.
Date User Action Args
2022-04-11 14:58:41adminsetgithub: 73430
2017-01-11 18:46:52rdbsetmessages: + msg285261
2017-01-11 18:44:00brett.cannonsetstatus: open -> closed

nosy: + brett.cannon
messages: + msg285260

resolution: wont fix
2017-01-11 18:40:40zach.waresetnosy: + zach.ware
messages: + msg285258
2017-01-11 18:26:54serhiy.storchakasetnosy: + benjamin.peterson

type: compile error
components: + Build, - Extension Modules
versions: + Python 3.7
2017-01-11 18:11:47rdbcreate