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 *
13 matches
Mail list logo
