[Numpy-discussion] Making datetime64 timezone naive

2015-10-12 Thread Stephan Hoyer 
As has come up repeatedly over the past few years, nobody seems to be very
happy with the way that NumPy's datetime64 type parses and prints datetimes
in local timezones.

The tentative consensus from last year's discussion was that we should make
datetime64 timezone naive, like the standard library's datetime.datetime:
http://thread.gmane.org/gmane.comp.python.numeric.general/57184

That makes sense to me, and it's exactly what I'd like to see happen for
NumPy 1.11. Here's my PR to make that happen:
https://github.com/numpy/numpy/pull/6453

As a temporary measure, we still will parse datetimes that include a
timezone specification by converting them to UTC, but will issue a
DeprecationWarning. This is important for a smooth transition, because at
the very least I suspect the "Z" modifier for UTC is widely used. Another
option would be to preserve this conversion indefinitely, without any
deprecation warning.

There's one (slightly) contentious API decision to make: What should we do
with the numpy.datetime_to_string function? As far as I can tell, it was
never documented as part of the NumPy API and has not been used very much
or at all outside of NumPy's own test suite, but it is exposed in the main
numpy namespace. If we can remove it, then we can delete and simplify a lot
more code related to timezone parsing and display. If not, we'll need to do
a bit of work so we can distinguish between the string representations of
timezone naive and UTC.

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

Re: [Numpy-discussion] Making datetime64 timezone naive

2015-10-12 Thread Nathaniel Smith 
On Mon, Oct 12, 2015 at 12:10 AM, Stephan Hoyer  wrote:
> As has come up repeatedly over the past few years, nobody seems to be very
> happy with the way that NumPy's datetime64 type parses and prints datetimes
> in local timezones.
>
> The tentative consensus from last year's discussion was that we should make
> datetime64 timezone naive, like the standard library's datetime.datetime:
> http://thread.gmane.org/gmane.comp.python.numeric.general/57184
>
> That makes sense to me, and it's exactly what I'd like to see happen for
> NumPy 1.11. Here's my PR to make that happen:
> https://github.com/numpy/numpy/pull/6453
>
> As a temporary measure, we still will parse datetimes that include a
> timezone specification by converting them to UTC, but will issue a
> DeprecationWarning. This is important for a smooth transition, because at
> the very least I suspect the "Z" modifier for UTC is widely used. Another
> option would be to preserve this conversion indefinitely, without any
> deprecation warning.

I'm dubious about supporting conversions in the long run -- even "Z"
-- because UTC datetimes and naive datetimes are really not the same
thing. OTOH maybe if we dropped this it would break everyone's code
and they would hate us -- I actually have no idea what people are
doing with datetime64 outside of pandas. One way to find out is to
start issuing DeprecationWarnings and see if anyone notices :-).
(Though of course this is far from fool-proof.)

> There's one (slightly) contentious API decision to make: What should we do
> with the numpy.datetime_to_string function? As far as I can tell, it was
> never documented as part of the NumPy API and has not been used very much or
> at all outside of NumPy's own test suite, but it is exposed in the main
> numpy namespace. If we can remove it, then we can delete and simplify a lot
> more code related to timezone parsing and display. If not, we'll need to do
> a bit of work so we can distinguish between the string representations of
> timezone naive and UTC.

One possible strategy here would be to do some corpus analysis to find
out whether anyone is actually using it, like I did for the ufunc ABI
stuff:
  https://github.com/njsmith/codetrawl
  https://github.com/njsmith/ufunc-abi-analysis

"datetime_to_string" is an easy token to search for, though it looks
like enough people have their own functions named that that you'd have
to do a bit of filtering to ignore non-numpy-related uses. A
filter("content", "import.*numpy") would collect all files that import
numpy into a single group for further examination.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Numpy 1.10.1 released.

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

I'm pleased to announce the release of Numpy 1.10.1. This release fixes
some build problems and serves to reset the release number on pipy to
something usable. As a note for future release managers, I had to upload
these files from the command line, as using the file upload option at pipy
resulted in a failure to parse the version.

NumPy 1.10.1 Release Notes
**

This release deals with a few build problems that showed up in 1.10.0. Most
users would not have seen these problems. The differences are:

* Compiling with msvc9 or msvc10 for 32 bit Windows now requires SSE2.
  This was the easiest fix for what looked to be some miscompiled code when
  SSE2 was not used. If you need to compile for 32 bit Windows systems
  without SSE2 support, mingw32 should still work.

* Make compiling with VS2008 python2.7 SDK easier

* Change Intel compiler options so that code will also be generated to
  support systems without SSE4.2.

* Some _config test functions needed an explicit integer return in
  order to avoid the openSUSE rpmlinter erring out.

