[pypy-dev] Porting PyPy/rpython to Python 3
VanL
van.lindberg at gmail.com
Thu Apr 16 20:15:08 CEST 2015
A quick overall response: I know that a lot of what I am talking about *is
possible* using RPython. That is one reason why I am starting where I am.
That doesn't necessarily make it easy (or as easy as it could be).
On Thu, Apr 16, 2015 at 11:39 AM, Ronan Lamy <ronan.lamy at gmail.com> wrote:
> Why Py3?: I like Py3 better. I want to use function annotations to
>> provide information to the inferencing process. The annotations would
>> provide new roots for a the type inferencing process - and importantly,
>> would allow me to stop that process at module boundaries efficiently.
>>
>
>
> Syntax aside, it's already in RPython, cf.
> rpython.rlib.objectmodel.enforceargs and rpython.rlib.signature (which
> sadly are incompatible with each other).
>
> Type inferencing? The types in typing.py don't work for us: Yes, but we
>> don't need to be restricted to those types only. There is no reason not
>> to declare the types that we need - for example to have UInt32 as a
>> possible type in a function annotation. This allows us to get rid of a
>> fair amount of "noise" is the rpython implementation (or at least to
>> sequester it better).
>>
>
> Unless you want to get rid of type inferencing altogether (or strictly
> restrict it to function locals, perhaps), that noise isn't going away.
>
[snip]
What changes in the compilation model? One big one: Be able to
>> effectively do type inferencing on a smaller piece of the program than
>> "the whole program." I would like to stop/start at either function
>> boundaries or at module boundaries. Declaring appropriate type
>> information would let me do that.
>>
>
> Removing whole-program type inferencing would change the character of the
> language a lot. In addition to function signatures, you'd also need to
> declare types for global constants, class and instance attributes, ...
>
I don't want to get rid of whole-program type inferencing. I just want to
be able to define a subset and declare that "this is the whole program" for
purposes of an inferencing pass. I do know that means that sometimes types
will become non-inferenceable. That is where explicit function/type
annotation would allow me to do so.
For a silly example,
def add(x, y): return x + y
is not generally type inferenceable in Python. But
def add(x:UInt32, y:UInt32): return x + y
is. (Putting aside overflow for a second).
>
> I don't understand how this fits with the rest of your plans. By
> definition, PyPy3 will be able to run spy, so why do you need your own
> interpreter?
>
>
I want my spy interpreter to run only spy. Python 3 (whether CPython3 or
PyPy3) would also be able to run .spy files, but having a nice repl
(without incurring the double interpretation cost) would be good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150416/35903581/attachment-0001.html>
More information about the pypy-dev
mailing list