getting started with classes

Am I doing this right?

class Number(Class, Final):
    value = Member(int)

    def __init__(self, val):
        self.value = val
    
    def __add__(self, other):
        value = self.value + other.value
        return Number(value) 
  
@Entrypoint
def main():

    a = Number(77)
    b = Number(2)

    for i in range(10000000):
        c = a+b
        a = c
    print(c)

Without the @Entrypoint it runs without any llvm magic, is that right?

When I do add the @Entrypoint then everything gets compiled (or the compiler barfs) ? Is that right? I’d like to know if it ever sneaks back into the python interpreter, like how cython does.

Here is a second attempt, where I try overloading __add__. It fails to compile.

Number = Forward("Number")

class Number(Class, Final):
    value = Member(int)
    
    def __init__(self, val):
        self.value = val
        
    def __str__(self):
        return str(self.value)
        
    def __add__(self, other:Number):
        value = self.value + other.value
        return Number(value) 
        
    def __add__(self, other:int):
        value = self.value + value
        return Number(value) 

Also, without the Final, it complains that I haven’t annotated a return type for __add__. Can I annotate that __add__ returns a Number ? Or do I just stick with Final?

I’m glad there is a comprehensive test suite, but lines like this: __add__ = lambda self, other: C("add") make no sense to me. Maybe someone should add a directory of example code ? Examples that don’t compile/run would also be good to see.

[braxtonmckee]

1. yes you are generally doing the right thing. There are still some ways the system is finicky if you don’t know the rules, and making that less obscure is something i’d love to do, so your feedback is super helpful.
2. yes, you have to cross an @Entrypoint barrier before it invokes the compiler. It attempts compile all the way down. It will drop back into the interpreter if it can’t figure out what’s going on (for instance, if you use a python builtin it doesn’t understand). You can see what it’s compiling by running with the TP_COMPILER_VERBOSE environment variable set to 1, 2, 3, 4, or 5, to get increasing levels of detail about what its compiling. Accidentally hitting the interpreter is super annoying, so I was planning on trying to build something to assert that everything is well typed (as an argument to Entrypoint, for instance). Feedback on that plan welcome. For the most part, the intent is that the compiler does not throw exceptions - if it doesn’t understand something it should hit the interpreter, and then we should allow features that you can use to assert that things are compiled. Along these lines, you can ‘from typed_python import isCompiled’ and then ‘assert isCompiled’ within your code, if you’re trying to determine whether you are running in compiled mode or the interpreter.
3. what’s the error on compilation? That ought to work - it’s probably just something stupid I neeed to fix. I did a whole pass on implicit conversion rules recently - we don’t have that many cases of operator overloading with classes, so maybe that’s a regression I can fix easily.
4. if you don’t put Final, then the compiller wants type annotations. This lets it generate something akin to a vtable in C++ so that it can compile against the base class and dispatch to overloads in subclasses. ‘Final’ means you can’t have a subclass, so ethe compiler doesn’t dispatch against the vtable and just uses the type directly (this is usually much faster because it can inline).
5. if you do want to leave ‘Final’ off, then yes, you can annotate -> Number.
6. I agree - we have inhouse projects (where I work) that use this extensively, but not that much client code in the public domain. I did just push up a ‘sorted_dict’ class in typed_python/lib that is a reasonable example of using TP to build a fairly nontrivial class, and I’m hoping to add more in the future. The tests are mostly there to verify that the system works, as they’re not the best examples.

On Thu, Feb 25, 2021 at 2:24 PM Simon Burton [e-mail] wrote:

Am I doing this right?

class Number(Class, Final): value = Member(int)

def __init__(self, val):
    self.value = val

def __add__(self, other):
    value = self.value + other.value
    return Number(value)

@Entrypoint def main():

a = Number(77)
b = Number(2)

for i in range(10000000):
    c = a+b
    a = c
print(c)

Without the “@entrypoint https://github.com/entrypoint” it runs without any llvm magic, is that right?

When I do add the “@entrypoint https://github.com/entrypoint” then everything gets compiled (or the compiler barfs) ? Is that right? I’d like to know if it ever sneaks back into the python interpreter, like how cython does.

Here is a second attempt, where I try overloading add. It fails to compile.

Number = Forward(“Number”)

class Number(Class, Final): value = Member(int)

def __init__(self, val):
    self.value = val

def __str__(self):
    return str(self.value)

def __add__(self, other:Number):
    value = self.value + other.value
    return Number(value)

def __add__(self, other:int):
    value = self.value + value
    return Number(value)

Also, without the Final, it complains that I haven’t annotated a return type for add. Can I annotate that add returns a Number ? Or do I just stick with Final?

I’m glad there is a comprehensive test suite, but lines like this: add = lambda self, other: C(“add”) make no sense to me. Maybe someone should add a directory of example code ? Examples that don’t compile/run would also be good to see.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/APrioriInvestments/typed_python/issues/385, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6OHBF3W52K2XME5QGQZ6LTA2PYDANCNFSM4YHC3MXA .

[braxtonmckee]

Separately, on string formatting, I guess we didn’t explicitly model str.format. fstrings work although we have not implemented all the twiddly little formatters