numpy-discussion

[Numpy-discussion] NumPy beta release plan

[Travis O. <oli...@ie...>]

Some of you may have noticed that things have been changing rapidly in 
the NumPy world (if you were out of the office in June then all the 
activity may seem overwhelming). 

All of this activity is based on the fact that the upcoming beta release 
will mean a feature freeze for NumPy. 

As a review:

The biggest changes over the past 3 months have been

1) Capitalized-type-names (Float32, Complex64, Int8, etc) are now
   only available in the numpy.oldnumeric namespace (this is the
   namespace that convertcode.py replaces for Numeric).   We are trying
   to wean you off character codes as much as possible.  They are still
   there, of course but should only be used in special cases not as
   a general rule.

2) Un-specified data-types now default to floating point. 

   To help with code you have that relies on integer data-types you
   can either use functions from numpy.oldnumeric where the functions
   are still defined with the integer-default data-types or use
   functions in numpy/lib/convdtype to replace type-less versions of
   ones, zeros, empty with empty(..., dtype=int).

3) C-API names have prefix PyArray_ (like always), NPY_ or npy_. 
 
   The NPY_ and npy_ prefixes are new and were done to remove the
   likelihood of name collisions when NumPy is used with another
   library.  The old (and un-prefixed) names are accessible by
   importing numpy/noprefix.h  instead of numpy/arrayobject.h

   It is fine to use noprefix.h in-place of arrayobject.h if you
   expect to have no naming conflicts. This is what NumPy itself does.

4) The flag combinations with _FLAGS in the name have the _FLAGS
   removed (but are prefixed with NPY_).  Again the old names are
   still available in numpy/noprefix.h

5) The Numarray C-API is now available as numpy/libnumarray.h as
   long as you use the directory returned from numpy.get_numarray_include()
   as an argument to -I in the compile command.


More minor changes:

1) ctypes attribute added for ease of working with ctypes data
2) T attribute added as a convenience for .transpose()


Personally, I don't want to make any more changes so that we can make a 
1.0 beta release that will freeze the API.  Because of my guarantee to 
keep SVN versions of NumPy/SciPy/matplotlib working, changes probably 
cause more headache for me than anyone else. 

Unless there is a serious issue pointed out, the only thing that should 
be changed at this point are bug-fixes, documentation strings, and added 
tests.  Once 1.0b1 is released nothing but those things can be added.

I'd like July to be a much more calm month.  We should get the 1.0b1 out 
in the next couple of weeks.  That way perhaps 1.0b2 can be out by the 
SciPy conference.    I can see the beta release period taking several 
months with only bug-fixes/docstring/testing improvements happening over 
that time. 

So, take this message as a warning for the up-coming feature freeze on 
NumPy and an invitation to contribute docstrings and unit-tests.

I hope the rapid pace of June development did not scare too many 
people.  Please voice your concerns if you have them.

Best regards,

-Travis O.

Re: [Numpy-discussion] NumPy beta release plan

[Stephan T. <st...@si...>]

Hi Travis,

thanks for putting all the effort into NumPy.

 > Unless there is a serious issue pointed out, the only thing that should
 > be changed at this point are bug-fixes, documentation strings, and added
 > tests.  Once 1.0b1 is released nothing but those things can be added.

