Re: [Numpy-discussion] Oops - maybe post3 numpy file?

2015-10-09 Thread Ralf Gommers 
On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett 
wrote:

> Hi,
>
> On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris
>  wrote:
> >
> >
> > On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith  wrote:
> >>
> >> On Oct 8, 2015 5:39 PM, "Charles R Harris" 
> >> wrote:
> >> >
> >> > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <
> matthew.br...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0.
> >> >> Using twine to do the upload generated a new release - 1.10.0.post2 -
> >> >> containing only the wheels.  I deleted that new release to avoid
> >> >> confusion, but now, when I try and upload the wheels to the 1.10.0
> >> >> pypi release via the web form, I get this error:
> >> >>
> >> >> Error processing form
> >> >>
> >> >> This filename has previously been used, you should use a different
> >> >> version.
> >> >>
> >> >> Any chance of a post3 upload so I can upload some matching wheels?
> >> >>
> >> >> Sorry about that,
> >> >
> >> >
> >> > Yeah, pipy is why we are on post2 already. Given the problem with
> msvc9,
> >> > I think we are due for 1.10.1 in a day or two. Or, I could revert the
> >> > troublesome commit and do a post3 tomorrow. Hmm... decisions,
> decisions.
> >> > I'll see if Julian has anything to say in the morning and go from
> there.
> >>
> >> I vote that we increment the micro number every time we upload a new
> >> source release, and reserve the postN suffix for binary-only uploads. If
> >> this means we have a tiny 1.10.1 then oh well, there's always 1.10.2 --
> we
> >> probably won't run out of numbers :-).
> >
> >
> > The only difference between 1.10.0 and 1.10.0.post2 is that the latter is
> > signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
> > document. Matthew, can you take care of that?
>
> Is the summary this:
>
> * never have an actual numpy version .postN;
> * releases always have source with a clean Major.Minor.Micro release
> number;
> * binary packages for Minor.Minor.Micro release numbers may have
> filenames ending in .postN
>

The few times in the past when we've needed to fix a binary, we've just
re-uploaded it with the same name. This seems much preferable to me than
confusing users with a post-fix on PyPi that doesn't even match
``numpy.__version__`` and that is so uncommon that I've never seen it used
anywhere.

If re-uploading with the same name is now disallowed by PyPi (is it?) then
bumping the micro version number as Nathaniel proposes would be the way to
go imho.

Ralf



> * these binary packages should be uploaded via the web interface to
> avoid creating a new release
>
> ?
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Oops - maybe post3 numpy file?

2015-10-09 Thread Charles R Harris 
On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers  wrote:

>
>
> On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett 
> wrote:
>
>> Hi,
>>
>> On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris
>>  wrote:
>> >
>> >
>> > On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith  wrote:
>> >>
>> >> On Oct 8, 2015 5:39 PM, "Charles R Harris" 
>> >> wrote:
>> >> >
>> >> > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett <
>> matthew.br...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0.
>> >> >> Using twine to do the upload generated a new release - 1.10.0.post2
>> -
>> >> >> containing only the wheels.  I deleted that new release to avoid
>> >> >> confusion, but now, when I try and upload the wheels to the 1.10.0
>> >> >> pypi release via the web form, I get this error:
>> >> >>
>> >> >> Error processing form
>> >> >>
>> >> >> This filename has previously been used, you should use a different
>> >> >> version.
>> >> >>
>> >> >> Any chance of a post3 upload so I can upload some matching wheels?
>> >> >>
>> >> >> Sorry about that,
>> >> >
>> >> >
>> >> > Yeah, pipy is why we are on post2 already. Given the problem with
>> msvc9,
>> >> > I think we are due for 1.10.1 in a day or two. Or, I could revert the
>> >> > troublesome commit and do a post3 tomorrow. Hmm... decisions,
>> decisions.
>> >> > I'll see if Julian has anything to say in the morning and go from
>> there.
>> >>
>> >> I vote that we increment the micro number every time we upload a new
>> >> source release, and reserve the postN suffix for binary-only uploads.
>> If
>> >> this means we have a tiny 1.10.1 then oh well, there's always 1.10.2
>> -- we
>> >> probably won't run out of numbers :-).
>> >
>> >
>> > The only difference between 1.10.0 and 1.10.0.post2 is that the latter
>> is
>> > signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
>> > document. Matthew, can you take care of that?
>>
>> Is the summary this:
>>
>> * never have an actual numpy version .postN;
>> * releases always have source with a clean Major.Minor.Micro release
>> number;
>> * binary packages for Minor.Minor.Micro release numbers may have
>> filenames ending in .postN
>>
>
> The few times in the past when we've needed to fix a binary, we've just
> re-uploaded it with the same name. This seems much preferable to me than
> confusing users with a post-fix on PyPi that doesn't even match
> ``numpy.__version__`` and that is so uncommon that I've never seen it used
> anywhere.
>
> If re-uploading with the same name is now disallowed by PyPi (is it?) then
> bumping the micro version number as Nathaniel proposes would be the way to
> go imho.
>

