On 10/30/2014 8:59 AM, R. David Murray wrote:
On Wed, 29 Oct 2014 23:33:06 -0400, Terry Reedy wrote:
The devguide needs to be kept up to date. If you open a tracker issue,
put me as nosy to review and commit.
The devguide is about building python itself. Paul is talking about
building ext
On Wed, 29 Oct 2014 23:33:06 -0400, Terry Reedy wrote:
> On 10/29/2014 4:05 PM, Paul Moore wrote:
> > On 29 October 2014 15:31, Nathaniel Smith wrote:
> >>> You can use Express editions of Visual Studio.
> >>
> >> IIUC, the express edition compilers are 32-bit only, and what you actually
> >> wan
On 10/29/2014 11:37 AM, Steve Dower wrote:
My ideal target (Utopia refined to be achievable) is for python-dev
to handle the Python binaries themselves (already done) and to make
them easy to bundle with applications/etc (I'm working on this for
3.5), and for PyPI to include pre-built wheels for
On 10/29/2014 4:05 PM, Paul Moore wrote:
On 29 October 2014 15:31, Nathaniel Smith wrote:
You can use Express editions of Visual Studio.
IIUC, the express edition compilers are 32-bit only, and what you actually
want are the "SDK compilers":
https://github.com/cython/cython/wiki/64BitCythonEx
ndows Phone
From: Paul Moore<mailto:p.f.mo...@gmail.com>
Sent: 10/29/2014 15:48
To: Ethan Furman<mailto:et...@stoneleaf.us>
Cc: Python Dev<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] Status of C compilers for Python on Windows
On 2
On 29 October 2014 23:49, Steve Dower wrote:
> "For the paid versions, I'm going to assume that anyone who paid for a
> compiler and doesn't know where their copy is, probably can't be
> helped ;-)"
>
> You could link to visualstudio.com for the trial versions, and maybe to a
> page/post about the
On 29 October 2014 23:22, Nathaniel Smith wrote:
>> Yeah, I know what you mean. My take on this is that I agree it's not
>> easy if you don't know and can't get access to the information, but if
>> you can, there's very little to it.
>
> That's great, but yeah. In case it helps as a data point, I
On Wed, Oct 29, 2014 at 10:46 PM, Paul Moore wrote:
> On 29 October 2014 22:19, Ethan Furman wrote:
>>> Yeah, I wondered about that. I'll work up a patch for that. But the
>>> more I think about it, it really is trivial:
>>
>> I am reminded of an interview question I was once asked which was pref
On 29 October 2014 23:02, Ethan Furman wrote:
> On 10/29/2014 03:46 PM, Paul Moore wrote:
>>
>> On 29 October 2014 22:19, Ethan Furman wrote:
>>>
>>>
>>>- where one should be at when one starts the compile process
>>
>>
>> I don't understand this. It's just "pip wheel foo" to build a wheel
>>
> On Oct 29, 2014, at 7:02 PM, Ethan Furman wrote:
>
> On 10/29/2014 03:46 PM, Paul Moore wrote:
>> On 29 October 2014 22:19, Ethan Furman wrote:
>>>
>>> - where one should be at when one starts the compile process
>>
>> I don't understand this. It's just "pip wheel foo" to build a wheel
>>
On 10/29/2014 03:46 PM, Paul Moore wrote:
On 29 October 2014 22:19, Ethan Furman wrote:
- where one should be at when one starts the compile process
I don't understand this. It's just "pip wheel foo" to build a wheel
for foo (which will be downloaded), or "pip wheel ." or "python
setup.p
On 29 October 2014 22:19, Ethan Furman wrote:
>> Yeah, I wondered about that. I'll work up a patch for that. But the
>> more I think about it, it really is trivial:
>
> I am reminded of an interview question I was once asked which was prefaced
> with: "Here's an easy one..."
>
> My reply was, if y
On 10/29/2014 03:09 PM, Paul Moore wrote:
On 29 October 2014 20:26, Donald Stufft wrote:
This sounds like something good for packaging.python.org
Yeah, I wondered about that. I'll work up a patch for that. But the
more I think about it, it really is trivial:
I am reminded of an interview qu
> On Oct 29, 2014, at 6:09 PM, Paul Moore wrote:
>
> On 29 October 2014 20:26, Donald Stufft wrote:
>> This sounds like something good for packaging.python.org
>
> Yeah, I wondered about that. I'll work up a patch for that. But the
> more I think about it, it really is trivial:
>
> - For non-
On 29 October 2014 20:26, Donald Stufft wrote:
> This sounds like something good for packaging.python.org
Yeah, I wondered about that. I'll work up a patch for that. But the
more I think about it, it really is trivial:
- For non-free MSVC, install the appropriate version, and everything just wor
This sounds like something good for packaging.python.org
> On Oct 29, 2014, at 4:05 PM, Paul Moore wrote:
>
> On 29 October 2014 15:31, Nathaniel Smith wrote:
>>> You can use Express editions of Visual Studio.
>>
>> IIUC, the express edition compilers are 32-bit only, and what you actually
>>
Stephen J. Turnbull:
the pain of using Windows is what drives me away from all of them.
Enough that you are not able to make the software you write usable on
Windows? I see your point and agree with it - I don't even like Windows
much at all, but supporting it is important for plenty of reasons
On 29 October 2014 15:31, Nathaniel Smith wrote:
>> You can use Express editions of Visual Studio.
>
> IIUC, the express edition compilers are 32-bit only, and what you actually
> want are the "SDK compilers":
> https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows
>
> These are fre
> On Oct 29, 2014, at 11:37 AM, Steve Dower wrote:
>
> Antoine Pitrou wrote:
>> On Wed, 29 Oct 2014 11:07:53 -0400
>> Tres Seaver wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 10/29/2014 10:31 AM, R. David Murray wrote:
>>>
If you are writing code targeted for W
On Wed, Oct 29, 2014 at 5:17 PM, David Cournapeau
wrote:
>
>
> On Wed, Oct 29, 2014 at 3:25 PM, Antoine Pitrou
> wrote:
>
>> On Thu, 30 Oct 2014 01:09:45 +1000
>> Nick Coghlan wrote:
>> >
>> > Lots of folks are happy with POSIX emulation layers on Windows, as
>> > they're OK with "basically wor
On Wed, Oct 29, 2014 at 3:25 PM, Antoine Pitrou wrote:
> On Thu, 30 Oct 2014 01:09:45 +1000
> Nick Coghlan wrote:
> >
> > Lots of folks are happy with POSIX emulation layers on Windows, as
> > they're OK with "basically works" rather than "works like any other
> > native application". "Basically
Antoine Pitrou wrote:
> On Wed, 29 Oct 2014 11:07:53 -0400
> Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/29/2014 10:31 AM, R. David Murray wrote:
>>
>> > If you are writing code targeted for Windows, I think you are very
>> > likely to have an MSDN subscri
On Thu, 30 Oct 2014 01:09:45 +1000, Nick Coghlan wrote:
> (Paul Moore already covered most of this, but I'll go into a bit more
> detail in a couple of areas)
>
> On 29 October 2014 00:46, Tony Kelman wrote:
> > Stephen J. Turnbull:
> >> It should be evident by now that our belief is that the la
On 29 Oct 2014 14:47, "Antoine Pitrou" wrote:
>
> On Wed, 29 Oct 2014 10:31:50 -0400
> "R. David Murray" wrote:
>
> > On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver
wrote:
> > > On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
> > >
> > > > most developers on Windows do have access to Microso
On Thu, 30 Oct 2014 01:09:45 +1000
Nick Coghlan wrote:
>
> Lots of folks are happy with POSIX emulation layers on Windows, as
> they're OK with "basically works" rather than "works like any other
> native application". "Basically works" isn't sufficient for many
> Python-on-Windows use cases thou
On Wed, 29 Oct 2014 11:07:53 -0400
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/29/2014 10:31 AM, R. David Murray wrote:
>
> > If you are writing code targeted for Windows, I think you are very
> > likely to have an MSDN subscription of some sort if your packag
(Paul Moore already covered most of this, but I'll go into a bit more
detail in a couple of areas)
On 29 October 2014 00:46, Tony Kelman wrote:
> Stephen J. Turnbull:
>> It should be evident by now that our belief is that the large majority
>> of Windows users is well-served by the current model
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2014 10:31 AM, R. David Murray wrote:
> If you are writing code targeted for Windows, I think you are very
> likely to have an MSDN subscription of some sort if your package
> includes C code. I'm sure it's not 100%, though.
My experience
On 30 October 2014 00:46, Antoine Pitrou wrote:
> On Wed, 29 Oct 2014 10:31:50 -0400
> "R. David Murray" wrote:
>
>> On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver
>> wrote:
>> > On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
>> >
>> > > most developers on Windows do have access to Microso
On Wed, 29 Oct 2014 10:31:50 -0400
"R. David Murray" wrote:
> On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver wrote:
> > On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
> >
> > > most developers on Windows do have access to Microsoft tool
> >
> > I assume you mean python-dev folks who work
On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver wrote:
> On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
>
> > most developers on Windows do have access to Microsoft tool
>
> I assume you mean python-dev folks who work on Windows: it is certainly
> not true for the vast majority of develoepr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
> most developers on Windows do have access to Microsoft tool
I assume you mean python-dev folks who work on Windows: it is certainly
not true for the vast majority of develoeprs who use Python on W
lto:step...@xemacs.org>
Sent: 10/28/2014 20:59
To: Tony Kelman<mailto:kel...@berkeley.edu>
Cc: python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] Status of C compilers for Python on Windows
Tony Kelman writes:
> No, just hearing the words come out o
Tony Kelman writes:
> No, just hearing the words come out of my mouth they sound a little
> nuts. Maybe not, there are after all half a dozen or more
> incompatible alternate Python implementations floating around. I
> think most of them started as from-scratch rewrites rather than
> source
On 10/28/2014 6:45 AM, Stephen J. Turnbull wrote:
because it's a fork, it's a different name
I think this is an important point, and first brought to this discussion
here. A fork is _not_ called Python, but something else... but if it is
kept extremely compatible and up-to-date in the hopes of
On 28 October 2014 14:46, Tony Kelman wrote:
> Patches should be done well and accompanied with proper documentation
> so new functionality is fully reproducible. If that's what's holding
> up review, comments in the bug threads indicating as much would be
> helpful.
Typically that tends to be ex
Stephen J. Turnbull:
Sure -- as long as it works for them, though, such potential
contributors don't necessarily care if it works for anybody else. My
experience (in other projects) is that allowing that level of
commitment to be sufficient for inclusion in the maintained code base
frequently re
Tony Kelman writes:
> If potential contributors have a desire to get it working in the
> first place, then they will also be invested in helping keep it
> working on an ongoing basis.
Sure -- as long as it works for them, though, such potential
contributors don't necessarily care if it works f
Stephen J. Turnbull:
Python is open source. Nobody is objecting to "somebody else" doing
this.[1] The problem here is simply that some "somebody elses" are
trying to throw future work over the wall into python-dev space.
If that's how it's seen at this point, then it sounds like the logical
c
R. David Murray writes:
> On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou
> wrote:
> > My point is that your "Windows build" would not have the same behaviour
> > as a MSVC-produced Windows build, and so testing it with it would not
> > certify that your code would actually be compatible
On Sun, Oct 26, 2014 at 3:41 PM, Paul Moore wrote:
> Not really, to be honest. I still don't understand why anyone not
> directly involved in CPython development would need to build their own
> Python executable on Windows.
Late Python bugfix releases are source-only, so if you suffer from a
bug
On 27 October 2014 21:19, Steve Dower wrote:
>> No, we've been trying to establish whether the patches to build with mingw
>> were
>> intended to produce such a compatible build. It's not clear, but so far it
>> seems
>> that apparently that is *not* the intent (and worse, mingw-w64 may not even
On Mon, Oct 27, 2014 at 8:54 PM, Steve Dower wrote:
> Greg Ewing wrote:
>> Nick Coghlan wrote:
>>> That assumption will allow MinGW-w64 to link with the appropriate
>>> MSVCRT versions for extention building without anything breaking.
>>
>> If that works, then the same technique should allow CPyth
> Paul Moore wrote:
> On 27 October 2014 20:45, Greg Ewing wrote:
>> Nick Coghlan wrote:
>>>
>>> That assumption will allow MinGW-w64 to link with the appropriate
>>> MSVCRT versions for extention building without anything breaking.
>>
>>
>> If that works, then the same technique should allow CPyt
Greg Ewing wrote:
> Nick Coghlan wrote:
>> That assumption will allow MinGW-w64 to link with the appropriate
>> MSVCRT versions for extention building without anything breaking.
>
> If that works, then the same technique should allow CPython itself to be built
> in a VS-compatible way with mingw, s
On 27 October 2014 20:45, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> That assumption will allow MinGW-w64 to link with the appropriate
>> MSVCRT versions for extention building without anything breaking.
>
>
> If that works, then the same technique should allow CPython
> itself to be built in a
Nick Coghlan wrote:
That assumption will allow MinGW-w64 to link with the appropriate
MSVCRT versions for extention building without anything breaking.
If that works, then the same technique should allow CPython
itself to be built in a VS-compatible way with mingw,
shouldn't it?
Those objectin
On Mon, Oct 27, 2014 at 5:48 PM, Paul Moore wrote:
> On 26 October 2014 23:44, Paul Moore wrote:
>> On 26 October 2014 23:11, Ray Donnelly wrote:
>>> I don't know where this "ABI compatible" thing came into being;
>>
>> Simple. If a mingw-built CPython doesn't work with the same extensions
>> as
On Sun, Oct 26, 2014 at 11:52 PM, wrote:
>
> Zitat von Tony Kelman :
>
>> A maintainer has volunteered. Others will help. Can any core developers
>> please begin reviewing some of his patches?
>
>
> Unfortunately, every attempt to review these patches has failed for me,
> every time. In the last
On 27 October 2014 18:47, Case Van Horsen wrote:
> I've managed to build gmpy2 (which requires GMP, MPFR, and MPC
> libraries) using msys2. I've detailed the steps (hacking) at:
>
> https://code.google.com/p/gmpy/source/browse/trunk/msys2_build.txt
Thanks for this. I don't have the time to read y
On Mon, Oct 27, 2014 at 10:48 AM, Paul Moore wrote:
> The bad news is that the support added to the old 32-bit mingw to
> support linking to alternative C runtime libraries (specifically
> -lmsvcr100) has bitrotted, and no longer functions correctly in
> mingw-w64. As a result, not only can mingw-
On 26 October 2014 23:44, Paul Moore wrote:
> On 26 October 2014 23:11, Ray Donnelly wrote:
>> I don't know where this "ABI compatible" thing came into being;
>
> Simple. If a mingw-built CPython doesn't work with the same extensions
> as a MSVC-built CPython, then the community gets fragmented (
Please ignore this. I hit the wrong button.
On 27 October 2014 14:18, Paul Moore wrote:
> On 26 October 2014 01:05, Ray Donnelly wrote:
>> Download and run:
>> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download
>
> Sending this offline because I really don
On 26 October 2014 01:05, Ray Donnelly wrote:
> Download and run:
> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download
Sending this offline because I really don't want to start up another
extended debate, but is there a version of this that I can use that
_
On 27 October 2014 12:30, Nick Coghlan wrote:
>> OK, I'm willing to accept that statement. But I don't understand it,
>> and I don't think you've explained why you *need* your CPython
>> interpreter to be compiled with mingw (as opposed to a number of other
>> things you might need around building
On 27 October 2014 09:37, Paul Moore wrote:
> On 26 October 2014 23:24, Tony Kelman wrote:
>> I want, and in many places *need*, an all-MinGW stack.
>
> OK, I'm willing to accept that statement. But I don't understand it,
> and I don't think you've explained why you *need* your CPython
> interpre
On 27 October 2014 09:44, Paul Moore wrote:
> I view it as critical (because availability of binaries is *already*
> enough of a problem in the Windows world, without making it worse)
> that we avoid this sort of fragmentation. I'm not seeing an
> acknowledgement from the mingw side that they agre
Zitat von Tony Kelman :
A maintainer has volunteered. Others will help. Can any core developers
please begin reviewing some of his patches?
Unfortunately, every attempt to review these patches has failed for me,
every time. In the last iteration of an attempt to add mingw64 support,
I had ask
On 26 October 2014 23:11, Ray Donnelly wrote:
> I don't know where this "ABI compatible" thing came into being;
Simple. If a mingw-built CPython doesn't work with the same extensions
as a MSVC-built CPython, then the community gets fragmented (because
you can only use the extensions built for you
On 26 October 2014 23:24, Tony Kelman wrote:
> I want, and in many places *need*, an all-MinGW stack.
OK, I'm willing to accept that statement. But I don't understand it,
and I don't think you've explained why you *need* your CPython
interpreter to be compiled with mingw (as opposed to a number o
Not really, to be honest. I still don't understand why anyone not
directly involved in CPython development would need to build their own
Python executable on Windows. Can you explain a single specific
situation where installing and using the python.org executable is not
possible
I want, and in m
On Sun, Oct 26, 2014 at 10:41 PM, Paul Moore wrote:
> On 26 October 2014 13:12, Tony Kelman wrote:
>> Only cross-compilation and the build system in the above list are relevant
>> to CPython, but I hope I have convinced you, Paul Moore, etc. that there are
>> real reasons for some groups of users
On 26 October 2014 14:28, Ray Donnelly wrote:
> I like this idea. To reduce the workload, we should probably pick
> Python3 (at least initially)?
Aren't the existing patches on the tracker already for Python 3.5+?
They should be, as that's the only version that's likely to be a
possible target (u
On 26 October 2014 17:59, Tony Kelman wrote:
> Ensuring compatibility with CPython's
> chosen msvcrt has made that work even more difficult for them.
Ensuring compatibility with CPython's msvcrt is mandatory unless you
want to create a split in the community over which extensions work
with which
On 26 October 2014 13:12, Tony Kelman wrote:
> Only cross-compilation and the build system in the above list are relevant
> to CPython, but I hope I have convinced you, Paul Moore, etc. that there are
> real reasons for some groups of users and developers to prefer MinGW-w64
> over MSVC.
Not real
If this includes (or would likely include) a significant portion of the
Scientific Computing community, I would think that would be a compelling
use case.
I can't speak for any of the scientific computing community besides myself,
but my thoughts: much of the development, as you know, happens on
On Sun, Oct 26, 2014 at 2:28 PM, Ray Donnelly wrote:
> On Sun, Oct 26, 2014 at 1:12 PM, Tony Kelman wrote:
>> Thanks all for the responses. Clearly this is a subject about which
>> people feel strongly, so that's good at least. David Murray's guidance
>> in particular points to the most likely pa
On Sun, 26 Oct 2014 06:12:45 -0700, "Tony Kelman" wrote:
> Steve Dower:
> > Building CPython for Windows is not something that needs solving.
>
> Not in your opinion, but numerous packagers of MinGW-based native or
> cross-compiled package sets would love to include Python. The fact
> that they c
On Sun, Oct 26, 2014 at 1:12 PM, Tony Kelman wrote:
> Thanks all for the responses. Clearly this is a subject about which
> people feel strongly, so that's good at least. David Murray's guidance
> in particular points to the most likely path to get improvements to
> really happen.
>
> Steve Dower:
Thanks all for the responses. Clearly this is a subject about which
people feel strongly, so that's good at least. David Murray's guidance
in particular points to the most likely path to get improvements to
really happen.
Steve Dower:
> Building CPython for Windows is not something that needs solv
Ray Donnelly wrote:
> On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore wrote:
>> On 25 October 2014 23:22, Chris Angelico wrote:
>>> On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote:
My point is that your "Windows build" would not have the same behaviour
as a MSVC-produced Windows bui
On Sat, Oct 25, 2014 at 6:24 PM, R. David Murray wrote:
> Note: it can be made even less compelling by making it a lot easier to
> build CPython on Windows without having an MSVC license (which I think
> means not using the GUI, for which I say *yay* :). I think Zach Ware
> has been working on im
On Sat, Oct 25, 2014 at 7:05 PM, Ray Donnelly wrote:
> On Sun, Oct 26, 2014 at 12:30 AM, Antoine Pitrou wrote:
>> On Sat, 25 Oct 2014 19:24:38 -0400
>> "R. David Murray" wrote:
>>>
>>> I know I for one do not generally test patches on Windows because I
>>> haven't taken the time to learn how to
Ray Donnelly wrote:
> On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower
> wrote:
>> Ray Donnelly wrote:
>>> Also, where are the publicly accessible specifications and other technical
>>> descriptions that MinGW-w64 would need to implement strong binary
>>> compatibility with MSVC? As a random example,
On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower wrote:
> Ray Donnelly wrote:
>> On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore wrote:
>>> On 25 October 2014 23:22, Chris Angelico wrote:
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou
wrote:
> My point is that your "Windows build" woul
On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore wrote:
> On 25 October 2014 23:22, Chris Angelico wrote:
>> On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote:
>>> My point is that your "Windows build" would not have the same behaviour
>>> as a MSVC-produced Windows build, and so testing it with
On Sun, Oct 26, 2014 at 12:30 AM, Antoine Pitrou wrote:
> On Sat, 25 Oct 2014 19:24:38 -0400
> "R. David Murray" wrote:
>>
>> I know I for one do not generally test patches on Windows because I
>> haven't taken the time to learn how to build CPython on it. Sure, I
>> could test pure python chang
On 26/10/2014 00:24, R. David Murray wrote:
On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou wrote:
On Sun, 26 Oct 2014 09:06:36 +1100
Chris Angelico wrote:
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote:
How do you know this isn't a problem, since you haven't *tested* with
MSVC?
W
On Sat, Oct 25, 2014 at 1:10 PM, Ray Donnelly
wrote:
> On Sat, Oct 25, 2014 at 6:13 PM, Steve Dower
> wrote:
> > Building CPython for Windows is not something that needs solving. The
> > culture on Windows is to redistribute binaries, not source, and both the
> > core team and a number of redist
On Sat, 25 Oct 2014 19:24:38 -0400
"R. David Murray" wrote:
>
> I know I for one do not generally test patches on Windows because I
> haven't taken the time to learn how to build CPython on it. Sure, I
> could test pure python changes by applying patches to an installed
> Python, but that's an o
On Sun, 26 Oct 2014 00:19:44 +0200, Antoine Pitrou wrote:
> On Sun, 26 Oct 2014 09:06:36 +1100
> Chris Angelico wrote:
> > On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote:
> > > How do you know this isn't a problem, since you haven't *tested* with
> > > MSVC?
> > > Why on Earth would you w
On 25 October 2014 23:22, Chris Angelico wrote:
> On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote:
>> My point is that your "Windows build" would not have the same behaviour
>> as a MSVC-produced Windows build, and so testing it with it would not
>> certify that your code would actually be
On Sun, 26 Oct 2014 09:22:18 +1100
Chris Angelico wrote:
> On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote:
> > My point is that your "Windows build" would not have the same behaviour
> > as a MSVC-produced Windows build, and so testing it with it would not
> > certify that your code would
On 25 October 2014 21:50, Steve Dower wrote:
> Ray Donnelly wrote:
>> What is it that you
>> are afraid of if CPython can be compiled out of the box using
>> mingw/MinGW-w64? Why are you fighting so hard against having option.
>
> I'm afraid of users having numpy crash because they're using an MSV
On 10/25/2014 5:11 PM, Chris Angelico wrote:
It might fragment the community to have multiple different binary
distributions. But it ought to be possible for any person/organization
to say "We're going to make our own build of Python, with these
extension modules, built with this compiler, targe
On Sat, 25 Oct 2014 21:10:23 +0100, Ray Donnelly
wrote:
> On Sat, Oct 25, 2014 at 6:13 PM, Steve Dower
> wrote:
> > (Apologies for the short reply, posting from my phone.)
> >
> > "MSVC can continue
> > to be the default compiler used for Python on Windows, none of Roumen's
> > patches change t
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote:
> My point is that your "Windows build" would not have the same behaviour
> as a MSVC-produced Windows build, and so testing it with it would not
> certify that your code would actually be compatible with genuine
> MSVC builds of CPython, whic
On Sun, 26 Oct 2014 09:06:36 +1100
Chris Angelico wrote:
> On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote:
> > How do you know this isn't a problem, since you haven't *tested* with
> > MSVC?
> > Why on Earth would you want to test your PEP work with an unsupported
> > Windows compiler and
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote:
> How do you know this isn't a problem, since you haven't *tested* with
> MSVC?
> Why on Earth would you want to test your PEP work with an unsupported
> Windows compiler and runtime, rather than with the officially supported
> compiler and ru
On Sat, Oct 25, 2014 at 10:52 PM, Antoine Pitrou wrote:
> On Sat, 25 Oct 2014 21:10:23 +0100
> Ray Donnelly wrote:
>>
>> This is the second time you've used the vacuous "culture on Windows"
>> argument, now with an added appeal to (vague) authority.
> [...]
>> Why are you fighting so hard against
On Sun, 26 Oct 2014 08:53:29 +1100
Chris Angelico wrote:
> On Sun, Oct 26, 2014 at 8:47 AM, Antoine Pitrou wrote:
> > And how do you know that it would have worked with MSVC if you only use
> > MinGW?
> > If you want to ensure compatibility with MSVC, you must build with MSVC.
> > There's no work
On Sat, 25 Oct 2014 21:10:23 +0100
Ray Donnelly wrote:
>
> This is the second time you've used the vacuous "culture on Windows"
> argument, now with an added appeal to (vague) authority.
[...]
> Why are you fighting so hard against having option.
> If CPython wants to truly call itself an Open So
On Sun, Oct 26, 2014 at 8:47 AM, Antoine Pitrou wrote:
> And how do you know that it would have worked with MSVC if you only use
> MinGW?
> If you want to ensure compatibility with MSVC, you must build with MSVC.
> There's no working around that.
Precisely. If you build with MinGW, you can't ensu
On Sun, 26 Oct 2014 08:11:39 +1100
Chris Angelico wrote:
>
> It might fragment the community to have multiple different binary
> distributions. But it ought to be possible for any person/organization
> to say "We're going to make our own build of Python, with these
> extension modules, built with
On Sun, Oct 26, 2014 at 7:50 AM, Steve Dower wrote:
> Ray Donnelly wrote:
>> What is it that you
>> are afraid of if CPython can be compiled out of the box using
>> mingw/MinGW-w64? Why are you fighting so hard against having option.
>
> I'm afraid of users having numpy crash because they're using
em to help.
>
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
> ________________
> From: Tony Kelman
> Sent: 10/25/2014 9:06
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Status of C compilers for Python on Windows
>
> I'm seve
Ray Donnelly wrote:
> What is it that you
> are afraid of if CPython can be compiled out of the box using
> mingw/MinGW-w64? Why are you fighting so hard against having option.
I'm afraid of users having numpy crash because they're using an MSVC CPython
instead of a mingw CPython. I'm afraid of u
On Sat, 25 Oct 2014 05:45:24 -0700, "Tony Kelman" wrote:
> As a developer of a (compiled) open-source library or application, wouldn't
> you love to be able to build binaries on Linux for Windows? With some work
> and build system patches, you can. For many projects it's a simple matter of
> ./con
Steve
Top-posted from my Windows Phone
From: Tony Kelman<mailto:kel...@berkeley.edu>
Sent: 10/25/2014 9:06
To: python-dev@python.org<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] Status of C compilers for Python on Windows
I'm several w
I'm several weeks late to this discussion, but I'm glad to see that it
happened. I'm not a Python developer, and barely a user, but I have several
years of daily experience compiling complicated scientific software cross-
platform, particularly with MinGW-w64 for Windows. The Python community,
bot
1 - 100 of 143 matches
Mail list logo
