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: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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4