You are not allowed to reuse a file name, and numpy.__version__  must match
the file name or pip install will fail. This has all been a bit of
experimentation and I think we have learned something. Agree about not
using the `.postN` suffix. I expect we will have fewer problems next time
around.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] msvc9 comipiler problems

2015-10-09 Thread Charles R Harris 
Hi All,

There is a compilation problem with
1.10.0 on 32 bit windows using the msvc9 compiler. One possible solution to
this is to drop support for python 2.6. The last, and final, release of of
that series was Python 2.6.9 in Oct 2013. The first release was in 2008.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] msvc9 comipiler problems

2015-10-09 Thread Julian Taylor 

On 10/09/2015 06:50 PM, Charles R Harris wrote:

Hi All,

There is a compilation problem
with 1.10.0 on 32 bit
windows using the msvc9 compiler. One possible solution to this is to
drop support for python 2.6. The last, and final, release of of that
series was Python 2.6.9 in Oct 2013. The first release was in 2008.

Thoughts?



doesn't the problem also affect python2.7? I don't recall which msvc is 
required for that but I though it was v9.


If its only the compiler needed for python2.6 thats affected then +1, we 
already dropped binary support for that in numpy 1.9.


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] msvc9 comipiler problems

2015-10-09 Thread Charles R Harris 
On Fri, Oct 9, 2015 at 10:50 AM, Charles R Harris  wrote:

> Hi All,
>
> There is a compilation problem
> with 1.10.0 on 32 bit windows
> using the msvc9 compiler. One possible solution to this is to drop support
> for python 2.6. The last, and final, release of of that series was Python
> 2.6.9 in Oct 2013. The first release was in 2008.
>
> Thoughts?
>

NVM. Looks like Python 2.7 also uses msvc9.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Should we allow arrays with "empty string" dtypes?

2015-10-09 Thread Erik Bray 
Hi all,

This is a post about strings--for the purpose of discussion then I'll
be assuming Python 2 and string means non-unicode strings.  However,
the discussion applies all the same to unicode strings.

For a long time Numpy has had the following behavior: When creating an
array with a zero-width string dtype like 'S0', Numpy automatically
increases the width of the dtype to support the longest string in the
input, like so:

>>> np.array(['abc', 'de'], dtype='S0')  # or equivalently dtype=str
array(['abc', 'de'],
  dtype='|S3')

But it *always* converts to a one character string dtype, at a
minimum.  So even when passing in a list of empty strings:

>>> np.array(['', '', ''], dtype='S0')
array(['', '', ''],
  dtype='|S1')

Or even

>>> np.zeros(3, dtype='S0')
array(['', '', ''],
  dtype='|S1')

This behavior is encoded in PyArray_NewFromDescr_int [1] and is very
old (since 2006) [2].  This made sense at the time, certainly, since
the logic for handling zero-sized strides was shaky, but most issues
with that have long since been worked out.

However, there's an oversight associated with this that it *is*
possible to make a structured dtype that has a zero-width string as
one of its fields.  But since even PyArray_View goes through
PyArray_NewFromDescr, viewing such a field results in a non-empty view
that contains garbage and allows writing garbage into a structured
array.  This is documented in several issues, such as #473 [3].

A fixed I've proposed in #6430 [4] takes a conservative approach of
keeping all the existing behavior *except* in the case of structured
arrays, where views with a dtype of 'S0' would be allowed.  However, a
simpler fix would be to just remove the restriction on creating arrays
of dtype 'S0' in general (with my first example above being one
exception--given a list of strings it will still convert 'S0' to a
dtype that can hold the longest string in the list).

