this post was submitted on 25 Sep 2026
58 points (91.4% liked)

Python

8062 readers
1 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

๐Ÿ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

๐Ÿ Python project:
๐Ÿ’“ Python Community:
โœจ Python Ecosystem:
๐ŸŒŒ Fediverse
Communities
Projects
Feeds

founded 3 years ago
MODERATORS
 

A hard exercise to help build the right mental model for Python data.

The โ€œSolutionโ€ link visualizes execution and reveals whatโ€™s actually happening using ๐—บ๐—ฒ๐—บ๐—ผ๐—ฟ๐˜†_๐—ด๐—ฟ๐—ฎ๐—ฝ๐—ต: https://github.com/bterwijn/memory_graph

you are viewing a single comment's thread
view the rest of the comments
[โ€“] a_non_monotonic_function@lemmy.world 4 points 1 week ago* (last edited 1 week ago) (1 children)

Like anything else, these sorts if issues are rather murky and are directly impacted by the user's competence in the tools.

Does python have obvious overhead issues? Yes.

Does Python have to be super inefficient? No.

Take basic set operations, for example. Do it manually in the language and it will be dog slow. Do it using the set class? You are leveraging the speed of the underlying C implementation.

E.g., In competitive programming eventually need C or Java, but a strong Python user can move the bar significantly in terms of how many problems are possible with Python.

If you don't want mutability you have to go to a pure functional language like Haskell, but then you have to copy a big list every time you make a change. There are ways to optimize copying by secretly sharing data behind the scene but you pay a performance price in some way.

I don't believe this to be the case. The immutability is precisely why efficient structural sharing is possible without screwing up other data structures. And for standard stuff, it is actually happening behind the scenes already.

You see similar claims about recursion in general, but those claims are often so broad that they don't hold water. I mean, yea, if your language sucks at optimizing recursion it isn't going to be a pleasant experience, but tail call elimination, lazy evaluation, etc. mean you can write some really awesome and efficient code.

I think the bigger problem is that it takes a lot of time to internalize what is going on under the hood when you make a call or initialize a data structure.

[โ€“] bterwijn@programming.dev 3 points 1 week ago (1 children)

I've built a nice visualizer for internalizing what is going on under the hood, I hope that can help people.

[โ€“] a_non_monotonic_function@lemmy.world 2 points 1 week ago (1 children)

Well, that is interesting, isn't it?

Thank you for the lead. I'm setting that link aside. I might use it in class next time.

[โ€“] bterwijn@programming.dev 2 points 1 week ago

Great, I hope it can bring much value for your teaching.