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

21–30 of 95 posts

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

#21

Post by jjk7 »

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

The differences seem relatively minor. Your specific example can be worked around by using a tuple; which in most cases does what you want.

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

#22

Post by axit »

troymc wrote: post #7
Lucasoato wrote: post #5

> Is Codon free? Codon is and always will be free for non-production use. That means you can use Codon freely for personal, academic, or other non-commercial applications. I hope it is released under a truly open-source license in the future; this seems like a promising technology. I'm also wondering how it would match C++ performance if it is still garbage collected.

The license is the "Business Source License 1.1" [1]. The Business Source License (BSL) 1.1 is a software license created by MariaDB Corporation. It's designed as a middle ground between fully open-source licenses and traditional proprietary software licenses. It's kind of neat because it's a parameteric license, in that you can change some parameters while leaving the text of the license unchanged. For codon, the "C…

From what I've seen is the "Change Date" is usually updated so you always have a few years older software as Apache License and the latest software as BSL

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

#23

Post by itishappy »

jjk7 wrote: post #21
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-…

The differences seem relatively minor. Your specific example can be worked around by using a tuple; which in most cases does what you want.

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 does not preserve insertion order, unlike Python's as of 3.6.

> Tuples: Since tuples compile down to structs, tuple lengths must be known at compile time, meaning you can't convert an arbitrarily-sized list to a tuple, for instance.

https://docs.exaloop.io/codon/general/differences

Pretty sure this means the following doesn't work either:

    config = { "name": "John Doe", "age": 32 }
Note: It looks like you can get around this via Python interop, but that further supports the point that this isn't really Python.

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

#24

Post by bpshaver »

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

Who is out here mixing types in a list anyway?

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

#25

Post by orf »

bpshaver wrote: post #24
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-…

Who is out here mixing types in a list anyway?

It’s common to have a list of objects with different types, but which implement the same interface. Duck typing of this kind is core to Python.

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

#26

Post by CaptainNegative »

bpshaver wrote: post #24
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-…

Who is out here mixing types in a list anyway?

I often find myself mixing Nones into lists containing built-in types when the former would indicate some kind of error. I could wrap them all into a nullable-style type, but why shouldn't the interpreter implicitly handle that for me?

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

#27

Post by orf »

quotemstr wrote: post #20
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-…

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.

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

#28

Post by timwaagh »

It's a really expensive piece of software. They do not publish their prices because of it. I don't think it's reasonable to market such products onto your average dev because of it. Anyhow Cython and a bunch of others provide a free and open source alternative.

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

#29

Post by nicce »

bpshaver wrote: post #24
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-…

Who is out here mixing types in a list anyway?

Everyone who chooses the Python in the first hand.

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

#30

Post by itishappy »

bpshaver wrote: post #24
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-…

Who is out here mixing types in a list anyway?

The json module returns heterogenous dicts.

https://docs.python.org/3/library/json.html

Post reply on HN