[Python-Dev] PEP 0404 and VS 2010

Christian Tismer tismer at stackless.com
Thu Nov 21 22:32:55 CET 2013

On 21/11/13 20:46, Chris Barker wrote:
> well, as you said below, you want to keep binary compatibility between 
> stackless and cPython, right down to the same dll name, so yes, it is 
> about Python. And since we are talking about it -- it actually would 
> be nice to be able to have a builds of python for Windows (any 
> version) that are not restricted to one compiler version per python 
> version. (Like a VS2010 py2.7, for example, but not JUST that)

That is a great target that I cannot address right now, but would love 
to work
on that, when I have understood all the API/ABI miracles. I was not aware of
those things that are already there.

> well, there is precedent for that with the OS-X builds -- so 
> reasonable enough. However, that really only helps for binary wheels 
> and pip -- which haven't been widely adopted yet (to put it mildly!). 
> So maybe a new dll name makes sense -- honestly  while some of how 
> Windows handles dlls makes "dll hell" inevitable, it's made worse by 
> really short dll names, and re-using names even when versions change 
> -- we're so far past the 8.3 world, I have no idea why that's still done.
> so a python27_VS_2010.dll or something might make sense.

I am converted to an OS X developer since 2006, but never had ABI problems,
because I use homebrew, but instead of being set free on Windows after 
30 years
of pain, I now have the same mess in my Parallels VMs.
Customers are so cruel, aren't they?

> Throw some info in there about 64 vs 32 bit too? or is it enough that 
> the linker will let you know if there is a problem?
>         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 ...
> Just to be clear here:
> You want to be able to create a non-stackless, regular old CPython 
> binary built with VS2010. (which is also compatible with  stackless build)

Yes, this is the idea, to some contorted definition of 'idea'.
> OK, now:
> Do you want people to be able to use extensions built by third parties 
> for python.org <http://python.org> CPython with your binary builds?

Would be great, but I would not mind to create their extensions on 
stackless.com, instead.

> If so, then there will need to be a python.org <http://python.org> 
> binary built with VS2010, and a way that makes it hard for people to 
> try to use extensions built for a different VS-version-build.
> If not, then the only problem is that users of your VS2010-built 
> binary will go off willy nilly and try to use extensions built for 
> python.org <http://python.org> builds, and they may appear to work at 
> first glance, but may do weird things or crash unexpectedly.

Yes, in the end it is much better to get some changes into CPython.
But as I read the input from Nick and Martin, I am afraid this is over
my tops, at least for the timeline I have set for myself.
(And yeah, I was pushy, as I always was with the Stackless project - 
forgive me).

> I'd say the issue there is education as much as anything.
> Or couldn't you simply install your binary somewhere other than 
> C:\python27? (and use different registry setting or whatever so the 
> windows installers will not get confused?)

Yes I can, and I'm pretty much considering. Seeking an improvement right 
not a controversial path or whatnot...

> The other potential route for error is a pip install -- you don't want 
> pip to find a binary that is incompatible with your build -- so you 
> should assure that whatever pip/wheel uses to identify the build is 
> set differently in your build (see the relevant PEPs).

Yes, I want to make PIP work with it, want to make it very simple to install
whatnot, and let people use that stuff. So if you can, please teach me
what I need to do or avoid. I don't want to intrude anywhere, I just want
to make the Stackless site a useful site where people can try extensions
and additions without getting into that DLL hell where I was for ages.


I do not want to do anything bad.

I do not want to solve hard-to-solve ABI problems in a week.

I do not want to drive python-dev crazy right now for just that.

What I want is a workable CPython path for some customer (!=CCP) to use
for the next (maybe 5) years, and I want to build that now, for good.

I think you have helped me incredibly much, and we need to talk in private.

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131121/82f89dba/attachment.html>

More information about the Python-Dev mailing list