tp$*, mp$*, sq$*, ob$*

[Philip Peterson]

For the benefit of others, I've made an (as far as I can tell) thus-far-comprehensive list of all the ab$xyz properties used in skulpt.  What all these do, I am not yet entirely certain, but I figured I might as well post them here so people know their names.

mp$subscript

mp$ass_subscript

mp$length

mp$ma_lookup (may be implemented at some point but is not at the time of this writing)

sq$concat

sq$repeat

sq$inplace_concat

sq$inplace_repeat

sq$length

sq$ass_item

sq$contains

sq$slice

sq$ass_slice (returns a slice of ass)

sq$item

ob$type

tp$name

tp$descr_set

tp$descr_get

tp$getattr

tp$setattr

tp$mro

tp$iter

tp$iternext

tp$call

tp$str

tp$richcompare

tp$hash

tp$index

[Brad Miller]

It seems that most of these map to __xx__ type functions that we all know and love.  for example tp$str seems to serve the same function as __str__.  I'm not sure why the names are different.  This is related to the bug I'm fixing right now:  http://code.google.com/p/skulpt/issues/detail?id=98&colspec=ID%20Stars%20Status%20Owner%20Summary

In str.js  there is this code, which works just fine for the builtins:

    else if (x.tp$str !== undefined)

    {

        ret = x.tp$str();

        if (!(ret instanceof Sk.builtin.str)) throw new Sk.builtin.ValueError("__str__ didn't return a str");

        return ret;

    }

But for user defined classes there is nothing that maps __str__ to tp$str.  So it seems that the solution is to add another else if clause

    else if (x.__str__ !== undefined) {

        return Sk.misceval.callsim(x.__str__,x);

    }

But I wish I understood whether the mapping from __str__ to tp$str should happen in the parsing process or whether this is in fact the right way to fix the problem.

Brad
-- 
Brad Miller
Sent with Sparrow

[Scott Graham]

Hi,

The $ names are the underlying implementation of functionality that
corresponds to the equivalent name in the CPython source code. In the
C code, tp$str would be a function pointer on an object named tp_str.

I don't have it quite clear in my mind right now, but generally
speaking, there could be multiple places where an object needs to be
turned into a string, and one of those might be __str__, but others
might include print, etc. Referring to the CPython source might help
(or might make things more confusing).

On the other hand, there may be places where I was too slavish in
trying to follow the CPython code, so some of them may be pointless
redirections. I'm not fully sure what the correct fix for your bug
above is without more investigation.

scott