Re: [Python-Dev] 3.5 release schedule PEP

[Nick Coghlan]

On 27 Sep 2014 14:19, "Chris Barker"  wrote:
>
> All this is also making me think that virtualenv and friends is the real
solution to user installed packages anyway.

The main use case that doesn't cover is system scripting on Linux, where
you may want access to all the platform specific libraries.

We're well and truly off topic for python-dev at this point, though...

Probably best to reboot the thread on distutils-sig, rather than continuing
this one.

Cheers,
Nick.

>
> -Chris
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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/ncoghlan%40gmail.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] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

[Xavier Morel]

On 2014-09-27, at 00:11 , Cameron Simpson  wrote:

> On 26Sep2014 13:16, Antoine Pitrou  wrote:
>> On Fri, 26 Sep 2014 01:10:53 -0700
>> Hasan Diwan  wrote:
>>> On 26 September 2014 00:28, Matěj Cepl  wrote:
>>> > Where does your faith that other /bin/sh implementations (dash,
>>> > busybox, etc.) are less buggy comes from?
>>> 
>>> The fact that they are simpler, in terms of lines of code. It's no
>>> guarantee, but the less a given piece of code does, the less bugs it will
>>> have. -- H
>> 
>> And that they have less "features" (which is certainly correlated to
>> their simplicity). IIUC, the misimplemented feature leading to this
>> vulnerability is a bash-ism.
> 
> IIRC you could export functions in ksh. Or maybe only aliases. But that 
> implies most POSIX shells may support it.

From my understanding KSH's function export is so a function becomes
available in the caller of a script e.g. if you define a function in
your .kshrc it's internal to the file (and won't be available in the
interactive shell) unless you export it:
http://users.speakeasy.net/~arkay/216-7.4KshFunctions.html

KSH (and ZSH) will also load functions from files on $FPATH, but AFAIK
that's it.
___
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] 3.5 release schedule PEP

[Paul Moore]

On 27 September 2014 06:08, Terry Reedy  wrote:
> Pip on Windows should act like a normal Windows program.  If I install
> Python for all users, I expect pipped packages to be installed for all users
> too, unless I specify otherwise.  If installation (for all users) requires
> admin privileges, I expect a UAC box to pop up and ask for the admin
> password.  This is pretty routine, at least with Win7.  Most every program I
> install does this either on installation or on first running.  Some Windows
> operations also pop up a box.  There are only a few things that require that
> I actually login as an admin user.

The main problem is that there is little or no prior art on Windows
for *console* programs that require elevation. Those few that do need
it require you to start the program from an elevated prompt, but
that's not a good user experience.

But having said that, I agree with your point, the UAC changes are
designed specifically to get people used to the "think about what
you're doing" approach, and we should be doing the same.
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] Microsoft Visual C++ Compiler for Python 2.7

[Antoine Pitrou]

On Fri, 26 Sep 2014 18:01:31 +
Steve Dower  wrote:
> Hi all,
> 
> (This is advance notice since people on this list will be interested. 
> Official announcements are coming when setuptools makes their next release.)

When you mention "setuptools", do you imply it doesn't work with plain
distutils?

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] Microsoft Visual C++ Compiler for Python 2.7

[Nick Coghlan]

On 27 September 2014 22:12, Antoine Pitrou  wrote:
> On Fri, 26 Sep 2014 18:01:31 +
> Steve Dower  wrote:
>> Hi all,
>>
>> (This is advance notice since people on this list will be interested. 
>> Official announcements are coming when setuptools makes their next release.)
>
> When you mention "setuptools", do you imply it doesn't work with plain
> distutils?

I'd expect it to have the same problem the SDK compilers currently do:
as far as I am aware, distutils simply doesn't recognise them as
available compilers.

I personally believe we should treat handling both this and the SDK
compilers properly as a platform-enablement bug for distutils and
ensure they work properly with the currently maintained branches
(including 2.7).

