Re: [Python-Dev] mUTF-7 support?
On Fri, Oct 10, 2014 at 3:05 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: There are still lots of idiotic web sites that assume everything in front of the @ must be a letter, digit, dot, or hyphen, and even some that only permit one dot after the @... even though for 30 years or so, the RFCs have permitted a nice variety of other special characters, although not all of them. And heaps that require a dot after the @, which is definitely not a requirement. ChrisA ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10 October 2014 01:29, Victor Stinner victor.stin...@gmail.com wrote: What about the Python stable ABI? Would it be broken if we use a different compiler? What about third party Python extensions? What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.? The key point for me is that any supported build on Windows supports the exact same ABI. It is difficult for Windows users to set up a build environment (and changing the compiler will not alter that fact) so Windows users will rely on binary builds. If multiple ABIs exist, users will have the problem of projects shipping only one ABI binary, and if it doesn't match their Python, they are out of luck. It's critical that we don't double the number of binary builds projects need to ship. Having said that, I'm personally not interested in this, as I am happy with MSVC Express. Python 3.5 will be using MSVC 14, where the express edition supports both 32 and 64 bit. The licensing doesn't bother me personally, and the compiler is easy to install for people who want it. Any competing build environment would have to be as easy to install and use as MSVC Express to be worthwhile, IMO. The only advantage[1] to a new compiler would be if it trivially supported cross-compiling on Linux, as that would allow Limux developers to easily ship Windows binaries. Paul [1] I am not commenting on philosophical advantages like licensing here. ___ 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
Re: [Python-Dev] mUTF-7 support?
R. David Murray writes: in the email address (and can't contain non-ASCII yet...we need RFC 6855 support for that, and I'm not sure *anybody* has that yet). If it's an RFC, *somebody* has it *somewhere*. :-) ___ 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
Re: [Python-Dev] mUTF-7 support?
On 10/10/14 04:41, R. David Murray wrote: Specifically, it is about what we might better term mailbox *folders*...that is, not what you would normally think of as the 'mailbox name', which is usually understood to be the thing before the @ in the email address (and can't contain non-ASCII yet...we need RFC 6855 support for that, and I'm not sure *anybody* has that yet). In this context it is the names you give to folders on the IMAP server...starting (usually) with INBOX and adding from there. These names are used in IMAP commands (ex: the 'select' or 'create' commands), and IMAP uses mUTF-7 for those. In IMAP4, mail folders are called mailboxes. Yes, non universal notation sucks. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Nathaniel Smith n...@pobox.com wrote: You may want to get in touch with Carl Kleffner -- he's done a bunch of work lately on getting a mingw-based toolchain to the point where it can build numpy and scipy. To build *Python extensions*, one can use Carl's toolchain or the VC9 compiler for Python 2.7 that Microsoft just released. To build *Python* you need Visual Studio, Visual Studio Express, Windows SDK, or Cygwin because there is no other build process available on Windows. Python cannot be built with MinGW. The official 64-bit Python installer from Python.org is built with the Windows SDK compiler, not Visual Studio. The Windows SDK is a free download. The 32-bit installer is built with Visual Studio. Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Paul Moore p.f.mo...@gmail.com wrote: Having said that, I'm personally not interested in this, as I am happy with MSVC Express. Python 3.5 will be using MSVC 14, where the express edition supports both 32 and 64 bit. If you build Python yourself, you can (more or less) use whichever version of Visual Studio you want. There is nothing that prevents you from building Python 2.7 or 3.4 with MSVC 14. But then you have to build all Python extensions with this version of Visual Studio as well. Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10/10/2014 08:07 AM, Paul Moore wrote: On 10 October 2014 01:29, Victor Stinner victor.stin...@gmail.com wrote: What about the Python stable ABI? Would it be broken if we use a different compiler? What about third party Python extensions? What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.? The key point for me is that any supported build on Windows supports the exact same ABI. Just to make something clear that may not be clear to non-Windows developers: the C library is implicitly part of the ABI. So unless these other compilers bend over backwards to generate code / have a C library that behaves *exactly* like MSVC, their ABI will be different, and therefore shared libraries compiled with one compiler won't work with the next. Heck, even shared libraries compiled with one version of MSVC won't work with any other version! (This is something apparently being fixed by MSVC 15; apparently they are designing the ABI for forwards compatibility. Huzzah!) So if CPython officially said we support MSVC and Compiler X, I worry that we'd have third-party modules compiled with either one or the other, leaving users unable to mix and match third-party extensions as they do today. (I want to use library X, which is only available compiled by MSVC. I also want to use library Y, which is only available compiled by Compiler X. What should I do? ... install Linux?) Here's my perspective. Having your code compilable by more compilers is good. But a maze of #ifdefs is bad. We still have #ifdef's for Borland C--I'd be very surprised if anyone was compiling Python 3 with Borland C. IMO the benefit from supporting other compilers on Windows is negligible, but the costs in maintaining these other compilers is tangible. Or, worse, we accept changes to support these other compilers, but the support is incomplete, or goes unmaintained and breaks (and nobody notices). So as a practical matter I think I'd prefer if we continued to only support MSVC. In fact I'd prefer it if we removed support for other Windows compilers, instead asking those maintainers to publish their own patches / repos, in the way that Stackless does. //arry/ ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
2014-10-10 11:18 GMT+02:00 Sturla Molden sturla.mol...@gmail.com: If you build Python yourself, you can (more or less) use whichever version of Visual Studio you want. There is nothing that prevents you from building Python 2.7 or 3.4 with MSVC 14. Python 2.7 provides project files (PCbuild/*) for Visual Studio 2008. Python 3.4 provides project files (PCbuild/*) for Visual Studio 2010. Does it mean that VC 2010 supports VC 2008 project files? If I remember correctly, I got a wizzard proposing to convert the project files. I didn't try it, and I installed VS 2008 instead. I guess that VS 2014 requires a similar conversion wizzard for VS 2010 and VS 2008 project files. Victor ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Hi, Paul Moore wrote: The key point for me is that any supported build on Windows supports the exact same ABI. It looks like ABI compatibility is a goal of Clang on Windows: http://clang.llvm.org/docs/MSVCCompatibility.html http://blog.llvm.org/2014/07/clangllvm-on-windows-update.html I don't know the status of the compatibility for the C ABI with VS 2008 and VS 2010. (These articles look to be focused on C++.) OpenWatcom and Cygwin are not compatible with VS. Is MinGW fully compatible with MSVS ABI? I read that it reuses the MSVCRT, but I don't know if it's enough. I guess that a full ABI compatibility means more than just using the C library, calling convention and much more. Clang documentation mentions for example debug symbols compatible with the Microsoft debugger. ... therefore shared libraries compiled with one compiler won't work with the next. I noticed this issue when I provided wheel packages for Python 2.7 and 3.3 using the same Windows SDK (7.1)... Python 2.7 and 3.3 from python.org are built with different versions of VS, and so require a different version of the Windows SDK (7.0 for Python 2.7, 7.1 for Python 3.3). So if CPython officially said we support MSVC and Compiler X, I worry that we'd have third-party modules compiled with either one or the other, leaving users unable to mix and match third-party extensions as they do today. Ok, I understand and I agree. Currently, VS is the defacto standard, at least for Python. We still have #ifdef's for Borland C--I'd be very surprised if anyone was compiling Python 3 with Borland C. I opened an issue yesterday to drop support of this compiler! Please write your comment there to support my patch. http://bugs.python.org/issue22592 IMO the benefit from supporting other compilers on Windows is negligible, but the costs in maintaining these other compilers is tangible. Or, worse, we accept changes to support these other compilers, but the support is incomplete, or goes unmaintained and breaks (and nobody notices). If we decide to support officially a C compiler different than VS on Windows, it should be a real support. It should be possible to build Python without any patch, and we should have a buildbot. And someone should maintain the support for this compiler (fix all bugs). Untested code always break (later). Victor ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10.10.2014 11:26, Larry Hastings wrote: On 10/10/2014 08:07 AM, Paul Moore wrote: On 10 October 2014 01:29, Victor Stinner victor.stin...@gmail.com wrote: What about the Python stable ABI? Would it be broken if we use a different compiler? What about third party Python extensions? What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.? The key point for me is that any supported build on Windows supports the exact same ABI. Just to make something clear that may not be clear to non-Windows developers: the C library is implicitly part of the ABI. So unless these other compilers bend over backwards to generate code / have a C library that behaves *exactly* like MSVC, their ABI will be different, and therefore shared libraries compiled with one compiler won't work with the next. Heck, even shared libraries compiled with one version of MSVC won't work with any other version! (This is something apparently being fixed by MSVC 15; apparently they are designing the ABI for forwards compatibility. Huzzah!) So if CPython officially said we support MSVC and Compiler X, I worry that we'd have third-party modules compiled with either one or the other, leaving users unable to mix and match third-party extensions as they do today. (I want to use library X, which is only available compiled by MSVC. I also want to use library Y, which is only available compiled by Compiler X. What should I do? ... install Linux?) Here's my perspective. Having your code compilable by more compilers is good. But a maze of #ifdefs is bad. We still have #ifdef's for Borland C--I'd be very surprised if anyone was compiling Python 3 with Borland C. IMO the benefit from supporting other compilers on Windows is negligible, but the costs in maintaining these other compilers is tangible. Or, worse, we accept changes to support these other compilers, but the support is incomplete, or goes unmaintained and breaks (and nobody notices). So as a practical matter I think I'd prefer if we continued to only support MSVC. In fact I'd prefer it if we removed support for other Windows compilers, instead asking those maintainers to publish their own patches / repos, in the way that Stackless does. I don't think this is special to the Windows platform. We already do support quite a few compilers in CPython and for multiple platforms, so keeping support for e.g. MinGW or adding Intel C support wouldn't really make much difference in the overall #ifdef picture ;-) That said, We do need maintainers for this support, so if there are no people willing to support these compilers in CPython, we should use the external port hosting approach for these, IMO. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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
Re: [Python-Dev] mUTF-7 support?
I think the consensus so far is that this is a good idea. I just opened http://bugs.python.org/issue22598. Thanks for your feedback. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10 October 2014 02:29, Victor Stinner victor.stin...@gmail.com wrote: The free version (Visual Studio Express) only supports 32-bit VC++ 2008/2010 EE do not *bundle* a 64-bit compiler, but it's certainly possible to build 64-bit applications by using the compiler in the (also free) Windows SDK: http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/ https://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Larry Hastings la...@hastings.org wrote: Just to make something clear that may not be clear to non-Windows developers: the C library is implicitly part of the ABI. MacOS X also has this issue, but it less known amon Mac developers! There tends to be multiple versions of the C library, one for each SDK version. If you link the wrong one when building a Python extension it can crash. For example if you have Python built with the 10.6 SDK (e.g. Enthought) but has XCode with the 10.9 SDK as default, you need to build with the flag -mmacosx-version-min=10.6, and for C++ also -stdlib=libstdc++. Not doing so will cause all sorts of mysterious errors. Two other ABI problems on Windows is the stack alignment and the MinGW runtime: On 32-bit applications, MSVC use 16 bit stack alignment whereas MinGW uses 32-bit alignment. This is a common cause of segfaults for Python extensions built with MinGW. Most developers just assume it is sufficient to link the same CRT as Python. Another problem is the MinGW runtime (mingw32.a or mingw32.dll) which conflicts with MSCV and can cause segfaults unless it is statically linked. The vanlilla MinGW distro defaults to dynamic linkage for this library. Because of this a special MinGW toolchain was created for building SciPy on Windows: https://github.com/numpy/numpy/wiki/Mingw-static-toolchain Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Victor Stinner victor.stin...@gmail.com wrote: Is MinGW fully compatible with MSVS ABI? I read that it reuses the MSVCRT, but I don't know if it's enough. Not out of the box. See: https://github.com/numpy/numpy/wiki/Mingw-static-toolchain Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Larry Hastings la...@hastings.org wrote: So as a practical matter I think I'd prefer if we continued to only support MSVC. In fact I'd prefer it if we removed support for other Windows compilers, instead asking those maintainers to publish their own patches / repos, in the way that Stackless does. The scientific community needs to use MinGW or Intel compilers because of Fortran. So some support for other compilers will be good, at least for building C extensions. Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Merlijn van Deen valhall...@arctus.nl wrote: VC++ 2008/2010 EE do not *bundle* a 64-bit compiler, Actually it does, but it is not available from the UI. You can use it from the command line, though. Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Victor Stinner victor.stinner at gmail.com writes: Hi, Windows is not the primary target of Python developers, probably because most of them work on Linux. Official Python binaries are currently built by Microsoft Visual Studio. Even if Python developers get free licenses thanks for Microsoft, I would prefer to use an open source compiler if it would be possible. === Other compilers? I'm happily using MSYS2 (sourceforge.net/projects/msys2/), which handles Python and many Python and GNOME related projects using the mingw64 compiler (which can target 32 and 64 bit). MSYS2 provides a POSIX like environment to build native applications on windows (using the win32 api). It features a source level package manager, pacman, ported from ArchLinux, so lots of *nix applications and libraries are available (see https://github.com/Alexpux/MINGW-packages and also https://github.com/Alexpux/MSYS2-packages/ for core libs and apps). I've used it with success in apps that use Python + GTK+3 + Numpy + SciPy + Matplotlib. Hope this information is useful. Regards, Rafael ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10 October 2014 10:50, Victor Stinner victor.stin...@gmail.com wrote: Is MinGW fully compatible with MSVS ABI? I read that it reuses the MSVCRT, but I don't know if it's enough. I guess that a full ABI compatibility means more than just using the C library, calling convention and much more. MinGW can be made to build ABI-compatible extensions. Whether this will continue with MSVC 15 I don't know, as it requires a change to add an interface library for the relevant msvcrXX runtime. And the MinGW community is somewhat fragmented these days, with the core project not supporting 64-bit and various external projects doing so. Having said all this, it *is* possible with some effort to use MinGW to build Python extensions. As noted, the numpy developers have done a lot of work on this as some of the libraries they need must be built with mingw. And the state of distutils support for mingw is very sad, as well, IIRC (last time I looked there were a number of open bugs, and very little movement on them). Rather than put effort into more build options for CPython, I think it would be much more beneficial to the Windows community if effort was put into: 1. Improving support for compiling *extensions* with mingw and its 64-bit cousins, in a way that is compatible with a standard MSVC-built Python. This would involve sorting through and applying some of the distutils changes, as well as working with the mingw projects to ensure they will offer support for the MSVC15 runtime ina timely manner. 2. Looking at ways to support cross-compiling Windows extensions from Linux using mingw. I've no idea how practical this would be, but if Linux developers could provide Windows builds without having to maintain a Windows environment, that would be great. As I say, I have no personal interest here, as I use MSVC, but I know the above two options are commonly asked for. Paul ___ 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
Re: [Python-Dev] Internationalized email support (was mUTF-7 support?)
On Fri, 10 Oct 2014 16:16:24 +0900, Stephen J. Turnbull step...@xemacs.org wrote: R. David Murray writes: in the email address (and can't contain non-ASCII yet...we need RFC 6855 support for that, and I'm not sure *anybody* has that yet). If it's an RFC, *somebody* has it *somewhere*. :-) Ah, it looks like you may be right. I didn't find any hits in the first few pages on Google; the closest I got was: https://groups.google.com/forum/?_escaped_fragment_=topic/mozilla.dev.apps.thunderbird/QBFibOEK5x4#!topic/mozilla.dev.apps.thunderbird/QBFibOEK5x4 I started writing a response that said if so, it is hidden from google. Then I did some deeper digging, and found this: http://googleblog.blogspot.com/2014/08/a-first-step-toward-more-global-email.html So my search using the RFC number was just too narrow...since gmail is IMAP based, Google itself must have *some* sort of RFC 6855 support. (Unless they've done a hack job of this internationalization support that only works for their own gmail clients, which given my past experience working with the gmail IMAP API I would believe...although I think the IMAP problems I found were mostly bugs rather than intentional deviations from the standards). We had a GSOC student (Milan Oberkirch) working on international email support this past summer, and I believe you asked in the proposal review phase why working on support for these RFCs was apropos. At the time I was kind of hoping Python could kickstart development of internationalized email by providing tools to build experiments, but now that Google has announced support, supporting it has become surprisingly immediately relevant. (The previously experimental postfix support for RFC 6531 is targeted for official release in 2.12, which is another big step forward.) I'd better get to reviewing the rest of those patches sometime soonthey include a preliminary patch for RFC 6855. Unfortunately the email package itself doesn't handle RFC 6532 email and there's no proposed patch for that yet. --David ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On Thu, Oct 9, 2014 at 7:29 PM, Victor Stinner victor.stin...@gmail.com wrote: Hi, Windows is not the primary target of Python developers, probably because most of them work on Linux. Official Python binaries are currently built by Microsoft Visual Studio. Even if Python developers get free licenses thanks for Microsoft, I would prefer to use an open source compiler if it would be possible. So *anyone* can build Python from scatch. I don't like the requirement of having a license to build Python. The free version (Visual Studio Express) only supports 32-bit and doesn't support PGO build (Profile-Guided Optimizations, which are disabled if I remember correctly because of compiler bugs). I know that it's hard to replace Visual Studio. I don't want to do it right now, but I would like to discuss that with you. Although I'm not very active around here much anymore, I was primarily working on Windows things within the last few years. While we have a lot of Windows users, we don't have a lot of Windows contributors. The huge amount of churn necessary to make a change away from VS, or the more likely move to make it possible to support both VS and insert other compiler, seems like a large amount of work that doesn't turn up much of a benefit. Especially for a platform with constrained developer availability, working software trumps all, so I don't expect that a project like this is going to see the regular contributors shifting their focus away from improving Python as it is. With that said, I do see the benefit of being able to build Python with a free compiler. It would be great for us to be able to say it's always built with free tools, but I'm not sure who's going to make this happen... ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2014 05:26 AM, Larry Hastings wrote: IMO the benefit from supporting other compilers on Windows is negligible Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC, raising the priority of mingw-buildable extensions for numerical work? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlQ37vYACgkQ+gerLs4ltQ6V9ACffcq9Cn+kHzDZxaWJ63NVb6Uk SasAoK5kNfBrCupcBz3FcRsUjs2aZxvu =LFqg -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
I don't think this is exactly on the same axis. Being able Python to build with a free compiler won't change this issue. Scientific Python won't be only the free compiler version, Visual Studio would remain the main citizen. It may fragment a little bit more the environment with people needing to pay attention to which compiler/Python version the Python extension/module is compatible with. And jettisonning Visual Studio for building Python is not an option because of the amount of applications relying on both (Visual Studio and Python) in companies. Cheers, Matthieu 2014-10-10 15:36 GMT+01:00 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2014 05:26 AM, Larry Hastings wrote: IMO the benefit from supporting other compilers on Windows is negligible Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC, raising the priority of mingw-buildable extensions for numerical work? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlQ37vYACgkQ+gerLs4ltQ6V9ACffcq9Cn+kHzDZxaWJ63NVb6Uk SasAoK5kNfBrCupcBz3FcRsUjs2aZxvu =LFqg -END PGP SIGNATURE- ___ 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/matthieu.brucher%40gmail.com -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10 October 2014 15:36, Tres Seaver tsea...@palladion.com wrote: On 10/10/2014 05:26 AM, Larry Hastings wrote: IMO the benefit from supporting other compilers on Windows is negligible Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC, raising the priority of mingw-buildable extensions for numerical work? The proposal here is to make it possible to build *python* with a different compiler. Being able to compile extensions with mingw is independent. It used to be relatively easy to build extensions with mingw, although Python's support for that has bitrotted to the point where it's not worth it unless you have a strong need (which is why the SciPy folks are working on it). In my view, anyone capable of modifying the Python build process to support other compilers would also be more than capable of improving the distutils support for building extensions with mingw in a way that is compatible with the current MSVC-built Python. While I can't dictate where anyone else chooses to spend their time, it seems to me that working on allowing non-MSVC builds of Python is a sad waste of limited resources while the mingw extension building issues remain. Paul ___ 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
Re: [Python-Dev] Sad status of Python 3.x buildbots
On 03/09/14 02:37, Antoine Pitrou wrote: I'm not sure that's an answer to the problem. What we need is not more machines, but dedicated buildbot maintainers. I would love to get an email if my buildbots are consistently RED for a few hours. In the past Antoine, Victor and others pinged me about issues in my buildbots (OpenIndiana). I feel shame and I think it is not very productive either. If red state in the buildbots were really trustable, the committer of that changelog should be bugged too. Since we have quite a few false positives, that would be probably annoying and no productive. Decreasing false positives should be a priority. In my case another issue is that my buildbots are hosted as a Solaris ZONE inside a OpenIndiana development machine I don't manage. Their own usage varies and can impact buildbots resource limits like memory, swap space, etc. Thanks for your patience and for notifying me issues when you suffer them. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Sad status of Python 3.x buildbots
On Sat, Oct 11, 2014 at 2:45 AM, Jesus Cea j...@jcea.es wrote: On 03/09/14 02:37, Antoine Pitrou wrote: I'm not sure that's an answer to the problem. What we need is not more machines, but dedicated buildbot maintainers. I would love to get an email if my buildbots are consistently RED for a few hours. In the past Antoine, Victor and others pinged me about issues in my buildbots (OpenIndiana). I feel shame and I think it is not very productive either. Likewise. In the earliest days of my buildbots, I kept a very close eye on them (which was good; they had some occasional network glitches, which I had to resolve), but once they became stable, I stopped watching. Now, I almost never check them - as long as the VM's running, I basically assume all's well. It'd be very helpful if a computer could auto-email any time they're down for any length of time. Is the info available in some way? Could I write a little monitor at my end that asks every hour if my buildbots can be seen? ChrisA ___ 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
Re: [Python-Dev] mUTF-7 support?
Jesus Cea j...@jcea.es wrote: On 10/10/14 02:43, Victor Stinner wrote: What is the current behaviour of imaplib in Python 3.4 with non-ASCII characters in mailbox names? It breaks. Crash burn. Oh ok. So in short, imaplib doesn't work on Python 3: Actually, it doesn't work in Python 2 either. It never supported international mailbox names. Correct. I had to hack in mUTF-7 support in getmail to properly support international IMAP users. Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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
Re: [Python-Dev] Sad status of Python 3.x buildbots
On 10/10/14 17:56, Chris Angelico wrote: Could I write a little monitor at my end that asks every hour if my buildbots can be seen? AFAIK maintainers already get an email if the buildbot vanishes long enough. I am more interested in getting an email when my buildbot is consistently red because somebody committed something it doesn't like two months ago... -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Sad status of Python 3.x buildbots
On 10/10/14 17:45, Jesus Cea wrote: Thanks for your patience and for notifying me issues when you suffer them. Another issue is changes that actually breaks buildbots and I don't actually know where to start debugging. For instance, currently: http://buildbot.python.org/all/builders/x86%20OpenIndiana%202.7/builds/2541/steps/test/logs/stdio == FAIL: test_init (test.test_readline.TestReadline) -- Traceback (most recent call last): File /export/home/buildbot/32bits/2.7.cea-indiana-x86/build/Lib/test/test_readline.py, line 52, in test_init self.assertEqual(stdout, b'') AssertionError: '\x1b[?1034h' != '' No idea what to do now, beside forcing bisection builds and blaming somebody else :). -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature ___ 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-10-03 - 2014-10-10) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4598 (-33) closed 29769 (+90) total 34367 (+57) Open issues with patches: 2152 Issues opened (34) == #7830: Flatten nested functools.partial http://bugs.python.org/issue7830 reopened by belopolsky #22526: file iteration SystemError for huge lines (2GiB+) http://bugs.python.org/issue22526 reopened by doko #22542: Use arc4random under OpenBSD for os.urandom() if /dev/urandom http://bugs.python.org/issue22542 reopened by 700eb415 #22552: ctypes.CDLL returns singleton objects, resulting in usage conf http://bugs.python.org/issue22552 opened by Ivan.Pozdeev #22554: Idle: optionally auto-pop-up completion window for names http://bugs.python.org/issue22554 opened by terry.reedy #22555: Tracking issue for adjustments to binary/text boundary handlin http://bugs.python.org/issue22555 opened by ncoghlan #22557: Local import is too slow http://bugs.python.org/issue22557 opened by serhiy.storchaka #22558: Missing hint to source code - complete http://bugs.python.org/issue22558 opened by Friedrich.Spee.von.Langenfeld #22559: [backport] ssl.MemoryBIO http://bugs.python.org/issue22559 opened by alex #22560: Add loop-agnostic SSL implementation to asyncio http://bugs.python.org/issue22560 opened by pitrou #22568: Use of utime as variable name in Modules/posixmodule.c cause http://bugs.python.org/issue22568 opened by Jeffrey.Armstrong #22570: Better stdlib support for Path objects http://bugs.python.org/issue22570 opened by barry #22571: Remove import * recommendations and examples in doc? http://bugs.python.org/issue22571 opened by terry.reedy #22575: bytearray documentation confuses string for unicode objects http://bugs.python.org/issue22575 opened by mjpieters #22577: local variable changes lost after pdb jump command http://bugs.python.org/issue22577 opened by xdegaye #22578: Add additional attributes to re.error http://bugs.python.org/issue22578 opened by serhiy.storchaka #22581: Other mentions of the buffer protocol http://bugs.python.org/issue22581 opened by serhiy.storchaka #22583: C stack overflow in the Python 2.7 compiler http://bugs.python.org/issue22583 opened by Kevin.Dyer #22585: os.urandom() should use getentropy() of OpenBSD 5.6 http://bugs.python.org/issue22585 opened by haypo #22586: urljoin allow_fragments doesn't work http://bugs.python.org/issue22586 opened by ColonelThirtyTwo #22587: os.path.abspath(None) behavior is inconsistent between platfor http://bugs.python.org/issue22587 opened by KevKeating #22589: mimetypes uses image/x-ms-bmp as the type for bmp files http://bugs.python.org/issue22589 opened by brma #22590: math.copysign buggy with nan under Windows http://bugs.python.org/issue22590 opened by pitrou #22592: Drop support of Borland C compiler http://bugs.python.org/issue22592 opened by haypo #22593: Automate update of doc references to UCD version when it chang http://bugs.python.org/issue22593 opened by r.david.murray #22594: Add a link to the regex module in re documentation http://bugs.python.org/issue22594 opened by serhiy.storchaka #22596: support.transient_internet() doesn't catch connection refused http://bugs.python.org/issue22596 opened by berker.peksag #22598: Add mUTF-7 codec (UTF-7 modified for IMAP) http://bugs.python.org/issue22598 opened by jcea #22599: traceback: errors in the linecache module at exit http://bugs.python.org/issue22599 opened by haypo #22600: In Multiprocessing Queue() doesn't work with list : __.put(lis http://bugs.python.org/issue22600 opened by AlainCALMET #22601: asyncio: loop.run_forever() should consume exception of the te http://bugs.python.org/issue22601 opened by haypo #22602: UTF-7 codec decodes ill-formed sequences starting with + http://bugs.python.org/issue22602 opened by jwilk #22603: Fix a typo in the contextlib docs http://bugs.python.org/issue22603 opened by Francisco.Fernández.Castaño #22604: assertion error in complex division http://bugs.python.org/issue22604 opened by pitrou Most recent 15 issues with no replies (15) == #22604: assertion error in complex division http://bugs.python.org/issue22604 #22603: Fix a typo in the contextlib docs http://bugs.python.org/issue22603 #22602: UTF-7 codec decodes ill-formed sequences starting with + http://bugs.python.org/issue22602 #22601: asyncio: loop.run_forever() should consume exception of the te http://bugs.python.org/issue22601 #22600: In Multiprocessing Queue() doesn't work with list : __.put(lis http://bugs.python.org/issue22600 #22596: support.transient_internet() doesn't catch connection refused http://bugs.python.org/issue22596 #22594: Add a link to the regex module in re documentation http://bugs.python.org/issue22594
Re: [Python-Dev] Sad status of Python 3.x buildbots
It's https://bugs.python.org/issue19884 On Fri, Oct 10, 2014, at 12:08, R. David Murray wrote: On Fri, 10 Oct 2014 18:00:06 +0200, Jesus Cea j...@jcea.es wrote: On 10/10/14 17:56, Chris Angelico wrote: Could I write a little monitor at my end that asks every hour if my buildbots can be seen? AFAIK maintainers already get an email if the buildbot vanishes long enough. I am more interested in getting an email when my buildbot is consistently red because somebody committed something it doesn't like two months ago... I think they are supposed to, but I've never gotten one, not even when my gentoo buildbots suffered a hardware failure. A month or so later Antoine emailed me, and I told him to remove them at least for now, since I don't currently have replacement hardware. (I'm hoping to fix that, but I have to find the time...) That said, there has never as far as I know been an active hook to email the maintainer when the buildbot is red. I don't know if buildbot supports that or not, so that would be the first thing to check. --David ___ 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/benjamin%40python.org ___ 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
Re: [Python-Dev] Sad status of Python 3.x buildbots
On Fri, 10 Oct 2014 18:00:06 +0200, Jesus Cea j...@jcea.es wrote: On 10/10/14 17:56, Chris Angelico wrote: Could I write a little monitor at my end that asks every hour if my buildbots can be seen? AFAIK maintainers already get an email if the buildbot vanishes long enough. I am more interested in getting an email when my buildbot is consistently red because somebody committed something it doesn't like two months ago... I think they are supposed to, but I've never gotten one, not even when my gentoo buildbots suffered a hardware failure. A month or so later Antoine emailed me, and I told him to remove them at least for now, since I don't currently have replacement hardware. (I'm hoping to fix that, but I have to find the time...) That said, there has never as far as I know been an active hook to email the maintainer when the buildbot is red. I don't know if buildbot supports that or not, so that would be the first thing to check. --David ___ 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
Re: [Python-Dev] Sad status of Python 3.x buildbots
On Fri, 10 Oct 2014 12:08:54 -0400 R. David Murray rdmur...@bitdance.com wrote: On Fri, 10 Oct 2014 18:00:06 +0200, Jesus Cea j...@jcea.es wrote: On 10/10/14 17:56, Chris Angelico wrote: Could I write a little monitor at my end that asks every hour if my buildbots can be seen? AFAIK maintainers already get an email if the buildbot vanishes long enough. I am more interested in getting an email when my buildbot is consistently red because somebody committed something it doesn't like two months ago... I think they are supposed to, but I've never gotten one, not even when my gentoo buildbots suffered a hardware failure. As far as I remember it's a relaying problem on the SMTP server. Perhaps Benjamin can confirm. That said, there has never as far as I know been an active hook to email the maintainer when the buildbot is red. I don't know if buildbot supports that or not, so that would be the first thing to check. I don't know if it would support e-mailing the maintainer rather than whoever committed the last changes. Besides, I'm afraid our test suite isn't stable enough for such e-mail notifications to be bearable... Regards Antoine. ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10/10/2014 01:29, Victor Stinner wrote: === MinGW Some people tried to compile Python. See for example: https://bitbucket.org/puqing/python-mingw We even got some patches: http://bugs.python.org/issue3871 (rejected) There are 55 open issues on the bug tracker with mingw in the title. See also: https://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc MinGW reuses the Microsoft C library and it is based on GCC which is very stable, actively developed, supports a lot of archiectures, etc. I guess that it should be possible to reuse third party GCC tools like the famous GDB debugger? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10.10.2014 14:05, Paul Moore wrote: On 10 October 2014 10:50, Victor Stinner victor.stin...@gmail.com wrote: Is MinGW fully compatible with MSVS ABI? I read that it reuses the MSVCRT, but I don't know if it's enough. I guess that a full ABI compatibility means more than just using the C library, calling convention and much more. MinGW can be made to build ABI-compatible extensions. Whether this will continue with MSVC 15 I don't know, as it requires a change to add an interface library for the relevant msvcrXX runtime. And the MinGW community is somewhat fragmented these days, with the core project not supporting 64-bit and various external projects doing so. Having said all this, it *is* possible with some effort to use MinGW to build Python extensions. As noted, the numpy developers have done a lot of work on this as some of the libraries they need must be built with mingw. And the state of distutils support for mingw is very sad, as well, IIRC (last time I looked there were a number of open bugs, and very little movement on them). Rather than put effort into more build options for CPython, I think it would be much more beneficial to the Windows community if effort was put into: 2. Looking at ways to support cross-compiling Windows extensions from Linux using mingw. I've no idea how practical this would be, but if Linux developers could provide Windows builds without having to maintain a Windows environment, that would be great. It is practical. Numpy Windows binaries are built on linux using mingw 3.4.5 and wine. The (vagrant based) setup which is currently used is available here: https://github.com/juliantaylor/numpy-vendor For the next release we do want to look into providing official win64 binaries based on the mingw64 toolchain that has been mentioned a few times already. An attempt to do so in the last released failed due to test issues and there were no experienced debuggers available to solve them. From my perspective cross building for windows is easier than cross building for mac, but thats probably just because I never seriously looked into that. ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10 October 2014 17:28, Mark Lawrence breamore...@yahoo.co.uk wrote: There are 55 open issues on the bug tracker with mingw in the title. It's not easy to tell, but on a spot check a fair proportion of them seem to be about distutils/extension builds. And a lot of the rest are related to http://bugs.python.org/issue3871 which is a rejected issue about adding build support for mingw. Paul ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
From Victor Stinner: I know that it's hard to replace Visual Studio. I don't want to do it right now, but I would like to discuss that with you. I have read the rest of the thread, but I want to start from this point. I'm probably going to run off in random directions since there are a lot of issues raised here (all of which I've heard before and given serious thought and discussion to), so please excuse the brain dump. As one of the driving forces behind keeping MSVC a viable choice for building CPython, I'd be disappointed if we were to change away from it (as would my employer). That said, I'm involved with Python because I want to be involved - I was developing in Python long before Microsoft hired me and I'm incredibly lucky that my day job permits me to be involved in this community - and it's not going to directly hurt my career if everyone decides to move away from MSVC, so I don't believe I'm conflicted here. The main way I'm currently trying to keep MSVC viable is by porting CPython 3.5 to build with the latest version (VC14 - yet to be released, but there are previews available). My progress is in my sandbox at https://hg.python.org/sandbox/steve.dower (VC14 branch), I've been regularly testing with the latest (internal) builds, fixing issues in Python and getting issues fixed in OpenSSL, Tcl and VC. The known PGO bugs have been fixed for VC14, and one of my plans is to do some thorough testing to see if it's safe and worth re-enabling. Some answers to points that were raised in this discussion: * VC 14 Express for Desktop can build both 32-bit and 64-bit versions of CPython - I'm also making changes to Python's VC projects so they can build correctly without VS, though I don't know if we'll have a compiler only package for VC14 * The main advantage of VC14 is that the C runtime will be binary compatible into the future (rather than *mostly* source compatible) - most of the macros are now function calls and opaque types like FILE* are genuinely opaque * Extensions built with VC14 or later will work with CPython built with VC14 or later - If other compilers begin to support the new CRT ABI and can match the calling convention, then it won't matter which compiler is used for extensions - The MS CRT has public sources - they ship with any version of VC14 - which should help * There are plenty of issues that prevent you from building with VC14 currently, just like with any other compiler that isn't VC10. - Platforms and compilers need dedicated maintainers I don't have any official confirmation, but my guess would be that the 64-bit compilers were omitted from the VC 2008 Express to save space (bearing in mind that WinXP was the main target at that time, which had poor 64-bit support, and very few people cared about building 64-bit binaries) and were not available in the IDE for VC 2010 Express by mistake. For building extensions, the former is resolved by the package at http://aka.ms/vcpython27, and the latter works fine since the 64-bit compiler is there, just not exposed in the IDE. Neither of these will be an issue with VC14 - 64-bit is far too important these days. Cross compilation is a valid issue, but I hope that build services like Appveyor also help out here. There is regular talk about the PSF/PyPI providing something similar, though I have doubts about its feasibility under any model other than renting a preconfigured VM. I don't see any reason why projects couldn't apply to the PSF for a grant to cover Appveyor costs or the expenses of similar services. As for extensions with Fortran or BLAS dependencies - the Python ABI requirements only extend to the Python interface. You can easily define a second interface within your project and build dependencies with whatever tools you like (and in theory if your compiler emits COFF modules, you can link objects from separate compilers, though that's probably easier said than done). When you control both sides of the ABI, the tooling is less important. It's just unfortunate that right now the ABI for Python is defined by the tooling - hopefully the VC14 CRT will help stabilise this. Currently the official CPython 2.7 build from python.org is built with VS 2008 Ultimate SP1 and I assume 3.4 is built with VS 2010 SP1, since I know Martin has access to the full version of VS. As Paul mentioned a few times, I'd also be quite happy to see all the effort towards building CPython with other compilers go towards building extensions with other compilers. On Windows, very very few people ever build their own binaries for anything - it's a totally different culture to *nix - so it's far more important that the development teams can build their own product. In this scenario, it's more important that extension developers know exactly what the ABI is so they can match it, than whether it's exactly the same as what their tools use by default. I don't think there's anything actionable in
Re: [Python-Dev] Status of C compilers for Python on Windows
On Oct 10, 2014, at 6:59 PM, Steve Dower steve.do...@microsoft.com wrote: Cross compilation is a valid issue, but I hope that build services like Appveyor also help out here. There is regular talk about the PSF/PyPI providing something similar, though I have doubts about its feasibility under any model other than renting a preconfigured VM. I don't see any reason why projects couldn't apply to the PSF for a grant to cover Appveyor costs or the expenses of similar services. I know very little about Windows, but we can spin up arbitrary Windows boxes, build something on them, and then shut them down as long as there’s some way to automate logging into a Windows box and running some commands… Normally I’d do this with SSH but I don’t know if Windows has anything like that. IOW we can totally spin up preconfigured VMs for a Windows build service. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
On 10/10/2014 03:36 PM, Tres Seaver wrote: On 10/10/2014 05:26 AM, Larry Hastings wrote: IMO the benefit from supporting other compilers on Windows is negligible Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC, raising the priority of mingw-buildable extensions for numerical work? CPython doesn't require OpenBLAS. Not that I am not receptive to the needs of the numeric community... but, on the other hand, who in the hell releases a library with Windows support that doesn't work with MSVC?! //arry/ ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Steve Dower steve.do...@microsoft.com wrote: I don't have any official confirmation, but my guess would be that the 64-bit compilers were omitted from the VC 2008 Express to save space (bearing in mind that WinXP was the main target at that time, which had poor 64-bit support, and very few people cared about building 64-bit binaries) and were not available in the IDE for VC 2010 Express by mistake. For building extensions, the former is resolved by the package at http://aka.ms/vcpython27, and the latter works fine since the 64-bit compiler is there, just not exposed in the IDE. Neither of these will be an issue with VC14 - 64-bit is far too important these days. The 64-bit compiler is in VC 2008 Express as well, just not exposed in the IDE. I know this because when I got the Absoft Fortran compiler I was told to download VC 2008 Express, because Absoft uses the VC9 linker. And indeed there was a 64-bit compiler in VC 2008 Express as well, just not available from the IDE. If I remeber correctly, some fiddling with vcvars.bat was required to turn it on. I never tried to build Python extensions with it, though. In the beginning I thought Absoft had given me the wrong product, because I had ordered a 64-bit Fortran compiler and I knew VC 2008 Express was only 32-bit. But they assured me the 64-bit VC9 compiler was there as well, and indeed it was. Sturla ___ 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
Re: [Python-Dev] Status of C compilers for Python on Windows
Larry Hastings la...@hastings.org wrote: CPython doesn't require OpenBLAS. Not that I am not receptive to the needs of the numeric community... but, on the other hand, who in the hell releases a library with Windows support that doesn't work with MSVC?! It uses ATT assembly syntax instead of Intel assembly syntax. Sturla ___ 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
