[Guido] > > Frankly, I think that for *any* functions that are in some external > > library (e.g. libc), Python should never provide a function prototype > > at all. The standard headers should provide the prototypes! [Jack] > They should, but what if they don't? That's what I like about the > pyport.h: it allows Python to build out of the box but still keeps > all the cruft needed because some platforms don't have their act > together in a single place. I know that I'm not expected to > understand sections of pyport.h that are for platforms I'm not > familiar with... Exactly! But the point is that over the last 10 years we've collected an enormous amount of cruft in this area that's not needed any more, because platforms improve. So my proposal is to remove all the cruft for which we don't have positive confirmation that it's needed somewhere, and then add back whatever's necessary to support all esoteric platforms again. Not-saying-what's-considered-esoteric-ly, --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4