Dennis Clarke <dcla...@blastwave.org> added the comment:
I very likely do not understand what is happening here. From my little
perspective the Python project has become far too critical to be yet
another language that can not be ported and used just about anywhere. I
often port software from various places into strange machines and even
onto z/OS mainframe type places. There is nothing more beautiful than
to take some C89 clean code and watch it just work. Flawlessly. Even the
OpenSSL project is locked neatly to that old C89 standard. I have tried
to get into a discussion about C99 but was always flatly told that we
need OpenSSL to work everywhere. Pretty much on anything that you can
get a compiler will do just fine. With the exception of some very small
embedded devices or tight memory constraints. It just works. Sadly the
Go Programming language is not like that. Neither is Rust. When I look
at The Python Project "Style Guide for C Code" here :
https://www.python.org/dev/peps/pep-0007/
The message is clearly stated :
Python versions greater than or equal to 3.6 use C89 with
several select C99 features:
- Standard integer types in <stdint.h> and <inttypes.h>.
We require the fixed width integer types.
- static inline functions
- designated initializers (especially nice for type
declarations)
- intermingled declarations
- booleans
- C++-style line comments
Future C99 features may be added to this list in the future
depending on compiler support (mostly significantly MSVC).
Don't use GCC extensions (e.g. don't write multi-line strings
without trailing backslashes).
All function declarations and definitions must use full prototypes
(i.e. specify the types of all arguments).
Only use C++ style // one-line comments in Python 3.6 or later.
No compiler warnings with major compilers (gcc, VC++, a few others).
That last line is a bit of a dream but I didn't write that. I merely
took a copy from the "Style Guide for C Code". So perhaps that needs a
rewrite and just state that the code will be mostly C99 safe and maybe
it would be best to just say iso9899:2011 and keep on plowing forwards.
One thing is certain, I built the OpenSSL 3.0.0 beta1 software on a pile
of systems in the last few weeks and then rebuilt a pile of dependant
libs and tools. They all work. Curl and libCurl is flawless. I am trying
to get Apache httpd 2.4.x ( and also trunk ) built and running. The only
major piece missing, critical and really important, is Python. OKay I
also have issues with ISC Bind but they seem to be drinking some strange
brew lately and their unit tests and other code has gone crab sideways.
That is another problem in someone elses backyard. Python however looks
to be very highly portable and it just works on everything. Pretty much.
So having said all that should this just be iso9899:2011 with no major
surprises?
ps: from the "Style Guide for C Code" we also see these gems :
Use 4-space indents and no tabs at all.
No line should be longer than 79 characters. If this and the
previous rule together don't give you enough room to code, your
code is too complicated -- consider using subroutines.
No line should end in whitespace. If you think you need significant
trailing whitespace, think again -- somebody's editor might delete
it as a matter of routine.
Those are just priceless old rules from the Fortan punchcard days.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue44789>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
