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

61–70 of 95 posts

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

#61

Post by Someone »

cjbillington wrote: post #37
actionfromafar wrote: post #33

Earlier quoted context omitted.

The trade-off is a bit of speed.

This might be what you meant, but the ordered dicts are faster, no? I believe ordering was initially an implementation detail that arose as part of performance optimisations, and only later declared officially part of the spec.

> but the ordered dicts are faster, no?

They may be in the current implementations, but removing an implementation constraint can only increase the solution space, so it cannot make the best implementation slower.

As a trivial example, the current implementation that guarantees iteration happens in insertion order also is a valid implementation for a spec that does not require that guarantee.

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

#63

Post by KeplerBoy »

thesz wrote: post #60
stoperaticless wrote: post #35

Earlier quoted context omitted.

All versions of python are python. If lang is not compatible with any of python versions, then the lang isn’t python. False advertising is not nice. (even if the fineprint clarifies)

> 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.

The words "any" and "all" have a different meaning.

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

#64

Post by baq »

orf wrote: post #27
quotemstr wrote: post #20

Earlier quoted context omitted.

It's not even a subset. They break foundational contracts of the Python language without technical necessity. For example, > Dictionaries: Codon's dictionary type does not preserve insertion order, unlike Python's as of 3.6. That's a gratuitous break. Nothing about preserving insertion order interferes with compilation, AOT or otherwise. The authors of Codon broke dict ordering because they felt like it, not because…

Try not to throw around statements like “they broke duct ordering because they felt like it”. Obviously they didn’t do that. There are trade-offs when preserving dictionary ordering.

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

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

#65

Post by BiteCode_dev »

haberman wrote: post #18

> Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon. This is targeting a Python subset, not Python itself. For example, something as simple as this will not compile, because lists cannot mix types in Codon ( https://docs.exaloop.io/codon/language/collections#strong-…

For a real compiler try nuitka.

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

#67

Post by robjwells »

dathinab wrote: post #46
itishappy wrote: post #23

Earlier quoted context omitted.

Altering python's core datatypes is not what I'd call minor. They don't even mention the changes to `list`. > Integers: Codon's int is a 64-bit signed integer, whereas Python's (after version 3) can be arbitrarily large. However Codon does support larger integers via Int[N] where N is the bit width. > Strings: Codon currently uses ASCII strings unlike Python's unicode strings. > Dictionaries: Codon's dictionary type…

> Strings: Codon currently uses ASCII strings unlike Python's unicode strings. wtf this is a supper big issue making this basically unusable for anything handling text (and potentially even just fixed indents, if you aren't limited to EU+US having non us-ascii idents in code or text is common, i.e. while EU companies most times code in english this is much less likely in Asia, especially China and Japan. it isn't eve…

Yeah this is a baffling decision. I’d like to know what the motivation is. ASCII doesn’t even contain € or £.

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

#68

Post by Myrmornis »

RogerL wrote: post #45
bpshaver wrote: post #24

Earlier quoted context omitted.

Who is out here mixing types in a list anyway?

return [key, value]

You should use a tuple there: it's a collection of fixed size where each slot has an identity. (There's a common confusion in Python circles that the main point of tuples is immutability; that's not so).

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

#69

Post by Myrmornis »

amelius wrote: post #47

The challenge is not just to make Python faster, it's to make Python faster __and__ port the ecosystem of Python modules to your new environment.

This should be top comment. If I don't get the ecosystem then I'd just use Rust.

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

#70

Post by slightwinder »

ghxst wrote: post #52
RogerL wrote: post #45

Earlier quoted context omitted.

return [key, value]

Why would you do this over `return key, value` which produces a tuple? Just curious.

To quote the Zen of Python:

    Explicit is better than implicit.
    Readability counts.
Post reply on HN