sometype.__new__ and C subclasses

[Carl Banks]

On May 2, 10:48 am, James Porter <port... at alum.rit.edu> wrote:
> On 5/2/2010 4:34 AM, Carl Banks wrote:
>
> > Why don't you use mysubtype.__new__(mysubtype,...)?
>
> > If you wrote mysubtype in C, and defined a different tp_new than
> > ndarray, then this exception will trigger.  And it ought to; you don't
> > want to use ndarray's tp_new to create an object of your subclass, if
> > you've defined a different tp_new.
>
> Unfortunately, I can't do that, since that call is in NumPy itself and
> it's part of their "standard" way of making instances of subclasses of
> ndarray. Functions like numpy.zeros_like use ndarray.__new__(subtype,
> ...) to create new arrays based on the shape of other arrays.
>
> The Python version of the subclass is shown here:
> <http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#slightly...>,
> and I'm trying to write something pretty similar in C. I'm trying to
> stay in C since everything else is in C, so it's easier to stay in C
> then to jump back and forth all the time.
>
> Maybe the real answer to this question is "NumPy is doing it wrong" and
> I should be on their list; still, it seems strange that the behavior is
> different between Python and C.

I would say numpy is wrong here, so I suggest filing a bug report.

In fact I can't think of any benefit to EVER calling X.__new__(Y)
where X is not Y.  Maybe old-style classes?  Someone who wants to
ensure they're getting an instance of a certain type can check
issubclass(Y,X) then call Y.__new__(Y).

Unfortunately, you just can't get rid of the test in tp_new_wrapper.


Carl Banks