PEP 7: Don't allow MSVC extensions

[erikjanss]

PEP 7 has this sentence :

• Don't use GCC extensions

I would propose to change this to :

• Don't use GCC or MSVC extensions

Reason : using MSVC extensions in the C-code makes is harder to reuse the code or do experimental work on the code using different toolchains or make the code portable to other toolchains, which could be a long term disadvantage.

An exemption could be made for the PC/pyconfig.h file as this file is more or less MSVC specific.

[encukou]

@erikjanss In my interpretation, this is already implied as the PEP mentions ANSI/ISO standard C (though since the list of C99 features was added, it became a little less clear).
Do you have a specific example of a MSVC extension that should be called out? Is there non-standard code in CPython now that you'd like to get rid of?

[erikjanss]

@encukou Up to now I only found one (I have not yet been able to go through all files though),
since the PEP mentions GCC explicitly, it might be read as 'MSVC extension is fine in windows specific code'

Modules/socketmodule.c line 562 :

# define SUPPRESS_DEPRECATED_CALL __pragma(warning(suppress: 4996))

uses __pragma, which appears to be a MSVC extension :

https://msdn.microsoft.com/en-us/library/d9x1s805.aspx

[encukou]

Can you file a CPython pull request to properly conditionalize that?
I don't know much about coding for Windows, but to me this looks like an oversight rather than deliberately equating MS_WINDOWS with MSVC.

I think it will be useful to first have a PR discussion on this particular case, and then to clarify the PEP based on the PR discussion.

[erikjanss]

I made a PR for this :

python/cpython#9067

The associated issue is 34581

https://bugs.python.org/issue34581

[AA-Turner]

@encukou can this issue be closed? The linked PR python/cpython#9067 was merged in 2018, but there didn't seem to be any discussion there, or on bpo-34581.

A

[CAM-Gerlach]

Perhaps it would be best to revise the sentence to state "Don't use any non-standard, compiler-specific extensions," since this would presumably apply to LLVM too, and any other compilers. It may be implied by "ISO-standard C", but it only seems reasonable to either not call out one particular compiler, or explicitly clarify that it applies to all compilers—and "explicit is better than implicit", after all.

[encukou]

IMO, it's good to point out GCC explicitly -- GCC users are/were the ones using "their" extensions, and getting away with it since most CI-style checks use(d) GCC. (It's, arguably, most straightforward to set up.)
But clearly marking it as an example would be an improvement. Do you want to send a PR?

[erikjanss]

The reason I made this request was that we tried make CPython compile for windows with mingw (as many others did before).

As it is right now, it requires a good amount of patches, to even get the code base to compile. But most of those patches are simply cleaning up the use of 'ifdef MS_WINDOWS', since in lots of places it is assumed that compiling to target windows is the same thing as compiling with MSVC.

In the end, we got it working 'good enough' for our case, but decided that from a maintenance perspective, it was better to rewrite our code in C++ and have it compile with ease, than to keep looking for those 'ifdef' issues appearing in the code base, and making PR's to change them.

Making it explicit that using those MSVC should be guarded explicitly might make such efforts in the future easier.

[CAM-Gerlach]

IMO, it's good to point out GCC explicitly -- GCC users are/were the ones using "their" extensions, and getting away with it since most CI-style checks use(d) GCC. (It's, arguably, most straightforward to set up.)

Yeah, historically this makes sense, especially before LLVM came onto the scene.

But clearly marking it as an example would be an improvement. Do you want to send a PR?

Sure, happy to. Will do.

[CAM-Gerlach]

Thanks; opened as #2263 ,