...
I also think having a 2.8 out there that is exactly the same as 2.7, except that it was built with a different version of a compiler on one particular platform is a very very bad idea.
This was not my proposal. I was seeking a way to make a version that produces no collisions with DLLs, and it was a question about Stackless, not Python. But I admit that I was not aware of a license problem.
So how CAN this be addressed? This is really a distribution issue, and the distutils-sig has been hard at work building the infrastructure to support things like this.
Right now, if you build binary wheels with the two different "official" OS-X builds, you will get two different names, and pop can find the correct one. (last I checked, pip would happily install the wrong one if you asked it to, though I think that is slated to be fixed)
So if a different build of 2.7 for Windows is put out there, we need to make sure it reports the platform in a way that wheel and pip can make the distinction.
That was the reason to change the number. If other approaches like a different name for certain things is easy to do, I am fine with that, too.
It might be nice to patch the win_inst too--IIRC it's still not very smart about even 32 vs 64 bit builds.
As for stackless--just to be clear--can you use extensions built with the "regular" python with a stack less binary? If so, I understand the concern. If not, then it seems stackless is a separate ecosystem anyway.
Good question, and this _is_ a problem: Minus a few number of things, Stackless is almost completely binary compatible with extensions, and people _will_ want to try Stackless for some things or might want to go back and use CPython, be it only to remove concerns of a customer. People do want to install binary packages which are not built for Stackless, and we always did best efforts to support that. That means: basically we want to improve the situation for Stackless-based project in the first place, but make it easy to go back to CPython. We have a compiler switch that can completely remove the stackless additions and create a 100 % binary identical CPython version! That implies in the end that extension modules which work with Stackless will also be runnable on CPython 2.7.x VS2010 or whatever name it is. The naming problem then comes in again through the back-door, and we cannot shut our eyes and pretend "hey it is Stackless", because that is admittedly close to a fraud. So even if VS2010 exists only in the stackless branch, it is very likely to get used as CPython VS 2010, and I again have the naming problem ... cheers - Chris -- Christian Tismer :^) mailto:tismer@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/