RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20131121/c3c37a90/attachment.html below:

<div dir="ltr">On Thu, Nov 21, 2013 at 10:53 AM, Christian Tismer <span dir="ltr"><<a href="mailto:tismer@stackless.com" target="_blank">tismer@stackless.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

I also think having a 2.8 out there that is exactly the same as 2.7, except that it was built with a different version of a compiler on one particular platform is a very very bad idea.<br>
</blockquote></div>
This was not my proposal. I was seeking a way to make a version that<br>
produces no collisions with DLLs, and it was a question about Stackless,<br>
not Python. But I admit that I was not aware of a license problem.<div class="im"><br></div></blockquote><div><br></div><div style>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>

<br>

So if a different build of 2.7 for Windows is put out there, we need to make sure it reports the platform in a way that wheel and pip can make the distinction.<br>
<br>
</blockquote>
<br></div>
That was the reason to change the number. If other approaches like a different<br>
name for certain things is easy to do, I am fine with that, too.</blockquote><div><br></div><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 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>

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 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 href="http://python.org">python.org</a> CPython with your binary builds?</div>

<div style><br></div><div style>If so, then there will need to be a <a 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 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 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 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 style><br></div><div style>Note that for OS-X we have some of the same issues -- what with Homebrew and Macports, and Apple, and ... there are a lot of potentially binary incompatible builds of PythonX.Y out there. I don't think the issue really isÂ safelyÂ resolved, but at a policy level, I THINK the conclusion on the distutils list was to declare that we only support binary wheels on PyPi for the <a href="http://python.org">python.org</a> builds. Users of other builds should use their build system to get binaries (much like Linux).Â </div>

<div style><br></div><div style>That policy is more or less in place already for Windows, though pretty much defacto, as there aren't any other widely used Windows binaries out there. (there is Cygwin though, and I think it reports itself as a different platform).</div>

<div style><br></div><div style>-Chris</div><div style><br></div></div>-- <br><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R Â Â Â Â Â Â (206) 526-6959Â Â voice<br>7600 Sand Point Way NE Â Â (206) 526-6329Â Â fax<br>

Seattle, WA Â 98115 Â Â Â Â (206) 526-6317Â Â main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>

</div></div>

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