I think I would prefer the general fix, but it would be a slight
change in behavior for any code using PyArray_NewFromDescr to create
string arrays.  But would anyone actually be negatively impacted by
such a change?  It seems to me that any code actually relies on the
existing behavior would smell fishy anyways.

Thanks,
Erik

[1] 
https://github.com/numpy/numpy/blob/8cb3ec6ab804f594daf553e53e7cf7478656bebd/numpy/core/src/multiarray/ctors.c#L940-L956

[2] 
https://github.com/numpy/numpy/commit/b022765aa48707083b1707e4a2a0d8ead2e8

[3] https://github.com/numpy/numpy/issues/473

[4] https://github.com/numpy/numpy/pull/6430
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Oops - maybe post3 numpy file?

2015-10-09 Thread Matthew Brett 
On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris
 wrote:
>
>
> On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers  wrote:
>>
>>
>>
>> On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris
>>>  wrote:
>>> >
>>> >
>>> > On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith  wrote:
>>> >>
>>> >> On Oct 8, 2015 5:39 PM, "Charles R Harris" 
>>> >> wrote:
>>> >> >
>>> >> > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett
>>> >> > 
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0.
>>> >> >> Using twine to do the upload generated a new release - 1.10.0.post2
>>> >> >> -
>>> >> >> containing only the wheels.  I deleted that new release to avoid
>>> >> >> confusion, but now, when I try and upload the wheels to the 1.10.0
>>> >> >> pypi release via the web form, I get this error:
>>> >> >>
>>> >> >> Error processing form
>>> >> >>
>>> >> >> This filename has previously been used, you should use a different
>>> >> >> version.
>>> >> >>
>>> >> >> Any chance of a post3 upload so I can upload some matching wheels?
>>> >> >>
>>> >> >> Sorry about that,
>>> >> >
>>> >> >
>>> >> > Yeah, pipy is why we are on post2 already. Given the problem with
>>> >> > msvc9,
>>> >> > I think we are due for 1.10.1 in a day or two. Or, I could revert
>>> >> > the
>>> >> > troublesome commit and do a post3 tomorrow. Hmm... decisions,
>>> >> > decisions.
>>> >> > I'll see if Julian has anything to say in the morning and go from
>>> >> > there.
>>> >>
>>> >> I vote that we increment the micro number every time we upload a new
>>> >> source release, and reserve the postN suffix for binary-only uploads.
>>> >> If
>>> >> this means we have a tiny 1.10.1 then oh well, there's always 1.10.2
>>> >> -- we
>>> >> probably won't run out of numbers :-).
>>> >
>>> >
>>> > The only difference between 1.10.0 and 1.10.0.post2 is that the latter
>>> > is
>>> > signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
>>> > document. Matthew, can you take care of that?
>>>
>>> Is the summary this:
>>>
>>> * never have an actual numpy version .postN;
>>> * releases always have source with a clean Major.Minor.Micro release
>>> number;
>>> * binary packages for Minor.Minor.Micro release numbers may have
>>> filenames ending in .postN
>>
>>
>> The few times in the past when we've needed to fix a binary, we've just
>> re-uploaded it with the same name. This seems much preferable to me than
>> confusing users with a post-fix on PyPi that doesn't even match
>> ``numpy.__version__`` and that is so uncommon that I've never seen it used
>> anywhere.
>>
>> If re-uploading with the same name is now disallowed by PyPi (is it?) then
>> bumping the micro version number as Nathaniel proposes would be the way to
>> go imho.
>
>
> You are not allowed to reuse a file name, and numpy.__version__  must match
> the file name or pip install will fail. This has all been a bit of
> experimentation and I think we have learned something. Agree about not using
> the `.postN` suffix. I expect we will have fewer problems next time around.

OK - any chance of a 1.10.1 release urgently?  Otherwise the wheel
installs don't work on OSX...

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] ANN: pandas v0.17.0 released

2015-10-09 Thread Jeff Reback 
Hi,

We are proud to announce v0.17.0 of pandas.

