4 ms·

It's not even a subset. They break foundational contracts of the Python language without technical necessity. For example, > Dictionaries: Codon's dictionary t

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.

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.