RE: [Python-checkins] python/dist/src/Python bltinmodule.c,2.276,2.277
[Jack Jansen]
... If you build with Apple's MPW compilers it probably is, but (a) these compilers are horribly outdated and (b) it would take major surgery to compile Python with MPW anyway, nowadays.
In that case, can we remove the MPW #ifdef's from the Python core? Things like object.c's #ifdef MPW /* MPW C modf expects pointer to extended as second argument */ { extended e; fractpart = modf(v, &e); intpart = e; } #else fractpart = modf(v, &intpart); #endif and mathmodule.c's flea on the tip of the tail of the dog #ifdef MPW_3_1 /* This hack is needed for MPW 3.1 but not for 3.2 ... */ FUNC2(pow, power, "pow(x,y)\n\nReturn x**y (x to the power of y).") #else and acceler.c's germ on the aforemetioned flea's hindquarters: #ifdef MPW_881_BUG /* In 881 mode MPW 3.1 has a code generation bug which seems to set the upper bits; fix this by explicitly masking them off */ int temp; #endif And so on. These don't really improve maintainability <wink>.
On Monday, Feb 10, 2003, at 17:34 Europe/Amsterdam, Tim Peters wrote:
[Jack Jansen]
... If you build with Apple's MPW compilers it probably is, but (a) these compilers are horribly outdated and (b) it would take major surgery to compile Python with MPW anyway, nowadays.
In that case, can we remove the MPW #ifdef's from the Python core? Things like object.c's
I would suggest waiting until after 2.4. At the time of 2.2 it was still possible for a truly brave soul to build an extension module with MPW, and I while I've never tried this myself I have no reason to believe this has broken. But the examples you give can definitely go, if they bother you rip them out. After 2.3 we can get rid of everything related to MacOS9. -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
participants (2)
-
Jack Jansen
-
Tim Peters