Live data from Hacker News

Making a Python interpreter in 1024 bytes

austinhenley.com

101–110 of 120 posts

Re: Making a Python interpreter in 1024 bytes

#102
post #84

Earlier quoted context omitted.

By that standard, this is totally over-engineered. Just hardcode it.

Good idea. Write a python script, and then code the minimal c interpreter possible to make that specific script work, utilizing the script itself as string reference (and any other way one can manage to utilize it in the interpreter itself).

Someone actually testing Kolmogorov Complexity LOL

Re: Making a Python interpreter in 1024 bytes

#103
post #95

The author lost me right away. >> I started with the most basic code I could think of: 1 + 2 OK, how did you fit that into 512/1024 bytes??? Did you try print(3 * * 1000)?

It's not real Python. It's essentially a made-up language that resembles a subset of Python.

That said, if I was building a small ugly toy Python implementation, I would probably also not implement long integers. Or the power operator. At least not in the first iteration.

Re: Making a Python interpreter in 1024 bytes

#106
post #79

Earlier quoted context omitted.

I like python subset . However, many don't see it that way.

It's not a subset of python. For instance this program works in this interpreter, but not in python: fxx i in rxxxx(10): pxxxx(i)

That isn't part of the language though. That's just input that it doesn't handle properly. The author acknowledged it lacks error handling.

Re: Making a Python interpreter in 1024 bytes

#109
post #60
post #40

I don't understand the point of this. If they wanted to make a Python interpreter, why didn't they just ask an AI to do it?

Why do anything. Why even do the AI version of this. Probably curiosity. If there's an AI version of code golfing, I'd be curious to see it. Maybe they golf worse or much better than us meat bags.

[dead]

Re: Making a Python interpreter in 1024 bytes

#110
post #49

Earlier quoted context omitted.

Truly, indentation is the moveable feast. Even on ancient typewriters, you could adjust your tabs depending on what you are doing. And people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors. > What business does a compiler have worrying about display width? The business of the compiler is to insure that code that it deems acceptable is not ambigu…

> people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors. Not for code, no. People will do that for spaces. For tabs it's a 1:1 correspondence with indentation level with any visual adjustments done by the editor. Reading between the lines I suspect you are operating with the flawed idea of using tabs for alignment. One must never use tabs for al…

> I'll instead observe that it seems to follow from what you said that you actually agree with me. As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.

No, I vehemently disagree with most of what you wrote. We certainly agree on basic things that tabs do not have a fixed width, and that a "compiler never has any control over (source code) display." (What a bizarre idea; whoever said it did?)

> I'd dispute that the compiler needs to care about where your editor places the left margin.

This isn't just about editors. I well remember green-bar.

> As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.

No, if someone uses 8 character tabs, and then wants to space over half a tab for visual reasons, things completely break. We probably agree that's wrong, and that the answer is some variant of the answer to "Doc, it hurts when I do this" and I maintain the answer is to dispense with tabs completely.

Look the tabs-vs-spaces war is as old as the big-endian/little-endian war, and I am probably older than you. We'll probably never convince each other of any of this. Have a good day.

Post reply on HN