> While that is true, I would hope that you come to the conclusion that > these macros can potentially do much more than simply hiding library > functions. Instead, their *primary* purpose is to request Single Unix > behaviour in case a platform implements both the standard behaviour, > and the traditional one (regardless of which tradition the system > follows). I'm fully aware of it. I say it's sometimes a PITA, too. At least if it comes to 3rd party modules. > So I would be *very* careful to enable these macros only for a few > translation units; I'm pretty sure that the "law" would be on the > vendor's side if inconsistent usage of these defines would be found to > cause problems, in Irix 27, or ValueBSD 3. That's why I'm totaly in favor of "stricly POSIX conforming" for Python itself. It's IMHO an other situation when it comes to modules or extensions. (Also, the ones in the Python distribution.) IMHO the module implementors should define for themself which standard they need/support (if any). As you've pointed out in your last mail there are (major?) technical problems with stat (eg. struct stat) which need to be solved. > If the change is only for 2.4, that would be fine - that code > hopefully will get testing on several other platforms before 2.4 is > released. Totally agree. That would be a way to big change for 2.3.x and it needs much testing, too. > Believes should not be trusted too much when it comes to > portability. If you can think of an obscure interpretation of some > standard, it is almost certain that there is some vendor out there who > has chosen that interpretation. And sometimes the standard itself is the problem... Regards, Marc
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