[Python-Dev] PEP 0404 and VS 2010

Christian Tismer tismer at stackless.com
Thu Nov 21 19:53:22 CET 2013


> 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 
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 at 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/

More information about the Python-Dev mailing list