Tarek Ziadé <ziade.ta...@gmail.com> added the comment: The build_ext command cannot be run twice, because the first time, the "compiler" option may be set to "unix" for example, or left to None, and then is transformed into a compiler object. That's the bug.
If you call it again, it'll break because the new_compiler() function will receive self.compiler, which is supposed to be a string not a compiler object. "compiler" is described as the "compiler type" in the options list of build_ext and should receive a string value. So what's broken is the fact that third-party code is using "compiler" as a compiler object attribute for years, because the command was creating the compiler object on the compiler option, rather than using its own attribute for that. And from an architectural point of view, if you have to tweak the compiler options by tweaking them direclty, it means that the build_ext command did a bad job with in the options it provides. For the cross-version incompatibility you are mentioning, it means that your code is working with "compiler" as a string option, then continue to work with it as a compiler object right after the command is run. But either way, there will be an incompatibility starting at 3.3 because we are going from the state "compiler is a string and also a compiler object, depending on when you use it" to "compiler is a only string option" This is an inconsistent behavior I am fixing here. While the code may be more complex with the descriptor, this will eventually go away in 3.3 (and 2.8 if it exists). What is the other solution you where thinking about ? adding a compiler_type option and keep the compiler option woud introduce more incompatibilities since "compiler" is used to configure build_ext by many code out there, while tweaking the compiler object itself is an advanced usage done by less people, which may do the same thing in an easy way by using another attribute. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6377> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