David Cournapeau offered (on distutils-sig) to tackle that for at
least the SDK compilers (the thread was before Steve's announcement of
the more readily available VC9 compiler download).

Cheers,
Nick.

P.S. Note that pip always runs setup.py via setuptools, so updating
setuptools also deals with the general "pip install" case of building
from source.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Microsoft Visual C++ Compiler for Python 2.7

[Paul Moore]

On 27 September 2014 14:01, Nick Coghlan  wrote:
> I personally believe we should treat handling both this and the SDK
> compilers properly as a platform-enablement bug for distutils and
> ensure they work properly with the currently maintained branches
> (including 2.7).

+1
___
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] Microsoft Visual C++ Compiler for Python 2.7

[Christian Heimes]

On 26.09.2014 20:01, Steve Dower wrote:
> Hi all,
> 
> (This is advance notice since people on this list will be interested. 
> Official announcements are coming when setuptools makes their next release.)
> 
> Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). 
> We've produced this package to help library developers build wheels for 
> Windows, but also to help users unblock themselves when they need to build C 
> extensions themselves.
> 
> The Microsoft Visual C++ Compiler for Python 2.7 is available from: 
> http://aka.ms/vcpython27 

Awesome! :) Thanks a lot, Steve!

Is it possible to compile extensions from Python's numerical stack such
as NumPy, SciPy and SciKit, too?

___
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] Microsoft Visual C++ Compiler for Python 2.7

[Steve Dower]

It'll help with the numerical stack, but only a little. The devs involved have 
largely figured it out already and I can't provide a good Fortran compiler or 
BLAS library, which is what they need.

It'll be much more valuable for the small packages that have one vital C 
extension - currently those are basically unusable without a wheel or a 
compiler. Many DB and XML packages seem to fall into this category. It also 
works for Cython, so anything that uses Cython should work with just these 
compilers.

Cheers,
Steve

Top-posted from my Windows Phone

From: Christian Heimes
Sent: ‎9/‎27/‎2014 7:19
To: python-dev@python.org
Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On 26.09.2014 20:01, Steve Dower wrote:
> Hi all,
>
> (This is advance notice since people on this list will be interested. 
> Official announcements are coming when setuptools makes their next release.)
>
> Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). 
> We've produced this package to help library developers build wheels for 
> Windows, but also to help users unblock themselves when they need to build C 
> extensions themselves.
>
> The Microsoft Visual C++ Compiler for Python 2.7 is available from: 
> http://aka.ms/vcpython27

Awesome! :) Thanks a lot, Steve!

Is it possible to compile extensions from Python's numerical stack such
as NumPy, SciPy and SciKit, too?

___
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/steve.dower%40microsoft.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] Microsoft Visual C++ Compiler for Python 2.7

[Antoine Pitrou]

On Sat, 27 Sep 2014 14:10:48 +0100
Paul Moore  wrote:
> On 27 September 2014 14:01, Nick Coghlan  wrote:
> > I personally believe we should treat handling both this and the SDK
> > compilers properly as a platform-enablement bug for distutils and
> > ensure they work properly with the currently maintained branches
> > (including 2.7).
> 
> +1

+1 as well.

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] Microsoft Visual C++ Compiler for Python 2.7

[Steve Dower]

Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but 
"update Python" is a big/impossible ask for a lot of people, whereas "update 
setuptools" is easy and also covers Python 2.6 and <3.3.

The compiler installer can't set the keys that distutils looks for without 
losing the per-user installation, and it may also corrupt actual installs of 
Visual Studio. A monkey patch via setuptools was the best way to handle this - 
covers pip and Cython and can be ported to other libraries that care but avoid 
setuptools.

Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But 
I'm willing to be convinced - we can always add a version check to the 
setuptools patch.

Cheers,
Steve

Top-posted from my Windows Phone

From: Antoine Pitrou
Sent: ‎9/‎27/‎2014 5:13
To: python-dev@python.org
Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On Fri, 26 Sep 2014 18:01:31 +
Steve Dower  wrote:
> Hi all,
>
> (This is advance notice since people on this list will be interested. 
> Official announcements are coming when setuptools makes their next release.)

