31–40 of 57 posts
(2012)
the text is based on python 3.5 which was released in 2015
other discussions:
https://news.ycombinator.com/item?id=16795049
one liner: eval(str)
one liner: eval(str)
```python3
from openai import OpenAI
import sys
client = OpenAI()
response = client.chat.completions.create( model="gpt-4", messages=[{ "role": "user", "content": f"generate valid python byte code this program compiles to: {sys.argv[1]}" }] )
print(response.choices[0].message.content)
```
Actually, probably not better.
> Byterun is a Python interpreter written in Python. This may strike you as odd, but it's no more odd than writing a C compiler in C. I'm not so sure. The difference between a self-hosted compiler and a circular interpreter is that the compiler has a binary artifact that you can store. With an interpreter, you still need some binary to run your interpreter, which will probably be CPython, making the new interpreter r…
PyPy handled this by implementing PyPy in a restricted minimal subset of Python that they called RPython, and that seemed to work out well for them.
It's more than just what is syntax or a language feature, for example RPython provides nts classes, but only very limited multiple inheritance; all the MRO stuff is implemented using RPython for PyPy itself.
> Byterun is a Python interpreter written in Python. This may strike you as odd, but it's no more odd than writing a C compiler in C. I'm not so sure. The difference between a self-hosted compiler and a circular interpreter is that the compiler has a binary artifact that you can store. With an interpreter, you still need some binary to run your interpreter, which will probably be CPython, making the new interpreter r…
This is the case only if the new interpreter does not simply include the layer that the old interpreter has for translating bytecode to native instructions. Once you have that, you can simply bootstrap any new interpreters from previous ones. Even in the case of supporting new architectures, you can still work at the Python level to produce the necessary binary, although the initial build would have to be done on an…
Earlier quoted context omitted.
This is the case only if the new interpreter does not simply include the layer that the old interpreter has for translating bytecode to native instructions. Once you have that, you can simply bootstrap any new interpreters from previous ones. Even in the case of supporting new architectures, you can still work at the Python level to produce the necessary binary, although the initial build would have to be done on an…
Interpreters don't translate bytecode to native instructions.
(2012)
actually it was published as a chapter in "500 lines or less" in 2016: https://news.ycombinator.com/item?id=11796253 the text is based on python 3.5 which was released in 2015 other discussions: https://news.ycombinator.com/item?id=16795049 https://news.ycombinator.com/item?id=12455104 https://news.ycombinator.com/item?id=11796253
> Byterun is a Python interpreter written in Python. This may strike you as odd, but it's no more odd than writing a C compiler in C. I'm not so sure. The difference between a self-hosted compiler and a circular interpreter is that the compiler has a binary artifact that you can store. With an interpreter, you still need some binary to run your interpreter, which will probably be CPython, making the new interpreter r…
PyPy handled this by implementing PyPy in a restricted minimal subset of Python that they called RPython, and that seemed to work out well for them.
I.e. PyPy DOESN'T have an interpreter written in an interpreted language.
Earlier quoted context omitted.
actually it was published as a chapter in "500 lines or less" in 2016: https://news.ycombinator.com/item?id=11796253 the text is based on python 3.5 which was released in 2015 other discussions: https://news.ycombinator.com/item?id=16795049 https://news.ycombinator.com/item?id=12455104 https://news.ycombinator.com/item?id=11796253
Oops, I went by the publication date of the book