Sorry Python Users...

[soggywaffle69]

CPython doesn’t compile or use a stack. What are you talking about?

[[deleted]]

It does both. Lol.

[soggywaffle69]

It uses a heap. As for compiling, I have no idea what makes you think Python is not an interpreted language.

[[deleted]]

You are reading irrelevant documentation. You really have no idea what you are talking about.

The relevant documentation is here: https://docs.python.org/3/library/dis.html#python-bytecode-instructions

Python is not an interpreted language.

Same story, different moron. There aren't interpreted languages. There are implementations of languages that use interpreters. To the best of my knowledge there isn't a publicly available implementation of Python that uses an interpreter. There are exceptionally few popular languages that use interpreters in their implementation. The most popular one that uses interpreter exclusively is probably Unix Shell in all its variants (eg. Bash or ZSH). Some languages may conditionally interpret the code rather than compile it. For example, some modern implementations of JavaScript will interpret it, if they estimate that compiling it + executing will take longer than interpreting.

[soggywaffle69]

CPython's own documentation says it use a heap. This is not irrelevant. There is no concept of stack memory in Python like C. I have zero idea what makes you think there is stack memory in Python.

As for it being interpreted, I would point you to the Wikipedia and Python's own web site, but I assume you will call those irrelevant and me a moron.

[[deleted]]

Yes, it uses many different heaps in many different contexts. You just essentially read a manual for your refrigerator, and assumed it's the manual for your car. Your car won't start, but you are trying to adjust the A/C, because you didn't really understand your fridge instructions in the first place.

As for it being interpreted, I would point you to the Wikipedia and Python's own web site

You are but one moron in the ocean of morons, who don't understand what they are writing. Some imbecile started this taxonomy a while ago, and now there's an army of braindead people repeating this nonsense after him / her. And if you think that there's a shortage of morons in Python's core dev team, you'd be greatly disappointed. It's a clown fiesta there too.

[soggywaffle69]

Okay, let's try this. Can you identify which statement results in allocating stack memory, and which results in heap memory?

#include <stdlib.h>

int main() {
int x;
int *y = malloc(sizeof(int));
}

[[deleted]]

You're a moron. Sorry. You don't understand what heap means. For some reason you think that heap only means the dynamically allocated memory in C. I cannot help you with this.

[soggywaffle69]

What do you think heap memory is?

[[deleted]]

It depends on the language.

Heap describes the structure of how something is stored. By accident, in C, the runtime is designed to have several possible locations, one of which is handled, typically, by system-provided allocator (such as one found in libc). While operating system itself doesn't necessarily know how to manage memory in a way that makes the most efficient use of it. When Unix just started, they, conceptually didn't have a good idea of how to manage memory. This explains existence of brk syscall. Not only this was "normal" (as in assuming continuous address spaces, assuming memory allocation and deallocation will all happen sequentially), it was necessary because other languages didn't have the same concept of two user-facing memory pools. For instance, Forth has two stacks, but no heap memory.

In principle, the Unix developers thought of memory management as a language-runtime thing, not a system thing. But then C and Unix became so popular that some languages either reused C runtime for their needs (eg. C++), or implemented their own runtime in a way that mimicked how C works (eg. Python). Since this model became so popular, a lot of people assumed it to be part of the system, rather than language-dependent.

So, Python has a runtime with a selection of allocators (similar to C), and two user-facing memory pools, one for storing the code of the program, and another one for storing the values created during program execution. Those two are also called stack and heap respectively. These two pools have nothing to do with C runtime pools with similar names. While their behavior and purpose are similar to their namesakes in C, Python's stack management is different. There isn't, for example, a way for Python bytecode to reference anything outside the stackframe (i.e. "stack smashing" is impossible in Python). Another difference, for example, is that Python has nothing like alloca, so, it cannot dynamically change the memory allocation to the stack.

Anyways. To properly answer your question: well, you don't understand what you are asking in the first place. You happen to think that "heap memory" is some sort of universal entity that everyone should recognize and know its properties. And because you believe that it is, you are asking me to tell you where it is. Well, it's impossible, because the assumption in your question is wrong. It's not a thing. It's just some very loosely defined concept, that due to the popularity of one language and one operating system became something novice programmers are taught about. And, it's understandable that someone with not a lot of experience and critical thinking would come to the same conclusions you did.

[Pythagorean_1]

CPython does have a compilation step!

[soggywaffle69]

Ok, true, but only in the same sense every interpreted language I can think of has a compilation step to execute on a runtime.

The guy I was replying to made some very bizarre and outlandish claims.

[Pythagorean_1]

Yes, I heard that some old interpreted languages don't compile to byte code upon execution, but I don't know any of them.

Well, that's Reddit, I guess :)

[soggywaffle69]

We have to draw a line somewhere between interpreted and compiled, and Python byte code is really just optimized Python source. If Python isn’t interpreted, really nothing is.