>> Is this even an issue for 3.x? ISTM that the C library macros aren't >> used, anyway, so I think this entire section could go from the header >> files. > > $ grep isspace > /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/*.h > /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#undef > isspace > /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#define > isspace(c) iswspace(btowc(c)) > > I'm not familiar with pyport.h usage. I do see that it protects the problem > lines with: > #ifdef _PY_PORT_CTYPE_UTF8_ISSUE
I think you missed my point. Python shouldn't be using isspace anymore at all, so any work-arounds for certain BSD versions should be outdated and can be removed entirely. Of course, before implementing that solution, one would have to verify that this claim (macros not used) is indeed true. > So long as that is not defined when C++ is in use no problem. I'm not so much concerned with compiling with C++, but care about a potential cleanup of the headers. >> For 2.7, things are more difficult. > > This is where a fix is required. Is there going to be another 2.7 release to > deliver a fix in? Yes, there will be more 2.7 bugfix releases. If a fix is too intrusive or too hacky, it might be that the bug must stay unfixed, though. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