This is a major release from 0.16.2 and includes a small number of API
changes, several new features, enhancements, and performance improvements
along with a large number of bug fixes. We recommend that all users upgrade
to this version.

This was a release of 4 months with 515 commits by 112 authors encompassing
233 issues and 362 pull-requests.

We recommend that all users upgrade to this version.

*What is it:*

*pandas* is a Python package providing fast, flexible, and expressive data
structures designed to make working with “relational” or “labeled” data both
easy and intuitive. It aims to be the fundamental high-level building block
for
doing practical, real world data analysis in Python. Additionally, it has
the
broader goal of becoming the most powerful and flexible open source data
analysis / manipulation tool available in any language.

*Highlights*:


   - Release the Global Interpreter Lock (GIL) on some cython operations,
   see here
   

   - Plotting methods are now available as attributes of the .plot
   accessor, see here
   

   - The sorting API has been revamped to remove some long-time
   inconsistencies, see here
   

   - Support for a datetime64[ns] with timezones as a first-class dtype,
   see here
   

   - The default for to_datetime will now be to raise when presented with
   unparseable formats, previously this would return the original input, see
   here
   

   - The default for dropna in HDFStore has changed to False, to store by
   default all rows even if they are all NaN, see here
   

   - Support for Series.dt.strftime to generate formatted strings for
   datetime-likes, see here
   

   - Development installed versions of pandas will now have PEP440
   compliant version strings GH9518
   
   - Development support for benchmarking with the Air Speed Velocity
   library GH8316 
   - Support for reading SAS xport files, see here
   

   - Removal of the automatic TimeSeries broadcasting, deprecated since
   0.8.0, see here
   

   - Display format with plain text can optionally align with Unicode East
   Asian Width, see here
   

   - Compatibility with Python 3.5 GH11097
   
   - Compatibility with matplotlib 1.5.0 GH1
   

See the Whatsnew
 for
much more information and the full Documentation
 link.

*How to get it:*

Source tarballs, windows wheels, macosx wheels are available on PyPI


   - note that currently PyPi is not accepting 3.5 wheels.

Installation via conda is:

   - conda install pandas

windows wheels are courtesy of  Christoph Gohlke and are built on Numpy 1.9
macosx wheels are courtesy of Matthew Brett

*Issues:*

Please report any issues on our issue tracker
:


Thanks to all who made this release happen. It is a very large release!

Jeff

*Thanks to all of the contributors*


   - Alex Rothberg
   - Andrea Bedini
   - Andrew Rosenfeld
   - Andy Li
   - Anthonios Partheniou
   - Artemy Kolchinsky
   - Bernard Willers
   - Charlie Clark
   - Chris
   - Chris Whelan
   - Christoph Gohlke
   - Christopher Whelan
   - Clark Fitzgerald
   - Clearfield Christopher
   - Dan Ringwalt
   - Daniel Ni
   - Data & Code Expert Experimenting with Code on Data
   - David Cottrell
   - David John Gagne
   - David Kelly
   - ETF
   - Eduardo Schettino
   - Egor
   - Egor Panfilov
   - Evan Wright
   - Frank Pinter
   - Gabriel Araujo
   - Garrett-R
   - Gianluca Rossi
   - Guillaume Gay
   - Guillaume Poulin
   - Harsh Nisar
   - Ian Henriksen
   - Ian Hoegen
   - Jaidev Deshpande
   - Jan Rudolph
   - Jan Schulz
   - Jason Swails
   - Jeff Reback
   - Jonas Buyl
   - Joris Van den Bossche
   - Joris Vanker

Re: [Numpy-discussion] Oops - maybe post3 numpy file?

2015-10-09 Thread Charles R Harris 
On Fri, Oct 9, 2015 at 12:17 PM, Matthew Brett 
wrote:

