(original) (raw)
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?
Good question, and this \_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.
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 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 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 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 now,
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.
Conclusion:
\----------
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 :^) 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/