[quotemstr]

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.

[orf]

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.

[baq]

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

[nick238]

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.

[funny_falcon]

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.

[dathinab]

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

[actionfromafar]

The trade-off is a bit of speed.

[cjbillington]

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]

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

[adammarples]

Well would you claim that Python 3.5 isn't python?

[stoperaticless]

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]

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

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

[skeledrew]

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]

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”)