> On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris
>  wrote:
> >
> >
> > On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers 
> wrote:
> >>
> >>
> >>
> >> On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett 
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris
> >>>  wrote:
> >>> >
> >>> >
> >>> > On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith 
> wrote:
> >>> >>
> >>> >> On Oct 8, 2015 5:39 PM, "Charles R Harris" <
> charlesr.har...@gmail.com>
> >>> >> wrote:
> >>> >> >
> >>> >> > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett
> >>> >> > 
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> I'm afraid I made a mistake uploading OSX wheels for numpy
> 1.10.0.
> >>> >> >> Using twine to do the upload generated a new release -
> 1.10.0.post2
> >>> >> >> -
> >>> >> >> containing only the wheels.  I deleted that new release to avoid
> >>> >> >> confusion, but now, when I try and upload the wheels to the
> 1.10.0
> >>> >> >> pypi release via the web form, I get this error:
> >>> >> >>
> >>> >> >> Error processing form
> >>> >> >>
> >>> >> >> This filename has previously been used, you should use a
> different
> >>> >> >> version.
> >>> >> >>
> >>> >> >> Any chance of a post3 upload so I can upload some matching
> wheels?
> >>> >> >>
> >>> >> >> Sorry about that,
> >>> >> >
> >>> >> >
> >>> >> > Yeah, pipy is why we are on post2 already. Given the problem with
> >>> >> > msvc9,
> >>> >> > I think we are due for 1.10.1 in a day or two. Or, I could revert
> >>> >> > the
> >>> >> > troublesome commit and do a post3 tomorrow. Hmm... decisions,
> >>> >> > decisions.
> >>> >> > I'll see if Julian has anything to say in the morning and go from
> >>> >> > there.
> >>> >>
> >>> >> I vote that we increment the micro number every time we upload a new
> >>> >> source release, and reserve the postN suffix for binary-only
> uploads.
> >>> >> If
> >>> >> this means we have a tiny 1.10.1 then oh well, there's always 1.10.2
> >>> >> -- we
> >>> >> probably won't run out of numbers :-).
> >>> >
> >>> >
> >>> > The only difference between 1.10.0 and 1.10.0.post2 is that the
> latter
> >>> > is
> >>> > signed. Sigh. We need to capture this experience in the HOWTO_RELEASE
> >>> > document. Matthew, can you take care of that?
> >>>
> >>> Is the summary this:
> >>>
> >>> * never have an actual numpy version .postN;
> >>> * releases always have source with a clean Major.Minor.Micro release
> >>> number;
> >>> * binary packages for Minor.Minor.Micro release numbers may have
> >>> filenames ending in .postN
> >>
> >>
> >> The few times in the past when we've needed to fix a binary, we've just
> >> re-uploaded it with the same name. This seems much preferable to me than
> >> confusing users with a post-fix on PyPi that doesn't even match
> >> ``numpy.__version__`` and that is so uncommon that I've never seen it
> used
> >> anywhere.
> >>
> >> If re-uploading with the same name is now disallowed by PyPi (is it?)
> then
> >> bumping the micro version number as Nathaniel proposes would be the way
> to
> >> go imho.
> >
> >
> > You are not allowed to reuse a file name, and numpy.__version__  must
> match
> > the file name or pip install will fail. This has all been a bit of
> > experimentation and I think we have learned something. Agree about not
> using
> > the `.postN` suffix. I expect we will have fewer problems next time
> around.
>
> OK - any chance of a 1.10.1 release urgently?  Otherwise the wheel
> installs don't work on OSX...
>

Working on it. There is a problem with msvc9 that needs to be addressed,
otherwise it would be out already.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] msvc9 comipiler problems

2015-10-09 Thread Chris Barker 
>
>
> NVM. Looks like Python 2.7 also uses msvc9.
>

yup, according to Wikipedia:

*Visual C++ 2008* (known also as Visual C++ 9.0)

so py2.7

Are you testing with the "MS Visual C++ compiler for Python 2.7" here:

http://www.microsoft.com/en-us/download/details.aspx?id=44266

I think the only difference is how.where it is installed, but you never
know...

-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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Oops - maybe post3 numpy file?

2015-10-09 Thread Matthew Brett 
On Fri, Oct 9, 2015 at 11:54 AM, Charles R Harris
 wrote:
