On Sat, Aug 29, 2009 at 00:41, David Cournapeau wrote:
> On Fri, Aug 28, 2009 at 11:18 AM, Robert Kern wrote:
>> On Fri, Aug 28, 2009 at 09:15, Christopher Barker
>> wrote:
>>> Joe Harrington wrote:
However, there are two natural forklets coming up.
The first is Python 3.0, which wi
On Fri, Aug 28, 2009 at 11:18 AM, Robert Kern wrote:
> On Fri, Aug 28, 2009 at 09:15, Christopher Barker
> wrote:
>> Joe Harrington wrote:
>>> However, there are two natural forklets coming up.
>>>
>>> The first is Python 3.0, which will necessitate some API changes.
>>
>> Absolutely! This seems l
--- On Fri, 8/28/09, Christopher Barker wrote:
> long live numpy3k!
>
> -Chris
Or at least until Py4K makes us "fork" again. ;)
DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discu
Fons Adriaensen wrote:
> Some weeks ago there was a post on this list requesting feedback
> on possible future directions for numpy. As I was quite busy at that
> time I'll reply to it now.
>
> My POV is that of a novice user, who at the same time wants quite
> badly to use the numpy framework for
Christopher Barker wrote:
>> Following the full
>> PEP procedure
>or a parallel NPEP system.
Actually, I originally intended just to mean "follow the procedure"
not "do it in their system". But, in thinking about it, if it's
compatible with their system to develop a whole subpackage in their
On Fri, Aug 28, 2009 at 09:15, Christopher Barker wrote:
> Joe Harrington wrote:
>> However, there are two natural forklets coming up.
>>
>> The first is Python 3.0, which will necessitate some API changes.
>
> Absolutely! This seems like a no-brainer. I don't think we are talking
> about really ma
Joe Harrington wrote:
> However, there are two natural forklets coming up.
>
> The first is Python 3.0, which will necessitate some API changes.
Absolutely! This seems like a no-brainer. I don't think we are talking
about really major changes to the numpy API anyway, generally clean-up,
and the
> ...numpy clean-up...
> ...cruft...
> ...API breakage...
> ...etc
At the risk of starting a flame war, the cleanest way out of the
legacy API trap is some level of fork, with the old code maintained
for some years while new uses (new users and new code by old users)
get done in the new packag
> Neil Martinsen-Burrell skrev:
>> The persistence of the idea that removing Numpy's legacy features will
>> only be annoyance is inimical to the popularity of the whole Numpy
>> project. [...] Once scientists have working codes it is more than an
>> annoyance to have to change those codes. In
--- On Thu, 8/27/09, Johan Grönqvist wrote:
> If the proposed changes seem important, I would appreciate
> having a
> namespace called numpy.legacy or numpy.deprecated or
> numpy.1dotX, that
> retains all the old functions. That would only be a small
> annoyance (to
> me) if importing the righ
Neil Martinsen-Burrell skrev:
>
> The persistence of the idea that removing Numpy's legacy features will
> only be annoyance is inimical to the popularity of the whole Numpy
> project. [...] Once scientists have working codes it is more than an
> annoyance to have to change those codes. In so
On 2009-08-27 19:56 , David Goldsmith wrote:
> --- On Thu, 8/27/09, Fons Adriaensen wrote:
[...]
>> 3. Finally remove all the redundancy and legacy stuff from the
>> world of numerical Python. It is *very* confusing to a new user.
>
> I like this also (but I also know that actually trying to ach
--- On Thu, 8/27/09, Fons Adriaensen wrote:
> 2. Adopting that format will make it even more important
> to
> clearly define in which cases data gets copied and when
> not.
> This should be based on some simple rules that can be
> evaluated
> by a code author without requiring a lookup in the
> r
Some weeks ago there was a post on this list requesting feedback
on possible future directions for numpy. As I was quite busy at that
time I'll reply to it now.
My POV is that of a novice user, who at the same time wants quite
badly to use the numpy framework for his numerical work which in
this c
14 matches
Mail list logo
