Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A high-performance, zero-overhead, extensible Python compiler using LLVM

github.com

Post reply on HN
Print view View original

91–95 of 95 posts

Re: A high-performance, zero-overhead, extensible Python compiler using LLVM

#91

Post by funny_falcon »

nick238 wrote: post #84
baq wrote: post #64

Earlier quoted context omitted.

dicts ordering keys in insertion order isn't an implementation detail anymore and hasn't been for years.

I get that all dicts are now effectively an `collections.OrderedDict`, but I've never seen practical code that uses the insertion order. You can't do much with that info (no `.pop()`, can't sort a dict without recreating it) beyond maybe helping readability when you print or serialize it.

Readability, reproducibility, and simple LRU.

Reproducibility matters for tests, they become simpler. Some other algorithms become simpler as well.

LRU is just a dict with preserving order: on access just delete and insert again.

Re: A high-performance, zero-overhead, extensible Python compiler using LLVM

#92

Post by Nab443 »

slightwinder wrote: post #90
ErikBjare wrote: post #81

Earlier quoted context omitted.

How does that apply in this case?

"return key, value" is implicit. While "return [key, value]" is explicitly telling the full return-value. And it's (for me) more readable than "return (key, value)".

I don't see how "return (key, value)" is less readable than it's list counterpart. Now, why using a list that can grow, and so takes more space and maybe less efficient, for something that should not?

Re: A high-performance, zero-overhead, extensible Python compiler using LLVM

#93

Post by ghxst »

slightwinder wrote: post #90
ErikBjare wrote: post #81

Earlier quoted context omitted.

How does that apply in this case?

"return key, value" is implicit. While "return [key, value]" is explicitly telling the full return-value. And it's (for me) more readable than "return (key, value)".

A list and tuple are not the same thing. There could be reasons to require a list explicitly but I couldn't really think of any obvious ones which is why I asked.

Re: A high-performance, zero-overhead, extensible Python compiler using LLVM

#94

Post by slightwinder »

Nab443 wrote: post #92
slightwinder wrote: post #90

Earlier quoted context omitted.

"return key, value" is implicit. While "return [key, value]" is explicitly telling the full return-value. And it's (for me) more readable than "return (key, value)".

I don't see how "return (key, value)" is less readable than it's list counterpart. Now, why using a list that can grow, and so takes more space and maybe less efficient, for something that should not?

"return (key, value)" can be read as a function-call. Especially as space after the function-name is allowed in python. And performance on that level is no serious topic in python anyway. But this is mainly just a personal preference.

Re: A high-performance, zero-overhead, extensible Python compiler using LLVM

#95

Post by stoperaticless »

skeledrew wrote: post #86
thesz wrote: post #60

Earlier quoted context omitted.

> If lang is not compatible with any of python versions, then the lang isn’t python. Python versions are not compatible between themselves, as python does not preserve backward compatibility, ergo python is not python.

Interestingly I recently had to run a script I wrote for 3.11 on an old system that has 3.6, and the only thing I had to remove were a few type hints (which of course don't affect function). Seems pretty backwards compatible to me.

Pretty compatible != compatible.

(I can edit my own script, I would hate if installation instructions for “django” would include “just remove the type hints from the scripts”)

Post reply on HN