>
>
> On Fri, Oct 9, 2015 at 12:17 PM, Matthew Brett 
> wrote:
>>
>> On Fri, Oct 9, 2015 at 7:43 AM, Charles R Harris
>>  wrote:
>> >
>> >
>> > On Fri, Oct 9, 2015 at 4:28 AM, Ralf Gommers 
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Oct 9, 2015 at 4:45 AM, Matthew Brett 
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Thu, Oct 8, 2015 at 6:32 PM, Charles R Harris
>> >>>  wrote:
>> >>> >
>> >>> >
>> >>> > On Thu, Oct 8, 2015 at 7:26 PM, Nathaniel Smith 
>> >>> > wrote:
>> >>> >>
>> >>> >> On Oct 8, 2015 5:39 PM, "Charles R Harris"
>> >>> >> 
>> >>> >> wrote:
>> >>> >> >
>> >>> >> > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett
>> >>> >> > 
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Hi,
>> >>> >> >>
>> >>> >> >> I'm afraid I made a mistake uploading OSX wheels for numpy
>> >>> >> >> 1.10.0.
>> >>> >> >> Using twine to do the upload generated a new release -
>> >>> >> >> 1.10.0.post2
>> >>> >> >> -
>> >>> >> >> containing only the wheels.  I deleted that new release to avoid
>> >>> >> >> confusion, but now, when I try and upload the wheels to the
>> >>> >> >> 1.10.0
>> >>> >> >> pypi release via the web form, I get this error:
>> >>> >> >>
>> >>> >> >> Error processing form
>> >>> >> >>
>> >>> >> >> This filename has previously been used, you should use a
>> >>> >> >> different
>> >>> >> >> version.
>> >>> >> >>
>> >>> >> >> Any chance of a post3 upload so I can upload some matching
>> >>> >> >> wheels?
>> >>> >> >>
>> >>> >> >> Sorry about that,
>> >>> >> >
>> >>> >> >
>> >>> >> > Yeah, pipy is why we are on post2 already. Given the problem with
>> >>> >> > msvc9,
>> >>> >> > I think we are due for 1.10.1 in a day or two. Or, I could revert
>> >>> >> > the
>> >>> >> > troublesome commit and do a post3 tomorrow. Hmm... decisions,
>> >>> >> > decisions.
>> >>> >> > I'll see if Julian has anything to say in the morning and go from
>> >>> >> > there.
>> >>> >>
>> >>> >> I vote that we increment the micro number every time we upload a
>> >>> >> new
>> >>> >> source release, and reserve the postN suffix for binary-only
>> >>> >> uploads.
>> >>> >> If
>> >>> >> this means we have a tiny 1.10.1 then oh well, there's always
>> >>> >> 1.10.2
>> >>> >> -- we
>> >>> >> probably won't run out of numbers :-).
>> >>> >
>> >>> >
>> >>> > The only difference between 1.10.0 and 1.10.0.post2 is that the
>> >>> > latter
>> >>> > is
>> >>> > signed. Sigh. We need to capture this experience in the
>> >>> > HOWTO_RELEASE
>> >>> > document. Matthew, can you take care of that?
>> >>>
>> >>> Is the summary this:
>> >>>
>> >>> * never have an actual numpy version .postN;
>> >>> * releases always have source with a clean Major.Minor.Micro release
>> >>> number;
>> >>> * binary packages for Minor.Minor.Micro release numbers may have
>> >>> filenames ending in .postN
>> >>
>> >>
>> >> The few times in the past when we've needed to fix a binary, we've just
>> >> re-uploaded it with the same name. This seems much preferable to me
>> >> than
>> >> confusing users with a post-fix on PyPi that doesn't even match
>> >> ``numpy.__version__`` and that is so uncommon that I've never seen it
>> >> used
>> >> anywhere.
>> >>
>> >> If re-uploading with the same name is now disallowed by PyPi (is it?)
>> >> then
>> >> bumping the micro version number as Nathaniel proposes would be the way
>> >> to
>> >> go imho.
>> >
>> >
>> > You are not allowed to reuse a file name, and numpy.__version__  must
>> > match
>> > the file name or pip install will fail. This has all been a bit of
>> > experimentation and I think we have learned something. Agree about not
>> > using
>> > the `.postN` suffix. I expect we will have fewer problems next time
>> > around.
>>
>> OK - any chance of a 1.10.1 release urgently?  Otherwise the wheel
>> installs don't work on OSX...
>
>
> Working on it. There is a problem with msvc9 that needs to be addressed,
> otherwise it would be out already.

Great, thanks - meanwhile I'll get onto the HOWTO_RELEASE PR in the
next couple of hours.

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] msvc9 comipiler problems

