15:15 <arigato> cfbolz: just curious, you said in issue3825 it would be not that hard to allow monkay-patching PyFloatType.tp_repr? how?

15:16 <cfbolz> arigato: ah, not precise by patching the C struct

15:16 <cfbolz> but we could have a __pypy__ api if we *really* wanted

15:16 <cfbolz> not sure it's a good direction generally though :-/

15:16 <arigato> still, how exactly? it seems to me it would make all calls to repr() indirect

15:18 <cfbolz> arigato: we could allow heaptype __dict__ modification generally via that api

15:18 <arigato> but we're talking about PyFloat_Type, not a heaptype

15:18 <cfbolz> sorry, I meant builtin-types

15:18 <cfbolz> it would be efficient with the JIT, like method calls on user-defined classes are efficient (ie a quasi-immutable version)

15:19 <arigato> it might negate the efforts we spent making the non-jitted version fast, though

15:19 <cfbolz> (for a while we even had a translation option for generally allowing monkey-patching on all types)

15:19 <cfbolz> arigato: that's true, and indeed probably the real problem :-/

15:19 <cfbolz> anyway, I don't *want* to do that, it's a pretty obscure use case

15:20 <arigato> OK, I just wondered if I was missing something :-)

15:20 <cfbolz> arigato: yes, I probably only thought about the JIT, and not the careful caching of special methods

15:24 <cfbolz> arigato: I still think that if somebody wants an especially fast special-purpose float formatter, they should just call it explicitly

15:26 <arigato> yes

15:37 <cfbolz> arigato: thanks for looking at raise-in-thread-2 :-)

16:22 <cfbolz> Here are the slides about cpu emulation using PyPy that I used in a talk last week: https://www.slideshare.net/secret/9xR1akke2qoy2N

17:14 <fuzzypixelz> hello!

17:14 <fuzzypixelz> I'm following https://rpython.readthedocs.io/en/latest/getting-started.html#trying-out-the-translator

17:15 <fuzzypixelz> trying to run any RPython code from pypy, i.e. pypy/rpython/bin/rpython results in things like:

17:15 <fuzzypixelz> SyntaxError: Missing parentheses in call to 'print'. Did you mean 'print(...)'?

17:15 <fuzzypixelz> CPython and pypy give similar errors

17:15 <arigato> rpython is a sublanguage of python 2, not python 3

17:16 <fuzzypixelz> does pypy support python2? is there a way to enable that via commandline arguments?

17:16 <arigato> and you need to use python2 to run bin/rpython

17:16 <fuzzypixelz> my distro doesn't seem to ship python2 anymore

17:16 <arigato> yes, you can use pypy (there is a python2 and a python3 version of pypy)

17:17 <fuzzypixelz> meaning pypy 2.7?

17:18 <fuzzypixelz> or is python2 included in pypy 3.9

17:18 <arigato> yes, the "pypy2.7" column in https://www.pypy.org/download.html

17:18 <fuzzypixelz> oh I have to download it okya

17:33 <fuzzypixelz> It seems that RPython's os.open is different from Python 2

17:33 <fuzzypixelz> In that it takes exactly 3 arguments

17:33 <fuzzypixelz> while Python 2 leaves the mode optional

17:34 <fuzzypixelz> this makes me wonder how do I lookup documentation for the RPython standard library?

17:39 <fuzzypixelz> even the order is different for RPython

17:56 <arigato> well, RPython is more or less documented at rpython.readthedocs.io, but it's meant to be used by people that want to write some kind of interpreter, not as a general purpose programming language

17:58 <arigato> there are also alternatives to the standard library that is compatible with RPython, in the "rpython.rlib" package

17:59 <arigato> but RPython is supposed to be a sublanguage of Python in the sense that any RPython program should work when directly executed as Python

18:00 <arigato> so I'm not sure what you mean by "even the order is different", it shouldn't be