The beginning of the beta phase might also be the best time to address 
the most severe NumPy.distutils issues, so that all changes can be 
extensively tested during the beta:
  - warning messages are only shown if compilation fails (NumPy should 
build warning free)
  - there are some problems on Windows (ticket #114)
  - 64bit/Python 2.5 issues?

Ciao,
   Stephan

Re: [Numpy-discussion] NumPy beta release plan

[Darren D. <dd...@co...>]

On Saturday 08 July 2006 4:04 am, Stephan Tolksdorf wrote:
> Hi Travis,
>
> thanks for putting all the effort into NumPy.
>
>  > Unless there is a serious issue pointed out, the only thing that should
>  > be changed at this point are bug-fixes, documentation strings, and added
>  > tests.  Once 1.0b1 is released nothing but those things can be added.
>
> The beginning of the beta phase might also be the best time to address
> the most severe NumPy.distutils issues, so that all changes can be
> extensively tested during the beta:

The number of people in my lab using numpy/scipy/matplotlib is starting to 
increase. Last week I was trying to get a couple of graduate students set up. 
They were using MacOS X 10.4 with gcc3.3, and we were never successful in 
getting numpy to build. I think the problem was the same as reported at 
http://mail.python.org/pipermail/pythonmac-sig/2006-March/016703.html. We 
ended up getting things installed by installing scipy with fink.

>   - warning messages are only shown if compilation fails (NumPy should
> build warning free)

One of the guys I was working with tried installing every compiler out there 
to get rid of all the compiler not found messages that were reported during 
the attempted numpy builds. I guess he thought these messages were critical 
errors, since they are rendered in red lettering.

Darren

Re: [Numpy-discussion] NumPy beta release plan

[Charles R H. <cha...@gm...>]

Hi Travis,

Are you going to make a development branch so other things can continue
going into Numpy until the 1.0 release?

Chuck

On 7/8/06, Darren Dale <dd...@co...> wrote:
>
> On Saturday 08 July 2006 4:04 am, Stephan Tolksdorf wrote:
> > Hi Travis,
> >
> > thanks for putting all the effort into NumPy.
> >
> >  > Unless there is a serious issue pointed out, the only thing that
> should
> >  > be changed at this point are bug-fixes, documentation strings, and
> added
> >  > tests.  Once 1.0b1 is released nothing but those things can be added.
> >
> > The beginning of the beta phase might also be the best time to address
> > the most severe NumPy.distutils issues, so that all changes can be
> > extensively tested during the beta:
>
> The number of people in my lab using numpy/scipy/matplotlib is starting to
> increase. Last week I was trying to get a couple of graduate students set
> up.
> They were using MacOS X 10.4 with gcc3.3, and we were never successful in
> getting numpy to build. I think the problem was the same as reported at
> http://mail.python.org/pipermail/pythonmac-sig/2006-March/016703.html. We
> ended up getting things installed by installing scipy with fink.
>
> >   - warning messages are only shown if compilation fails (NumPy should
> > build warning free)
>
> One of the guys I was working with tried installing every compiler out
> there
> to get rid of all the compiler not found messages that were reported
> during
> the attempted numpy builds. I guess he thought these messages were
> critical
> errors, since they are rendered in red lettering.
>
> Darren
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] NumPy beta release plan

[Travis O. <oli...@ie...>]

Charles R Harris wrote:
> Hi Travis,
>
> Are you going to make a development branch so other things can 
> continue going into Numpy until the 1.0 release?
Something like that is a good idea.   I'm open to suggestions...

-Travis

Re: [Numpy-discussion] NumPy beta release plan

[Gary R. <gr...@bi...>]

Hi Travis,

My suggestion: Because you said you want to do a feature freeze, this 
should be pretty easy to handle. Wait for a feature freeze point then 
create a 1.0 branch. From then, new stuff can continue going into the 
trunk. Bug fixes go into the trunk and the 1.0 branch.

Gary R.

Travis Oliphant wrote:
> Charles R Harris wrote:
>> Hi Travis,
>>
>> Are you going to make a development branch so other things can 
>> continue going into Numpy until the 1.0 release?
> Something like that is a good idea.   I'm open to suggestions...
> 
> -Travis

Re: [Numpy-discussion] NumPy beta release plan

[Christian K. <ck...@ho...>]

Travis Oliphant <oliphant.travis <at> ieee.org> writes:

> 
> 
> Some of you may have noticed that things have been changing rapidly in 
> the NumPy world (if you were out of the office in June then all the 
> activity may seem overwhelming). 
> 
> All of this activity is based on the fact that the upcoming beta release 
> will mean a feature freeze for NumPy. 

Recently numpy.distutils switched to install to /usr/local/lib instead of
/usr/lib. Is that intended? I'd prefer to have it back at /usr/lib in
1.0beta.

Anyway, I'm really looking forward to seeing a 1.0 release. Keep up the good
work.

Regards, Christian

Re: [Numpy-discussion] NumPy beta release plan

[Robert K. <rob...@gm...>]

Christian Kristukat wrote:
> Travis Oliphant <oliphant.travis <at> ieee.org> writes:
> 
>> Some of you may have noticed that things have been changing rapidly in 
>> the NumPy world (if you were out of the office in June then all the 
>> activity may seem overwhelming). 
>>
>> All of this activity is based on the fact that the upcoming beta release 
>> will mean a feature freeze for NumPy. 
> 
> Recently numpy.distutils switched to install to /usr/local/lib instead of
> /usr/lib. Is that intended? I'd prefer to have it back at /usr/lib in
> 1.0beta.

It shouldn't have. It shouldn't be doing anything different in that respect than 
core distutils. Are other distutils packages installing to /usr/lib? Nothing in 
the code should be making that choice. It is up to the configuration of Python 
(whatever prefix that the interpreter was installed to) or overridden by system 
or user configuration files.

