Python numbers every programmer should know • Hacker News Board

Re: Python numbers every programmer should know

#161

Post by BiteCode_dev » Fri, Jan 02, 2026, 1:50 PM UTC

fooker wrote: post #5

Counterintuitively: program in python only if you can get away without knowing these numbers. When this starts to matter, python stops being the right tool for the job.

Not at all.

Some of those number are very important:

- Set membership check is 19.0 ns, list is 3.85 μs. Knowing what data structure to use for the job is paramount.

- Write 1KB file is 35.1 μs but 1MB file is only 207 μs. Knowing the implications of I/O trade off is essential.

- sum() 1,000 integers is only 1,900 ns: Knowing to leverage the stdlib makes all the difference compared to manual loop.

Etc.

A few years ago I did a Python rewrite of a big clients code base. They had a massive calculation process that took 6 servers 2 hours.

We got it down to 1 server, 10 minutes, and it was not even the goal of the mission, just the side effect of using Python correctly.

In the end, quadratic behavior is quadratic behavior.

Re: Python numbers every programmer should know

#162

Post by tialaramex » Fri, Jan 02, 2026, 2:35 PM UTC

nightfly wrote: post #131

zelphirkalt wrote: post #110

Earlier quoted context omitted.

Omg, switching to C++ for pupils programming beginners ... "How to turn off the most students from computer programming?" 101. Really can't get much worse than C++ for beginners.

PSU (Oregon) uses C++ as just "c with classes" and ignores the rest of C++ for intro to programming courses. It frustrates people who already use C++ but otherwise works pretty well.

We should distinguish "First language" classes (for Computer Scientists who will likely learn many other languages and are expected to graduate knowing enough to just pick up another language with self study in reasonable time) from "Only language" classes for subjects where you might find it useful to write some software. These have different goals, it wouldn't make sense to teach say, OCaml as the only language but it's entirely reasonable as a first language.

Re: Python numbers every programmer should know

#163

Post by fragmede » Fri, Jan 02, 2026, 3:41 PM UTC

its-summertime wrote: post #147

dekhn wrote: post #115

Earlier quoted context omitted.

Ah, I only noticed the "shell startup" bit. Yes, after 2-3 I agree you'd start to notice if you were really fast. I suppose at that point I'd just have Gemini rewrite the prompt-building commands in Rust (it's quite good at that) or merge all the prompt-building commands into a single one (to amortize the startup cost).

https://starship.rs/ perhaps? I should probably start using it again honestly.

it feels good to have all that information at your fingertips but most of the time the default config is way too noisy.

Re: Python numbers every programmer should know

#164

Post by fragmede » Fri, Jan 02, 2026, 3:43 PM UTC

lifeisstillgood wrote: post #117

krior wrote: post #111

Earlier quoted context omitted.

I mean it sounds reasonable to me to wrap the data into objects. customers[3][4] is a lot less readable than customers[3].balance

Absolutely But hidden in this is the failing of every sql-bridge ever - it’s definitely easier for a programmer to read customers(3).balance but the trade off now is I have to provide class based semantics for all operations - and that tends to hide (oh you know, impedance mismatch). I would far prefer “store the records as plain as we can” and add on functions to operate over it (think pandas stores basically just i…

customers[3]['balance'] seems like a reasonable middle ground, no?

Re: Python numbers every programmer should know

#165

Post by fragmede » Fri, Jan 02, 2026, 3:44 PM UTC

perrygeo wrote: post #70

> small int (0-256) cached It's -5 to 256, and these have very tricky behavior for programmers that confuse identity and equality. >>> a = -5 >>> b = -5 >>> a is b True >>> a = -6 >>> b = -6 >>> a is b False

wat

Re: Python numbers every programmer should know

#166

Post by [deleted] » Fri, Jan 02, 2026, 4:03 PM UTC

BiteCode_dev wrote: post #161

fooker wrote: post #5

Counterintuitively: program in python only if you can get away without knowing these numbers. When this starts to matter, python stops being the right tool for the job.

Not at all. Some of those number are very important: - Set membership check is 19.0 ns, list is 3.85 μs. Knowing what data structure to use for the job is paramount. - Write 1KB file is 35.1 μs but 1MB file is only 207 μs. Knowing the implications of I/O trade off is essential. - sum() 1,000 integers is only 1,900 ns: Knowing to leverage the stdlib makes all the difference compared to manual loop. Etc. A few years ag…

[deleted]

Re: Python numbers every programmer should know

#167

Post by fooker » Fri, Jan 02, 2026, 5:30 PM UTC

BiteCode_dev wrote: post #161

fooker wrote: post #5

Counterintuitively: program in python only if you can get away without knowing these numbers. When this starts to matter, python stops being the right tool for the job.

Not at all. Some of those number are very important: - Set membership check is 19.0 ns, list is 3.85 μs. Knowing what data structure to use for the job is paramount. - Write 1KB file is 35.1 μs but 1MB file is only 207 μs. Knowing the implications of I/O trade off is essential. - sum() 1,000 integers is only 1,900 ns: Knowing to leverage the stdlib makes all the difference compared to manual loop. Etc. A few years ag…

List membership check being significantly slower than set membership check is freshman computer science 101.

Re: Python numbers every programmer should know

#168

Post by boutell » Fri, Jan 02, 2026, 6:23 PM UTC

Knowing all of these is exactly what a developer shouldn't need to do. Fix "big O" problems in your own code. And be aware of a few exceptionally weird counterintuitive things if it matters on a "big O" level — like "you think this common operation is O(1) but it's actually O(N^2)". If there actually are any of those. And just get stuff done.

I guess you could find yourself in a situation where a 2X speedup is make or break and you're not a week away from needing 4X, etc. But not very often.

Re: Python numbers every programmer should know

#169

Post by intalentive » Fri, Jan 02, 2026, 6:35 PM UTC

Great resource. I would also like to see a comparison of variable access times across different scopes.

Re: Python numbers every programmer should know

#170

Post by pjmlp » Fri, Jan 02, 2026, 6:40 PM UTC

passivegains wrote: post #68

oofbey wrote: post #55

Earlier quoted context omitted.

It’s very natural. Python is fantastic for going from 0 to 1 because it’s easy and forgiving. So lots of projects start with it. Especially anything ML focused. And it’s much harder to change tools once a project is underway.

this is absolutely true, but there's an additional nuance: yes, python is fantastic, yes, it's easy and forgiving, but there are other languages like that too. ...except there really aren't. other than ruby and maybe go, every other popular language sacrifices ease of use for things that simply do not matter for the overwhelming majority of programs. much of python's popularity doesn't come from being easy and forgiv…

Cough, Lisp.