2015-10-09 Thread Carl Kleffner 
The error occurs also for Python-2.7 win32. I tested
numpy-1.10.0+mkl-cp27-none-win32.whl some days ago and reported to C.
Gohlke.

Carl

2015-10-09 20:56 GMT+02:00 Chris Barker :

>
>> NVM. Looks like Python 2.7 also uses msvc9.
>>
>
> yup, according to Wikipedia:
>
> *Visual C++ 2008* (known also as Visual C++ 9.0)
>
> so py2.7
>
> Are you testing with the "MS Visual C++ compiler for Python 2.7" here:
>
> http://www.microsoft.com/en-us/download/details.aspx?id=44266
>
> I think the only difference is how.where it is installed, but you never
> know...
>
> -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
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy-1.11.0.dev0 windows wheels compiled with mingwpy available

2015-10-09 Thread Carl Kleffner 
I made numpy master (numpy-1.11.0.dev0 ,
https://github.com/numpy/numpy/commit/0243bce23383ff5e894b99e40df2f8fd806ad79f)
windows binary wheels available for testing.

Install it with pip:

> pip install -i https://pypi.anaconda.org/carlkl/simple numpy

These builds are compiled with OPENBLAS trunk for BLAS/LAPACK support and
the mingwpy compiler toolchain.

OpenBLAS is deployed within the numpy wheels. To be performant on all usual
CPU architectures OpenBLAS is configured with it's  'dynamic architecture'
and automatic CPU detection.

This version of numpy fakes long double as double just like the MSVC builds.

Some test statistics:

win32 (32 bit)
numpy-1.11.0.dev0, python-2.6: errors=8, failures=1
numpy-1.11.0.dev0, python-2.7: errors=8, failures=1
numpy-1.11.0.dev0, python-3.3: errors=9
numpy-1.11.0.dev0, python-3.4: errors=9

amd64 (64bit)
numpy-1.11.0.dev0, python-2.6: errors=9, failures=6
numpy-1.11.0.dev0, python-2.7: errors=9, failures=6
numpy-1.11.0.dev0, python-3.3: errors=10, failures=6
numpy-1.11.0.dev0, python-3.4: errors=10, failures=6

Carl
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] method to calculate the magnitude squared

2015-10-09 Thread Phillip Feldman 
Hello Nathaniel,

It is hard to say what is normative practice with NumPy, because there are
at least three paradigms:

(1) Some operations are implemented as methods of the `ndarray` class.
`sum` and `mean` are examples.

(2) Some operations are implemented via functions that invoke a private
method of the class.  `abs` is an example of this:

In [8]: x= array([1+1J])
In [9]: x.__abs__()
Out[9]: array([ 1.41421356])

(3) Some operations are implemented as functions that operate directly on
the array, e.g., RMS (root-mean-square).

Because calculating the square of the magnitude is such a widely-used
operation, and is often done in a grossly inefficient manner (e.g., by
taking the absolute value, which involves a square-root, and then
squaring), I believe that there is a strong argument for doing either (1)
or (2).  I'd prefer (1).

Phillip

On Thu, Oct 8, 2015 at 3:05 PM, Nathaniel Smith  wrote:

> Hi Phillip,
>
> My advice would be to stick with the function call. It's consistent with
> most other array operations (esp. when you consider that the vast majority
> of operations on arrays are functions defined in third party libraries like
> yours), and the more things we add to the core array object, the more work
> it is for people implementing new array-style containers. I definitely
> would not recommend subclassing ndarray for this purpose -- there are all
> kinds of subtle problems that you'll run into that mean it's extremely
> difficult to do well, and may well be impossible to do perfectly.
>
> Good luck,
> -n
> On Oct 5, 2015 21:08, "Phillip Feldman" 
> wrote:
>
>> My apologies for the slow response; I was experiencing some technical
>> problems with e-mail.
>>
>> In answer to Antoine's question, my main desire is for a numpy ndarray
>> method, for the convenience, with a secondary goal being improved
>> performance.
>>
>> I have added the function `magsq` to my library, but would like to access
>> it as a method rather than as a function. I understand that I could create
>> a class that inherits from NumPy and add a `magsq` method to that class,
>> but this has a number of disadvantages.
>>
>> Phillip
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion