10 ms·

> 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

> 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-typing https://docs.exaloop.io/codon/language/collections#strong-ty...): l = [1, 's'] It's confusing to call this a "Python compiler" when the constraints it imposes pretty fundamentally change the nature of the language.

odo1242 2y ago
Yeah, it feels closer to something like Cython without the python part.
quotemstr 2y ago
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 they had to. At least Mojo merely claims to be Python-like. Unlike Codon, it doesn't claim to be Python then note in the fine print that it doesn't uphold Python contractual language semantics.
- adammarples 2y ago
  Well would you claim that Python 3.5 isn't python?
  - stoperaticless 2y ago
    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)
    - thesz 2y ago
      > 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.
      - KeplerBoy 2y ago
        The words "any" and "all" have a different meaning.
      - skeledrew 2y ago
        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.
        stoperaticless 2y ago
        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”)
- orf 2y ago
  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.
  - actionfromafar 2y ago
    The trade-off is a bit of speed.
    - cjbillington 2y ago
      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.
      - Someone 2y ago
        > 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.
  - dathinab 2y ago
    if you claim > high-performance Python implementation then no this aren't trade-offs but breaking the standard without it truly being necessary most important this will break code in a subtle and potentially very surprising way they could just claim they are python like and then no one would hold them for not keeping to the standard but if you are misleading about your product people will find offense even if it isn't intentionally
  - baq 2y ago
    dicts ordering keys in insertion order isn't an implementation detail anymore and hasn't been for years.
jjk7 2y ago
The differences seem relatively minor. Your specific example can be worked around by using a tuple; which in most cases does what you want.
- itishappy 2y ago
  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 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.
  - dathinab 2y ago
    > 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 even really a performance benefit compared to utf-8 as utf-8 only using us-ascii letters _is_ us-ascii and you don't have to use unicode aware string operations
    - robjwells 2y ago
      Yeah this is a baffling decision. I’d like to know what the motivation is. ASCII doesn’t even contain € or £.
    - 2y ago
bpshaver 2y ago
Who is out here mixing types in a list anyway?
- orf 2y ago
  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.
  - bpshaver 2y ago
    Good point.
- CaptainNegative 2y ago
  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?
  - bpshaver 2y ago
    Yeah, that seems fair.
- nicce 2y ago
  Everyone who chooses the Python in the first hand.
  - bpshaver 2y ago
    Well, I'm one of those people, and I feel that I rarely do this. Except if I have a list of different objects that implement the same interface, as another commenter mentioned.
- itishappy 2y ago
  The json module returns heterogenous dicts. https://docs.python.org/3/library/json.html https://docs.python.org/3/library/json.html
BiteCode_dev 2y ago
For a real compiler try nuitka.
wpietri 2y ago
Yeah, this right here would kill it for me: > Strings: Codon currently uses ASCII strings unlike Python's unicode strings. That rules out almost anything web-ish for me. The use case I could imagine is places where you have a bunch of python programmers who don't really want to learn another language but you have modest amounts of very speed-sensitive work. E.g., you're a financial trading company who has hired a lot of PhDs with data science experience. In that context, I could imagine saying, "Ok, quants, all of your production code has to work in Codon". It's not like they're programming masters anyhow, and having it be pretty Python-ish will be good enough for them.
- wpietri 2y ago
  Ah, looking further, I find this about the company: "Their focus lies in bridging the gap between these two aspects across various domains, with a particular emphasis on life sciences and bioinformatics." That makes sense as a sales pitch. "Hey, company with a lot of money! Want your nerds to go faster and need less expensive hardware? Pay us for magic speed-ups!" So it's less a product for programmers than it is for executives.
- Retr0id 2y ago
  >> Strings: Codon currently uses ASCII strings unlike Python's unicode strings. Yikes. These days I wouldn't even call those strings, just bytes. I can live with static/strong typing (I prefer it, even), but not having support for actual strings is a huge blow.

odo1242 2y ago

Yeah, it feels closer to something like Cython without the python part.

quotemstr 2y ago

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 they had to. At least Mojo merely claims to be Python-like. Unlike Codon, it doesn't claim to be Python then note in the fine print that it doesn't uphold Python contractual language semantics.

adammarples 2y ago
Well would you claim that Python 3.5 isn't python?
- stoperaticless 2y ago
  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)
  - thesz 2y ago
    > 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.
    - KeplerBoy 2y ago
      The words "any" and "all" have a different meaning.
    - skeledrew 2y ago
      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.
      - stoperaticless 2y ago
        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”)
orf 2y ago
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.
- actionfromafar 2y ago
  The trade-off is a bit of speed.
  - cjbillington 2y ago
    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.
    - Someone 2y ago
      > 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.
- dathinab 2y ago
  if you claim > high-performance Python implementation then no this aren't trade-offs but breaking the standard without it truly being necessary most important this will break code in a subtle and potentially very surprising way they could just claim they are python like and then no one would hold them for not keeping to the standard but if you are misleading about your product people will find offense even if it isn't intentionally
- baq 2y ago
  dicts ordering keys in insertion order isn't an implementation detail anymore and hasn't been for years.

jjk7 2y ago

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

itishappy 2y ago
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 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.
- dathinab 2y ago
  > 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 even really a performance benefit compared to utf-8 as utf-8 only using us-ascii letters _is_ us-ascii and you don't have to use unicode aware string operations
  - robjwells 2y ago
    Yeah this is a baffling decision. I’d like to know what the motivation is. ASCII doesn’t even contain € or £.
  - 2y ago

bpshaver 2y ago

Who is out here mixing types in a list anyway?

orf 2y ago
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.
- bpshaver 2y ago
  Good point.
CaptainNegative 2y ago
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?
- bpshaver 2y ago
  Yeah, that seems fair.
nicce 2y ago
Everyone who chooses the Python in the first hand.
- bpshaver 2y ago
  Well, I'm one of those people, and I feel that I rarely do this. Except if I have a list of different objects that implement the same interface, as another commenter mentioned.
itishappy 2y ago
The json module returns heterogenous dicts. https://docs.python.org/3/library/json.html https://docs.python.org/3/library/json.html

BiteCode_dev 2y ago

For a real compiler try nuitka.

wpietri 2y ago

Yeah, this right here would kill it for me: > Strings: Codon currently uses ASCII strings unlike Python's unicode strings. That rules out almost anything web-ish for me. The use case I could imagine is places where you have a bunch of python programmers who don't really want to learn another language but you have modest amounts of very speed-sensitive work. E.g., you're a financial trading company who has hired a lot of PhDs with data science experience. In that context, I could imagine saying, "Ok, quants, all of your production code has to work in Codon". It's not like they're programming masters anyhow, and having it be pretty Python-ish will be good enough for them.

wpietri 2y ago
Ah, looking further, I find this about the company: "Their focus lies in bridging the gap between these two aspects across various domains, with a particular emphasis on life sciences and bioinformatics." That makes sense as a sales pitch. "Hey, company with a lot of money! Want your nerds to go faster and need less expensive hardware? Pay us for magic speed-ups!" So it's less a product for programmers than it is for executives.
Retr0id 2y ago
>> Strings: Codon currently uses ASCII strings unlike Python's unicode strings. Yikes. These days I wouldn't even call those strings, just bytes. I can live with static/strong typing (I prefer it, even), but not having support for actual strings is a huge blow.