I believe that Debian recently changed its configuration to default to 
/usr/local (for good reason!). Perhaps that is causing what you see.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] NumPy beta release plan

[Robert K. <rob...@gm...>]

Christian Kristukat wrote:
> Robert Kern <robert.kern <at> gmail.com> writes:
> 
>> I believe that Debian recently changed its configuration to default to 
>> /usr/local (for good reason!). Perhaps that is causing what you see.
> 
> I just found out that this is feature/bug of opensuse 10.1. I'm beginning to
> like it but can you tell what you have to do to force it install to /usr/lib?

It's probably a good idea to leave it as-is. OS distributions like to control 
all files in /usr (except /usr/local) and leave /usr/local for sysadmins and users.

But if you need more control:

http://docs.python.org/inst/alt-install-windows.html (ignore the inappropriate 
filename; it talks about alternate installation locations for all platforms)
http://docs.python.org/inst/config-syntax.html

> Btw. (OFF TOPIC) have you noticed that the scipy mailing list is just
> swallowing mails but not spreading them?

No. That could be a problem on our end. Please let Jeff Strunk 
<js...@en...> know about it. If you can provide details like a local 
copy of the email that got sent and swallowed, that would be very good.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] NumPy beta release plan

[Charles R H. <cha...@gm...>]

Hi,

On 7/9/06, Robert Kern <rob...@gm...> wrote:
>
> Christian Kristukat wrote:
> > Robert Kern <robert.kern <at> gmail.com> writes:
> >
> >> I believe that Debian recently changed its configuration to default to
> >> /usr/local (for good reason!). Perhaps that is causing what you see.
> >
> > I just found out that this is feature/bug of opensuse 10.1. I'm
> beginning to
> > like it but can you tell what you have to do to force it install to
> /usr/lib?


Suse does that, but so does python by default if you compile it from
scratch; Suse is just following the path of least resistence. I don't like
it much, I think distributions should leave /usr/local empty, but when you
compile your own stuff it should arguably end up in /usr/local by default.

Chuck

Re: [Numpy-discussion] NumPy beta release plan

[Christian K. <ck...@ho...>]

Charles R Harris <charlesr.harris <at> gmail.com> writes:

> 
> 
> Hi,
> 
> On 7/9/06, Robert Kern <robert.kern <at> gmail.com> wrote:
> Christian Kristukat wrote:> Robert Kern <robert.kern <at> gmail.com>
writes:>>> I believe that Debian recently changed its configuration to default to
> >> /usr/local (for good reason!). Perhaps that is causing what you see.>> I
just found out that this is feature/bug of opensuse 10.1. I'm beginning to> like
it but can you tell what you have to do to force it install to /usr/lib?
> 
> 
> Suse does that, but so does python by default if you compile it from scratch;

I think every autoconf managed source package out there will install itself to
/usr/local if you don't specify the --prefix. So this is not a python thing. 

> Suse is just following the path of least resistence. I don't like it much, I 
> think distributions should leave /usr/local empty, but when you compile your
> own stuff it should arguably end up in /usr/local by default.

The python modules shipped with suse are installed where python resides and that
is in /usr. But beginning with suse 10.1 user installed packages go to
/usr/local. What I don't like about that method so much is, that when you build
a rpm with distutils it gets installed in /usr/local/, too, even though the
system does handle third party rpms in the systems rpm database.

Christian

Re: [Numpy-discussion] NumPy beta release plan

[Travis O. <oli...@ee...>]

Christian Kristukat wrote:

>Travis Oliphant <oliphant.travis <at> ieee.org> writes:
>
>  
>
>>Some of you may have noticed that things have been changing rapidly in 
>>the NumPy world (if you were out of the office in June then all the 
>>activity may seem overwhelming). 
>>
>>All of this activity is based on the fact that the upcoming beta release 
>>will mean a feature freeze for NumPy. 
>>    
>>
>
>Recently numpy.distutils switched to install to /usr/local/lib instead of
>/usr/lib. Is that intended? I'd prefer to have it back at /usr/lib in
>1.0beta.
>  
>

What gets installed in /usr/lib ?

I'm pretty sure the install directory is determined by the Python 
installation.  Exceptions to this are probably bugs.

-Travis

Re: [Numpy-discussion] NumPy beta release plan

[Christian K. <ck...@ho...>]

Robert Kern <robert.kern <at> gmail.com> writes:

