<antocuni>
cfbolz: I think that that particular test subclasses int "just because", i.e. because it was a readily available base class. At that time, we didn't think about all the implications of subclassing primitive types
<cfbolz>
antocuni: oh, it's all good! it made me think about how to implement it for real
<antocuni>
good :)
<antocuni>
in PyPy you mean?
<cfbolz>
yes
<antocuni>
cool
<antocuni>
how? :)
<cfbolz>
antocuni: we already have support for "hidden" fields in user-defined subclasses
<cfbolz>
we use it for weakrefs
<antocuni>
ah cool
<antocuni>
so you add a hidden field to store a pointer to hpy_data?
<cfbolz>
yes
<cfbolz>
I mean we could always do that, but I think for object subclasses we want it to be more efficient
<cfbolz>
and have a direct field
<cfbolz>
(actually now that I think of it we can use the same trick to make cpyext more efficient for instances of user-defined classes and avoid the dict lookup)
<antocuni>
I think I'm a bit confused
<antocuni>
when you say "hidden fields", you are talking about RPython or app-level fields?
<cfbolz>
app-level
<cfbolz>
they are stored in the same place that regular instance fields go
<cfbolz>
ie using the map and storage fields of the map
<antocuni>
and "direct fields" are RPython fields?
<cfbolz>
yes
<antocuni>
ok
<antocuni>
then yes, we should try to use a direct field
<cfbolz>
we don't want an rpython field for hpy in *every* instance I think
steve_s has quit [Quit: Client closed]
<antocuni>
right
<antocuni>
but here is where HPy is much easier than cpyext
<cfbolz>
why?
<antocuni>
we need hpy_data only for types which are defined in C
<antocuni>
user-defined types
<antocuni>
in cpyext, you can take a "normal" app-level int and cast it to PyObject*, which is a mess
<antocuni>
in HPy, you cannot
<cfbolz>
right, fine
<cfbolz>
just saying that if we use an app-level hidden field we are good even for cpyext
<cfbolz>
because it needs space only when used
<antocuni>
so, the HPy user-defined type which subclasses int can be an instance of W_HPyObject_int or something like that
<cfbolz>
antocuni: no, that doesn't work
<antocuni>
why?
<cfbolz>
antocuni: that means we need to generate tooooons of rpython classes
<cfbolz>
one for every W_*Object
<cfbolz>
in every module
<antocuni>
no
<antocuni>
one for every builtin type which HPy allows to subclass
<cfbolz>
ok, I thought the plan was to allow a subclass of every type
<antocuni>
uhm, I am a bit confused again now
<antocuni>
you might be right
<antocuni>
yes, I think you are right. Basically, the current W_HPyObject is used for instances of HPy subclasses of objects (which are the majority and the default)
<antocuni>
and we would need the same for every superclass which as a W_*Object in RPython
<antocuni>
which means that basically we need 2x W_*Object classes than what we have now (which might or might not be a good idea, I don't know)\
<antocuni>
fangerer: at the sprint we talked about introducing a .builtin_shape field on HPyType_Spec: did you commit the code somewhere, or you have the sketch of the code which we wrote down?
<fangerer>
yes, I have; but still in internal review. I'll try to accelerate that ...
<antocuni>
thanks
<cfbolz>
antocuni: we used to have much more auto-generated subclasses
<cfbolz>
but I worked hard to get rid of them ;-)
<antocuni>
I don't have a strong opinion, just saying that it's an option on the table
<antocuni>
we might decide to have special subclasses only for a handful of types where it's useful
<cfbolz>
yes, I'd like to see some extensions actually need it first
<antocuni>
ah, I thought that numpy subclasses int and floats but maybe not?
<cfbolz>
antocuni: sure
<cfbolz>
do they have extra memory though?
<antocuni>
good point
<antocuni>
but actually, I don't know if they subclass at all. E.g. numpy.int64 is not a subclass of int
<antocuni>
oh I see
<antocuni>
it *used to be* a subclass of int
<antocuni>
but now it cannot because in py3k int is not an int64