Everything is an object in python - object class and type class

[BartC]

On 04/06/2015 11:06, Laura Creighton wrote:
> In a message of Thu, 04 Jun 2015 00:04:04 +0100, BartC writes:
>> Mainly the language itself. But I've also been looking at the workings
>> of CPython. (Also PyPy but obviously I'm not going to get anywhere
>> there, although RPython sounds intriguing.)
>
> Why not?  We built the thing for people like you who want to design
> their own language.

(I thought you wrote bookkeeping systems?)

> This makes me sad.  What are we doing wrong
> that you think you won't get anywhere there?

It's not that you're doing anything wrong. I'm just used to using my own 
languages and to implementing 100% of them myself. (I have one that does 
the job of C, and another that takes over the role of Python, which are 
the two I'd otherwise be using.)

In the case of the interpreted one, I write streamlined but otherwise 
unremarkable bytecode interpreters that can (when I add a bit of ASM) 
just about compete with PyPy on small benchmarks.

(It is this latter language that I am upgrading to be more dynamic, to 
make the comparisons fairer, and see if I can still maintain 
performance. But I do believe a lot can be achieved with a more careful 
language design.)

To make use of PyPy, I understand that I have to code my interpreter in 
RPython, with various hints, and it is the execution paths in this code 
that are somehow optimised at runtime.

However, I've seen at the video someone posted of the keynote talk about 
PyPy (https://youtu.be/l_HBRhcgeuQ), and it does look a rather 
intimidating process (apparently taking several hours to compile the 
smallest code tweak; currently it takes me about 1 second to try 
something new).

Also, I'm using Windows where even ordinary Python development doesn't 
really work; I had to use Ubuntu (a completely alien environment to me) 
to attempt compiling Cpython).

-- 
Bartc