
Blip: A bytecode compiler for Python 3 - luu
https://github.com/bjpop/blip
======
manaskarekar
The succinctness of the README in this project makes me wish more READMEs were
written like this.

~~~
nickpsecurity
I agree: it was a pleasure to read. Very unusual, that. ;)

------
BrandoElFollito
Generally speaking, what are the advantages of such a compiler vs. the
standard interpreter?

~~~
trwired
None. Standard interpreter automatically compiles modules to bytecode on the
first import and stores them in .pyc files. Compiling specific files is also
possible. I am assuming this project is simply an exercise on the author's
part.

edit: precision

~~~
masklinn
Well it might be possible for this one to implement a better bytecode
optimiser and a better "stack flow", the standard interpreter only has a
fairly simple peephole optimiser so it will e.g. store to locals to
immediately reload the same local, or repeatedly load a name from the local or
global scope rather than load it once and dup it:

    
    
        >>> @dis.dis
        ... def foo():
        ...     print a
        ...     print a 
        ...     print a
        ... 
          3           0 LOAD_GLOBAL              0 (a)
                      3 PRINT_ITEM          
                      4 PRINT_NEWLINE       
    
          4           5 LOAD_GLOBAL              0 (a)
                      8 PRINT_ITEM          
                      9 PRINT_NEWLINE       
    
          5          10 LOAD_GLOBAL              0 (a)
                     13 PRINT_ITEM          
                     14 PRINT_NEWLINE       
                     15 LOAD_CONST               0 (None)
                     18 RETURN_VALUE        
    

I don't know how much value the optimised bytecode would bring though, likely
not much outside of specific tight loops, and even then it's still only
interpreted cpython, for little more cost you can integrate scipy solutions
(e.g. numba) which'll likely have a much more significant impact.

~~~
mborch
This is required due to Python's semantics. You can't optimize that away
unless the code is written to explicitly turn a global into a local.

~~~
dalke
Here's an example of why mborch's statement is true:

    
    
        class A:
            def __init__(self, value=0):
                self.b = value
            def __str__(self):
                if self.b == 0:
                    global a
                    a = A(1)
                elif self.b == 1:
                    import __builtin__, __main__
                    __builtin__.a = 2
                    del __main__.a
                return str(self.b)
        a = A()
        
        def foo():
            print a
            print a
            print a
            
        foo()
    
    

This generates:

    
    
        1
        2
        3
    

but it's a different 'a' in all three cases; the last isn't even from the
module's namespace.

~~~
stctgion
pretty sure that produces 0,1,2

~~~
dalke
Good catch!

Yes, the output was from my first version. I rewrote it to be more explicit
about changing the 'a' each time, and forgot to update the output section.

------
jakeogh
(In Haskell)

~~~
truncate
I would be interested to see codebase comparison with CPython compiler.

