Marc Recht <marc@informatik.uni-bremen.de> writes: > Although I'm quite sure the FreeBSD community doesn't like it I'll make > a patch against sys/defs.h to put a define _BSD_SOURCE at the top of the > chain which sets the default environment and post it to the > freebsd-current discussion list. Could you please call it __EXTENSIONS__? Many of the functions that fall under it are not BSD specific, and _BSD_SOURCE selects the favour-bsd API on other systems. _BSD_SOURCE would be fine for things that are traditionally in BSD, but have been superceded by competing POSIX API. In that case, Python would want to use the POSIX API. So would would not want to define _BSD_SOURCE (just as we don't want to define _OSF_SOURCE and _GNU_SOURCE, but cannot avoid doing so). > I'm quite sure it's an object to be extended.. There are some strange > systems out there which all need special treatment.. ... or just cannot be supported. Please see PEP 11, we'll be phasing out support for a number of such systems. It's just not worth the pain. Python works on Posix systems, and uses extensions where available. It does not work on strange systems; tough luck for users of such systems (we have yet to hear from a DYNIX user who wants to run Python 2.2). > > Only if all other options have been exhausted. What problems occur if > > _XOPEN_SOURCE is defined? > _XOPEN_SOURCE sets _POSIX_C_SOURCE. And why is that a problem? Regards, Martin
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