Comment by quotemstr

Comment by quotemstr a day 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.

orf a day 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.

Reply View 6 replies

baq a day ago

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

Reply View | 1 reply
- nick238 12 hours ago
  
  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.
  
  Reply View | 0 replies
dathinab a day 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

Reply View | 0 replies
actionfromafar a day ago

The trade-off is a bit of speed.

Reply View | 2 replies
- cjbillington a day 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.
  
  Reply View | 1 reply
  
  Someone a day 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.
  
  Reply View | 0 replies

adammarples a day ago

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

Reply View 4 replies

stoperaticless a day 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)

Reply View | 3 replies
- thesz a day 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.
  
  Reply View | 2 replies
  
  skeledrew 4 hours 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.
  
  Reply View | 0 replies
  
  KeplerBoy a day ago
  
  The words "any" and "all" have a different meaning.
  
  Reply View | 0 replies