Showing content from http://mail.python.org/pipermail/python-dev/attachments/20131121/82f89dba/attachment.html below:
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 21/11/13 20:46, Chris Barker wrote:<br>
</div>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">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)</div>
</div>
</div>
</blockquote>
<br>
That is a great target that I cannot address right now, but would
love to work<br>
on that, when I have understood all the API/ABI miracles. I was not
aware of<br>
those things that are already there.<br>
<br>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div style="">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.</div>
<div style=""><br>
</div>
<div style="">so a python27_VS_2010.dll or something might
make sense.</div>
<div style=""><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I am converted to an OS X developer since 2006, but never had ABI
problems,<br>
because I use homebrew, but instead of being set free on Windows
after 30 years<br>
of pain, I now have the same mess in my Parallels VMs.<br>
Customers are so cruel, aren't they?<br>
<br>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">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?</div>
<div style=""><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
It might be nice to patch the win_inst too--IIRC it's
still not very smart about even 32 vs 64 bit builds.<br>
<br>
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.<br>
</blockquote>
<br>
</div>
Good question, and this _is_ a problem:<br>
Minus a few number of things, Stackless is almost
completely binary<br>
compatible with extensions, and people _will_ want to try
Stackless for some<br>
things or might want to go back and use CPython, be it
only to remove concerns of<br>
a customer.<br>
People do want to install binary packages which are not
built for Stackless,<br>
and we always did best efforts to support that.<br>
<br>
That means: basically we want to improve the situation for
Stackless-based<br>
project in the first place, but make it easy to go back to
CPython.<br>
We have a compiler switch that can completely remove the
stackless<br>
additions and create a 100 % binary identical CPython
version!<br>
<br>
That implies in the end that extension modules which work
with Stackless<br>
will also be runnable on CPython 2.7.x VS2010 or whatever
name it is.<br>
The naming problem then comes in again through the
back-door,<br>
and we cannot shut our eyes and pretend "hey it is
Stackless",<br>
because that is admittedly close to a fraud.<br>
<br>
So even if VS2010 exists only in the stackless branch, it
is very likely<br>
to get used as CPython VS 2010, and I again have the
naming problem ...<br>
</blockquote>
<div><br>
</div>
<div style="">Just to be clear here:</div>
<div style=""><br>
</div>
<div style="">You want to be able to create a non-stackless,
regular old CPython binary built with VS2010. (which is
also compatible with stackless build)</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, this is the idea, to some contorted definition of 'idea'.<br>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">OK, now:</div>
<div style=""><br>
</div>
<div style="">Do you want people to be able to use
extensions built by third parties for <a
moz-do-not-send="true" href="http://python.org">python.org</a>
CPython with your binary builds?</div>
</div>
</div>
</div>
</blockquote>
<br>
Would be great, but I would not mind to create their extensions on
stackless.com, instead.<br>
<br>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">If so, then there will need to be a <a
moz-do-not-send="true" href="http://python.org">python.org</a>
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.</div>
<div style=""><br>
</div>
<div style="">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 <a moz-do-not-send="true"
href="http://python.org">python.org</a> builds, and they
may appear to work at first glance, but may do weird
things or crash unexpectedly.</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, in the end it is much better to get some changes into CPython.<br>
But as I read the input from Nick and Martin, I am afraid this is
over<br>
my tops, at least for the timeline I have set for myself.<br>
(And yeah, I was pushy, as I always was with the Stackless project -
forgive me).<br>
<br>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">I'd say the issue there is education as much
as anything.</div>
<div style=""><br>
</div>
<div style="">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?)</div>
<div style=""><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes I can, and I'm pretty much considering. Seeking an improvement
right now,<br>
not a controversial path or whatnot...<br>
<br>
<blockquote
cite="mid:CALGmxE++Y4dwe2GYRMdEDFm1Z1BVwQpVoi996r8EfW5=DKVamQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">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).</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, I want to make PIP work with it, want to make it very simple to
install<br>
whatnot, and let people use that stuff. So if you can, please teach
me<br>
what I need to do or avoid. I don't want to intrude anywhere, I just
want<br>
to make the Stackless site a useful site where people can try
extensions<br>
and additions without getting into that DLL hell where I was for
ages.<br>
<br>
Conclusion:<br>
----------<br>
<br>
I do not want to do anything bad.<br>
<br>
I do not want to solve hard-to-solve ABI problems in a week.<br>
<br>
I do not want to drive python-dev crazy right now for just that.<br>
<br>
What I want is a workable CPython path for some customer (!=CCP) to
use<br>
for the next (maybe 5) years, and I want to build that now, for
good.<br>
<br>
I think you have helped me incredibly much, and we need to talk in
private.<br>
<br>
Cheers -- Chris<br>
<br>
<pre class="moz-signature" cols="72">--
Christian Tismer :^) <a class="moz-txt-link-rfc2396E" href="mailto:tismer@stackless.com"><mailto:tismer@stackless.com></a>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* <a class="moz-txt-link-freetext" href="http://starship.python.net/">http://starship.python.net/</a>
14482 Potsdam : PGP key -> <a class="moz-txt-link-freetext" href="http://pgp.uni-mainz.de">http://pgp.uni-mainz.de</a>
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? <a class="moz-txt-link-freetext" href="http://www.stackless.com/">http://www.stackless.com/</a></pre>
</body>
</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