When you mention "setuptools", do you imply it doesn't work with plain
distutils?

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/steve.dower%40microsoft.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] Microsoft Visual C++ Compiler for Python 2.7

[Sturla Molden]

Christian Heimes  wrote:

> Is it possible to compile extensions from Python's numerical stack such
> as NumPy, SciPy and SciKit, too?

The official NumPy installer is currently built with VC9, so probably yes.
Other parts of the SciPy stack needs a Fortran compiler as well, so those
might be more tricky. Currently the limitation to Fortran 77 is considered
lifted, Fortran 90 and later will be allowed, so g77 is no longer an
option. In practice you will need Intel ifort or a patched MinGW gfortran. 

Because of this the SciPy community has been creating a customized MinGW
toolchain (including gfortran) for building binary wheels on Windows. It is
patched to make sure that e.g. the MinGW runtime does not conflict with the
VC9 code in the official Python 2.7 installer and that libgfortran uses the
correct C runtime. The stack alignment is also changed to make it VC9
compatible. There was also a customization of the C++ exception handling.
In addition to this the MinGW runtime and libgfortran are statically
linked, so there are no extra runtime DLLs to install.

https://github.com/numpy/numpy/wiki/Mingw-static-toolchain

The toolchain also contains a build of OpenBLAS to use as BLAS and LAPACK
when building NumPy and the SciPy stack. Intel MKL or ATLAS might be
preferred though, due to concerns about the maturity of OpenBLAS.

Sturla Molden

___
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] Microsoft Visual C++ Compiler for Python 2.7

[Sturla Molden]

Steve Dower  wrote:
> It'll help with the numerical stack, but only a little. The devs involved
> have largely figured it out already and I can't provide a good Fortran
> compiler or BLAS library, which is what they need.

We finally have a MinGW based toolchain that can be used. Making sure it
was compatible with VC9 is actually worse than most would expect, as there
are subtile incompatibilities between vanilla MinGW and VC9, beyond just
linking the same C runtime DLL. But it was worked out:

https://github.com/numpy/numpy/wiki/Mingw-static-toolchain

As for BLAS, the NumPy/SciPy devs have procured a permission from Intel to
use MKL in binary wheels. But still there will be official binaries linked
with a free BLAS library available. Currently we use ATLAS, but the plan is
to use OpenBLAS (successor to GotoBLAS2) when it matures. 

OpenBLAS is currently the fastest abd most scalable BLAS library available,
actually better than MKL, but it is severely underfunded. It is not a good
situation for the industry that the only open BLAS library with the
performance of MKL is a Chinese student project in HPC. ATLAS is
unfortunately far less performant and scalable. 

Apple and Cray solved the problem on their platforms by building
high-performance BLAS and LAPACK libraries into their operating systems
(Apple Accelerate Framework and Cray libsci). But AFAIK, Windows does not
have a BLAS library from Microsoft. 

Sturla Molden

___
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] Microsoft Visual C++ Compiler for Python 2.7

[Steve Dower]

The SDK compilers are not easily fixable (I've tried). The installation is 
basically corrupt as far as the non-x86 compilers are concerned.

The package we just put out is exactly the same files as the SDK with those 
issues fixed. There's no reason to encourage the SDK at all now (which was the 
point of the whole exercise from my point of view).

Cheers,
Steve

Top-posted from my Windows Phone

From: Antoine Pitrou
Sent: ‎9/‎27/‎2014 8:32
To: python-dev@python.org
Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On Sat, 27 Sep 2014 14:10:48 +0100
Paul Moore  wrote:
> On 27 September 2014 14:01, Nick Coghlan  wrote:
> > I personally believe we should treat handling both this and the SDK
> > compilers properly as a platform-enablement bug for distutils and
> > ensure they work properly with the currently maintained branches
> > (including 2.7).
>
> +1

+1 as well.

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/steve.dower%40microsoft.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