I noticed that Python is compiled against the C99 version. Why not allowing C18 (aka C17 aka C11 with clarifications for compilers)? It has a better unicode and threading support.
AFAIK, not all compilers support C18.
Python actually uses C89 with several select C99 features, see PEP 7.
Yes, you’re right, it’s only supported by gcc and llvm. But I think c11 is supported by a vast number of compilers.
I think PEP 7 could add to the selected features also unicode
and threading from c11 (or c18 if the compiler supports it).
Mh, I’ve done a little search, and it seems MSVC does not support thread.h and sometimes acts strangely with variadic macros…
I think anyway unicode and restrict could be a good addition.
You can build this function using:
fd=open(filename, O_EXCL | ...); f = fdopen(fd, "...");
I’m not sure which kind of problem you are trying to solve. Python already supports Unicode. We use the wchar_t type and L"…" wide character string literals.
Well, for what I know, u literals can be optimized by the compiler, and wchar_t is platform-dependent. And what about restrict?
u"..." is a 16-bit wide string literal. For what do you need it in the CPython core?
Write the patch, measure the impact, and if it’s an improvement, let’s get it in with #ifdef for compilers that don’t support it.
sigh which compilers CPython officially supports?
For what I know, Chromium builds against C11, depending on the platform, even if the target can be C99 without problems. Maybe this activates some optimizations?
I think it’s not a bad idea to compile against C11, or better C18, if the compiler supports it, even if C11 unicode will be not used in CPython.
Ones that support C89 with the C99 features listed in PEP 7.
Chromium is not relevant.
You are making suggestions without mentioning what actual problems they will solve. That is not very useful.
Please do that! If you find that it results in an improvement, then let’s figure out how to best move there.
Python is conservative about C language features because
- Python tries to support a lowest common denominator of systems. Traditionally, this has meant supporting many proprietary Unixes each with their own proprietary C compiler. These days, there are a lot less weird compilers around than the 90s, but there are still people compiling Python themselves on very old systems with old versions of GCC or Clang. MSVC has also historically been slow to implement pure C features. That’s why we only started requiring C99 a few years ago.
- New C features aren’t that interesting. The evolution of the C language itself has been conservative for decades.
Write the patch, measure the impact
Ok, do you know if there’s a place in particular where can I can do the patch and test it? Maybe unicodeobject.c, bytesobject.c or both? Should I test str, bytes, bytearray or all of them? Is it timeit good enough? I see do you have a test suite, do you have also a benchmark suite?
and if it’s an improvement, let’s get it in with
#ifdeffor compilers that don’t support it.
Sure. Do you want also a coffee?
New C features aren’t that interesting
Well, I agree, indeed I was interested in threading and unicode only. But C11 threading system is not supported by MSVC…
Compiling Python on Windows with GCC produces a slower build?
No, I don’t know. I don’t know what you are trying to accomplish.
I assumed you want to switch to C18 because something would be faster. But I still don’t know what you think would be faster. Or maybe my assumption was not correct.
It doesn’t matter which is faster; we aren’t going to drop MSVC support.
Well, I respect your decision, even if I must say that if every important project continues to support MSVC, Microsoft will be never convinced to improve it. Edge was developed because people started to drop IE in favor of Firefox and Chromium/Chrome later. And now we have a lot of programmers that dropped the IE support, for Goddess’ sake.
@encukou: well, in theory unicode literals would be faster. Is there a bench suite in CPython code? I searched in Tools but I have not found one.
Again if there was an extremely compelling reason to use C18, we could consider tightening our compiler requirements, but there isn’t.