> I believe that Debian recently changed its configuration to default to 
> /usr/local (for good reason!). Perhaps that is causing what you see.
> 

I just found out that this is feature/bug of opensuse 10.1. I'm beginning to
like it but can you tell what you have to do to force it install to /usr/lib?
Btw. (OFF TOPIC) have you noticed that the scipy mailing list is just
swallowing mails but not spreading them?

Regards, Christian

Re: [Numpy-discussion] NumPy beta release plan

[Russell E. O. <ro...@ce...>]

In article <44A...@ie...>,
 Travis Oliphant <oli...@ie...> wrote:

> 3) C-API names have prefix PyArray_ (like always), NPY_ or npy_. 
>  
>    The NPY_ and npy_ prefixes are new and were done to remove the
>    likelihood of name collisions when NumPy is used with another
>    library.  The old (and un-prefixed) names are accessible by
>    importing numpy/noprefix.h  instead of numpy/arrayobject.h

This may be too late or too picky, but...

This seems like too many choices, leading to possible confusion when 
reading other people's extensions or the numpy code itself. Could you 
standardize on one (I like npy_) or two (if you have to keep PyArray_ 
for some reason and can't put it in a backwards-compatibility header 
somewhere).

Overall it's great. I'm really glad to hear you're so close to freezing 
the features.

-- Russell

Re: [Numpy-discussion] NumPy beta release plan

[Travis O. <oli...@ee...>]

Russell E. Owen wrote:

>In article <44A...@ie...>,
> Travis Oliphant <oli...@ie...> wrote:
>
>  
>
>>3) C-API names have prefix PyArray_ (like always), NPY_ or npy_. 
>> 
>>   The NPY_ and npy_ prefixes are new and were done to remove the
>>   likelihood of name collisions when NumPy is used with another
>>   library.  The old (and un-prefixed) names are accessible by
>>   importing numpy/noprefix.h  instead of numpy/arrayobject.h
>>    
>>
>
>This may be too late or too picky, but...
>
>This seems like too many choices, leading to possible confusion when 
>reading other people's extensions or the numpy code itself. Could you 
>standardize on one (I like npy_) or two (if you have to keep PyArray_ 
>for some reason and can't put it in a backwards-compatibility header 
>somewhere).
>
>  
>
There is a logic behind it though.

The C-API function calls all have PyArray_  prefixes (as always in Numeric)

The macro captialized constants have NPY_ prefixes

Newly defined types with lower-case names have npy_ prefixes


-Travis

Re: [Numpy-discussion] NumPy beta release plan

[Sasha <nd...@ma...>]

I would like to add my voice to a call for single prefix (I like
PyArray_ for everything, but can live with npy_).   Presumably npy_
vs. NPY_ variation is supposed to distinguish between macros and C
language elements, but as long as the stem is properly capitalized, I
don't see a problem of using the same prefix for everything.

In any case, if more than one prefix is used, it would be helpful to
get some guidance on what to use when.

On 7/10/06, Russell E. Owen <ro...@ce...> wrote:
> In article <44A...@ie...>,
>  Travis Oliphant <oli...@ie...> wrote:
>
> > 3) C-API names have prefix PyArray_ (like always), NPY_ or npy_.
> >
> >    The NPY_ and npy_ prefixes are new and were done to remove the
> >    likelihood of name collisions when NumPy is used with another
> >    library.  The old (and un-prefixed) names are accessible by
> >    importing numpy/noprefix.h  instead of numpy/arrayobject.h
>
> This may be too late or too picky, but...
>
> This seems like too many choices, leading to possible confusion when
> reading other people's extensions or the numpy code itself. Could you
> standardize on one (I like npy_) or two (if you have to keep PyArray_
> for some reason and can't put it in a backwards-compatibility header
> somewhere).
>
> Overall it's great. I'm really glad to hear you're so close to freezing
> the features.
>
> -- Russell
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] NumPy beta release plan

[Travis O. <oli...@ee...>]

Sasha wrote:

>I would like to add my voice to a call for single prefix (I like
>PyArray_ for everything, but can live with npy_).   Presumably npy_
>vs. NPY_ variation is supposed to distinguish between macros and C
>language elements, but as long as the stem is properly capitalized, I
>don't see a problem of using the same prefix for everything.
>
>In any case, if more than one prefix is used, it would be helpful to
>get some guidance on what to use when.
>  
>

PyArray_  --- Functions and/or macro-functions
NPY_        --- Constants or enums
npy_         ---  typedef'd types (npy_int16, npy_float32, npy_intp)

-Travis