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
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 **whatever) on top of the shape/buffer/order... That'd be a big help for subclassing. On a side note, I came to the fact that Santa Claus doesn't really live in the North Pole, so I would understand if it wasn't feasible...
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 an underlying truth." -- Umberto Eco
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
Travis Oliphant wrote:
What is the attitude of this group about the ndarray growing some class methods?
Works for me.
-- Robert Kern
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 get inherited by sub-classes by default, as far as I know. 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 methods. -Travis
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 methods.
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 -- ----------------- bblais@bryant.edu http://web.bryant.edu/~bblais
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 highly likely to me that other future changes will prevent you from loading arrays pickled with older versions of numpy and python. That is one of several reasons why I generally think relying on direct pickling for storage is not a good idea. Another reason is that loading data becomes an all or nothing proposition, you can't read half of an array off the disk for example (not easily anyway). If you need to store numpy arrays directly, pytables (www.pytables.org) is the best solution that I am aware of, and it will (mostly) save you from worrying about these kinds of issues in the future. - Matt
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 harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
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 think I've seen class methods used that way, but then I haven't seen them used much at all. Sometimes I have wished for an overloaded constructor, i.e.: array(SomeBuffer) results in the same thing as frombuffer(SomeBuffer) but Python doesn't really "do" overloaded methods, and there are some times when there wouldn't be only one way the input could be interpreted. That all being the case, it seems to make some sense to put these in as class methods, but : a = numpy.ndarray.fromfile(MyFile) does feel a bit awkward. Wx Python handles this by having a few constructors: wx.EmptyBitmap() wx.BitmapFromImage() wx.BitmapFromBuffer() etc... but that's kind of clunky too. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
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 alternate constructors. I don't think I've seen class methods used that way, but then I haven't seen them used much at all.
Alternate constructors is probably the primary use case for class methods that I've seen. It's certainly the most frequent reason I've made them.
Sometimes I have wished for an overloaded constructor, i.e.:
array(SomeBuffer)
results in the same thing as
frombuffer(SomeBuffer)
but Python doesn't really "do" overloaded methods, and there are some times when there wouldn't be only one way the input could be interpreted.
Well, array() is already very, very overloaded. That's why it's difficult to use sometimes. BTW, you might want to check out the module simplegeneric for a good way to implement certain kinds of overloading. Just not numpy.array(), please ;-). http://cheeseshop.python.org/pypi/simplegeneric/ -- 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
On 2/1/07, Robert Kern
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 alternate constructors. I don't think I've seen class methods used that way, but then I haven't seen them used much at all.
Alternate constructors is probably the primary use case for class methods that I've seen. It's certainly the most frequent reason I've made them.
Same here (not in any publicly released code) and I happen to find them handy in that role. Absent truly overloaded constructors à la C++, they appear to be an acceptable compromise to me. Cheers, f
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. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
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 namespace?
Yes, until a major revision at which point they could (if deemed useful) be removed after a deprecation warning period. -Travis
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.fromfile
would they still be accessible in their functional form in the numpy namespace?
Yes, until a major revision at which point they could (if deemed useful) be removed after a deprecation warning period.
That would be a happy day. I'd love to see the numpy namespace go on a diet... Cheers Stéfan
participants (9)
-
Brian Blais -
Christopher Barker -
Fernando Perez -
Matt Knox -
Pierre GM -
Robert Kern -
Sebastian Haase -
Stefan van der Walt -
Travis Oliphant