Hacker News Reader

Comment by ot | Hacker News Reader

Can we change the title to say Python-like or something similar? Based on the comments so far, it seems that the detail that it compiles its own Python-inspired language, not actual Python, is lost on many.

EDIT: A list of differences here: https://docs.exaloop.io/codon/general/differences

The summary minimizes with "many Python programs will work with few if any modifications", but it actually looks like a substantially different language.

View on HN

From the README, for those who didn't scroll that far:

"While Codon supports nearly all of Python's syntax, it is not a drop-in replacement, and large codebases might require modifications to be run through the Codon compiler. For example, some of Python's modules are not yet implemented within Codon, and a few of Python's dynamic features are disallowed. The Codon compiler produces detailed error messages to help identify and resolve any incompatibilities."

That list actually seems genuinely pretty minimal. Reading your comment I was expecting a long major list of changes, but it's only 3 things, most of which seem relatively unlikely to impact most programs, with the possible exception of dictionary sort order.

Read the entire page. Those three bullet points aren't the extent of it. This is like the difference between Ruby and Crystal; the same syntax, similar culture, but they're fundamentally different languages.

The list of small things are for data structure. However, the language is a lot less dynamic than Python:

> Since Codon performs static type checking ahead of time, a few of Python's dynamic features are disallowed. For example, monkey patching classes at runtime (although Codon supports a form of this at compile time) or adding objects of different types to a collection.

While monkey patching is maybe not done so much in Python (outside of unit testing), adding objects of different to a collection is definitely a common operation!

From what I understand, this will be possible in the future with implicit union types. Wouldn't work with _arbitrary_ types, but with a set of types that can be computed at compile time (my guess is that this is possible in most real-world cases).

Really? The lack of Unicode strings immediately disqualifies this for most things I've worked on the last few years. No emojis, no diacritics, no non-US users. Ok for internal tools for American companies with an older workforce, I guess, but I wouldn't use this for anything that takes input from the general public (e.g., customers).

I suppose I'm thinking more about data science / engineering oriented things, since that's what I tend to use Python for.

> …with the possible exception of dictionary sort order.

Which is an implementation detail that is not guaranteed by the language standard.

Porting code from 2 to 3 made me have to use a sorted dict because the code relied on the insertion order (metaclass magic operating on the class dict) but when they revamped the dictionary implementation I could do away with that fix. Until they come up with a more efficient dict and break everyone’s code again.

Does make me want to dust off the old spark parser and see what this can do with it.

That list is minimal. Elsewhere there's the no heterogenous lists and no biginteger restrictions, and it looks like import doesn't work either. Presumably no heterogenous dictionaries either - so not only unordered, but also simply typed.

For py2many, there is an informal specification here:

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Would be great if all the authors of "python-like" languages get together and come up with a couple of specs.

I say a couple, because there are ones that support the python runtime (such as cython) and the ones which don't (like py2many).

Python is a language with several implementations (PyPy, CPython, JPython). Not all python programs work in all of those implementations.

So, I think this might qualify as much as a python implementation as PyPy.

I don't think python without heterogenous lists and dictionaries is really python?

I can't think of a time I ever needed to do such a thing, and I've written many thousand lines of python. Python supports OOP, so classes will get you quite far in this regard.

Wouldn't that exclude (most) nested lists?

What do you mean by nested lists? A list of lists, that's a list with a single type.

I was thinking more a tree-like structure, with lists or values.

You convinced me to change the description of a "Python-like language" I'm working on to say "Python-like" instead of "Python": https://www.npmjs.com/package/pylang

The main challenge with those three issues, to me at least, is that it cannot even tell you, "yep, you need minor changes for Codon to work." It'll just work until it doesn't at runtime because your violates one of those three assumptions. So to migrate, we would have to go and figure out all the possible cases those things matter and guard against them. Not really unpalatable, just not so much a nice migration path.

Also, I'm not actually sure what they mean by internal dict sorting. Do they mean insertion order stability?

Ok, we've liked it in the title above.

This may or may not be the biggest concerns.

Pythonic?

Reply on news.ycombinator.com