* We ran into a problem with pipy not allowing reuse of filenames and a
  resulting proliferation of *.*.*.postN releases. Not only were the names
  getting out of hand, some packages were unable to work with the postN
  suffix.


Numpy 1.10.1 supports Python 2.6 - 2.7 and 3.2 - 3.5.


Commits:

45a3d84 DEP: Remove warning for `full` when dtype is set.
0c1a5df BLD: import setuptools to allow compile with VS2008 python2.7 sdk
04211c6 BUG: mask nan to 1 in ordered compare
826716f DOC: Document the reason msvc requires SSE2 on 32 bit platforms.
49fa187 BLD: enable SSE2 for 32-bit msvc 9 and 10 compilers
dcbc4cc MAINT: remove Wreturn-type warnings from config checks
d6564cb BLD: do not build exclusively for SSE4.2 processors
15cb66f BLD: do not build exclusively for SSE4.2 processors
c38bc08 DOC: fix var. reference in percentile docstring
78497f4 DOC: Sync 1.10.0-notes.rst in 1.10.x branch with master.


Cheers,

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

Re: [Numpy-discussion] Numpy 1.10.1 released.

2015-10-12 Thread Matthew Brett 
Hi,

On Mon, Oct 12, 2015 at 9:27 AM, Charles R Harris
 wrote:
> Hi All,
>
> I'm pleased to announce the release of Numpy 1.10.1. This release fixes some
> build problems and serves to reset the release number on pipy to something
> usable. As a note for future release managers, I had to upload these files
> from the command line, as using the file upload option at pipy resulted in a
> failure to parse the version.
>
> NumPy 1.10.1 Release Notes
> **
>
> This release deals with a few build problems that showed up in 1.10.0. Most
> users would not have seen these problems. The differences are:
>
> * Compiling with msvc9 or msvc10 for 32 bit Windows now requires SSE2.
>   This was the easiest fix for what looked to be some miscompiled code when
>   SSE2 was not used. If you need to compile for 32 bit Windows systems
>   without SSE2 support, mingw32 should still work.
>
> * Make compiling with VS2008 python2.7 SDK easier
>
> * Change Intel compiler options so that code will also be generated to
>   support systems without SSE4.2.
>
> * Some _config test functions needed an explicit integer return in
>   order to avoid the openSUSE rpmlinter erring out.
>
> * We ran into a problem with pipy not allowing reuse of filenames and a
>   resulting proliferation of *.*.*.postN releases. Not only were the names
>   getting out of hand, some packages were unable to work with the postN
>   suffix.
>
>
> Numpy 1.10.1 supports Python 2.6 - 2.7 and 3.2 - 3.5.
>
>
> Commits:
>
> 45a3d84 DEP: Remove warning for `full` when dtype is set.
> 0c1a5df BLD: import setuptools to allow compile with VS2008 python2.7 sdk
> 04211c6 BUG: mask nan to 1 in ordered compare
> 826716f DOC: Document the reason msvc requires SSE2 on 32 bit platforms.
> 49fa187 BLD: enable SSE2 for 32-bit msvc 9 and 10 compilers
> dcbc4cc MAINT: remove Wreturn-type warnings from config checks
> d6564cb BLD: do not build exclusively for SSE4.2 processors
> 15cb66f BLD: do not build exclusively for SSE4.2 processors
> c38bc08 DOC: fix var. reference in percentile docstring
> 78497f4 DOC: Sync 1.10.0-notes.rst in 1.10.x branch with master.

Thanks a lot for guiding this through.

I uploaded the OSX wheels to pypi via :
https://github.com/MacPython/numpy-wheels

Cheers,

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

Re: [Numpy-discussion] Making datetime64 timezone naive

2015-10-12 Thread Alexander Belopolsky 
On Mon, Oct 12, 2015 at 3:10 AM, Stephan Hoyer  wrote:

> The tentative consensus from last year's discussion was that we should
> make datetime64 timezone naive, like the standard library's
> datetime.datetime



If you are going to make datetime64 more like datetime.datetime, please
consider adding the "fold" bit.  See PEP 495. [1]

[1]: https://www.python.org/dev/peps/pep-0495/
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Problem with os.environ.clear in numpy initialization

2015-10-12 Thread Michael Behrisch 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,
I am sorry I sent the wrong pull request. Here is the correct one:
https://github.com/numpy/numpy/pull/6460

Best regards,
Michael


