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
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 :^) <mailto:tis...@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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
