Brian Blais wrote:
> Would this break previously saved pickles, so you couldn't load them? I ran
> into
> that problem last year when there was a change to numpy. Is that something
> that
> would happen here?
No.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a h
> Would this break previously saved pickles, so you couldn't load them? I ran
into
> that problem last year when there was a change to numpy. Is that something
that
> would happen here?
>
> bb
>
Regardless of whether or not this change will "break pickles", it seems hi
On Thu, Feb 01, 2007 at 05:51:22PM -0700, Travis Oliphant wrote:
> Christopher Barker wrote:
>
> >Travis Oliphant wrote:
> >
> >
> >>I'm thinking that we should have several. For example all the fromXXX
> >>functions should probably be classmethods
> >>
> >>ndarray.frombuffer
> >>ndarray.fromf
Travis Oliphant wrote:
> Sebastian Haase wrote:
>
>> Travis,
>> Could you explain what a possible downside of this would be !?
>
> I can't think of any downsides. I have to understand how class-methods
> are actually implemented, though before I could comment on speed
> implications of class m
On 2/1/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Christopher Barker wrote:
> > Sebastian Haase wrote:
> >
> >> Could you explain what a possible downside of this would be !?
> >> It seems that if you don't need to refer to a specific "self" object
> >> that a class-method is what it should - is
Christopher Barker wrote:
> Sebastian Haase wrote:
>
>> Could you explain what a possible downside of this would be !?
>> It seems that if you don't need to refer to a specific "self" object
>> that a class-method is what it should - is this not always right !?
>
> Well, what these really are are
Sebastian Haase wrote:
> Could you explain what a possible downside of this would be !?
> It seems that if you don't need to refer to a specific "self" object
> that a class-method is what it should - is this not always right !?
Well, what these really are are alternate constructors. I don't thin
Christopher Barker wrote:
>Travis Oliphant wrote:
>
>
>>I'm thinking that we should have several. For example all the fromXXX
>>functions should probably be classmethods
>>
>>ndarray.frombuffer
>>ndarray.fromfile
>>
>>
>
>would they still be accessible in their functional form in the numpy
Sebastian Haase wrote:
>Travis,
>Could you explain what a possible downside of this would be !?
>It seems that if you don't need to refer to a specific "self" object
>that a class-method is what it should - is this not always right !?
>
>
>
I don't understand the last point. Classmethods would
Travis,
Could you explain what a possible downside of this would be !?
It seems that if you don't need to refer to a specific "self" object
that a class-method is what it should - is this not always right !?
-Sebastian
On 2/1/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Travis Oliphant wrote:
>
Travis Oliphant wrote:
> I'm thinking that we should have several. For example all the fromXXX
> functions should probably be classmethods
>
> ndarray.frombuffer
> ndarray.fromfile
would they still be accessible in their functional form in the numpy
namespace?
--
Christopher Barker, Ph.D.
Oc
Travis Oliphant wrote:
> What is the attitude of this group about the ndarray growing some class
> methods?
Works for me.
--
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
On Thursday 01 February 2007 18:48:56 Travis Oliphant wrote:
> What is the attitude of this group about the ndarray growing some class
> methods?
> ndarray.frombuffer
> ndarray.fromfile
Sounds great. But what would really make my semester is to have
ndarray.__new__ accept optional keywords (as *
What is the attitude of this group about the ndarray growing some class
methods?
I'm thinking that we should have several. For example all the fromXXX
functions should probably be classmethods
ndarray.frombuffer
ndarray.fromfile
etc.
-Travis
___
14 matches
Mail list logo