Am 12.10.2015 um 20:19 schrieb Michael Behrisch:
> Hi list, I encountered a problem in my code which depends on numpy.
> Due to an unusual variable in my environment and this python bug 
> https://bugs.python.org/issue20658 the os.environ.clear call in 
> numpy/core/__init__.py fails. I wrote a patch and submitted a pull 
> request: https://github.com/behrisch/numpy/pull/1
> 
> Although it is mainly a workaround for the bug mentioned, I would
> be happy if it could get accepted because I have only limited
> control of the environment.
> 
> Best regards, Michael 
> ___ NumPy-Discussion
> mailing list NumPy-Discussion@scipy.org 
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYcFyYACgkQPBD+ltFwpilpqACgjWgriUX8qhz8tDIcsTnSXijM
6G4An2XlDvg7owA7e13mPrMjEzIKHx3H
=HAMn
-END PGP SIGNATURE-
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Problem with os.environ.clear in numpy initialization

2015-10-12 Thread Michael Behrisch 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi list,
I encountered a problem in my code which depends on numpy. Due to an
unusual variable in my environment and this python bug
https://bugs.python.org/issue20658 the os.environ.clear call in
numpy/core/__init__.py fails. I wrote a patch and submitted a pull
request: https://github.com/behrisch/numpy/pull/1

Although it is mainly a workaround for the bug mentioned, I would be
happy if it could get accepted because I have only limited control of
the environment.

Best regards,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYb+c0ACgkQPBD+ltFwpilo1wCZAbvS192vVwnWCYT0y7L5At6m
TdsAoOmLjTnq7iVlh2QmnsM1qJ72PTyE
=wDnI
-END PGP SIGNATURE-
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumFOCUS fiscal sponsorship agreement

2015-10-12 Thread Ralf Gommers 
Hi,

Thanks Nathaniel and everyone else who contributed for pushing forward with
formalizing Numpy governance and with this FSA. I'm quite excited about
both!

Before I start commenting on the FSA, I'd like to point out that I'm both
on the numpy steering committee and the NumFOCUS board. I don't see that as
a problem for being involved in the discussions or signing the FSA, however
I will obviously abstain from voting or (non-)consenting in case of a
possible conflict of interest.


On Thu, Oct 8, 2015 at 7:57 AM, Nathaniel Smith  wrote:

> Hi all,
>
> Now that the governance document is in place, we need to get our legal
> ducks in a row by signing a fiscal sponsorship agreement with
> NumFOCUS.
>
> The basic idea here is that there are times when you really need some
> kind of corporation to represent the project -- the legal system for
> better or worse does not understand "a bunch of folks on a mailing
> list" as a legal entity capable of accepting donations,


Additional clarification: NumFOCUS is a 501(c)3 organization, which means
that in the US donations that are tax-deductable can be made to it (and
hence to Numpy after this FSA is signed). From European or other countries
donations can be made, but they won't be deductable.


> or holding
> funds or other assets like domain names. The obvious solution is to
> incorporate a company to represent the project -- but incorporating a
> company involves lots of super-annoying paperwork. (Like, *super*
> annoying.) So a standard trick is that a single non-profit corporation
> acts as an umbrella organization providing these services to multiple
> projects at once, and this is called "fiscal sponsorship". You can
> read more about it here:
> https://en.wikipedia.org/wiki/Fiscal_sponsorship
>
> NumFOCUS's standard comprehensive FSA agreement can be seen here:
>
>
> https://docs.google.com/document/d/11YqMX9UrgfCSgiQEUzmOFyg6Ku-vED6gMxhO6J9lCgg/edit?usp=sharing


There's one upcoming change to this FSA: the overhead percentage (now 4-7%)
charged will go up significantly, to around 10-15%. Re4ason: NumFOCUS
cannot cover its admin/legal costs as well as support its projects based on
what the doc says now. This is still at the lower end of the scale for
non-profits, and universities typically charge way more on grants. So I
don't see any issue here, but it's good to know now rather than right after
we sign.


> and we have the option of negotiating changes if there's anything we don't
> like.
>
> They also have a FAQ:
>
> https://docs.google.com/document/d/1zdXp07dLvkbqBrDsw96P6mkqxnWzKJuM-1f4408I6Qs/edit?usp=sharing
>
> I've read through the document and didn't see anything that bothered
> me, except that I'm not quite sure how to make the split between the
> steering council and numfocus subcommittee that we have in our
> governance model sync up with their language about the "leadership
> body", and in particular the language in section 10 about simple
> majority votes. So I've queried them about that already.
>

I'd like to clarify that the Numfocus subcommittee is only meant to
facility interaction with NumFOCUS and to ensure that if funds are spent,
they are spent in a way consistent with the mission and non-profit nature
of NumFOCUS. The same applies to possible legal impacts of decisions made
in the Numpy project.

Regarding the question about the "simple majority votes" language, we can
simply replace that with the appropriate text describing how decisions are
made in the Numpy project.

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