A high-performance, zero-overhead, extensible Python compiler using LLVM

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

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.

parsing json is roughly of the type:

type Json = None | bool | float | str | dict[str, Json] | list[Json]

you might have similar situations for configs e.g. float | str for time in seconds or a human readable time string like "30s" etc.

given how fundamental such things are I'm not sure if there will be any larger projects (especially wrt. web servers and similar) which are compatible with this

also many commonly used features for libraries/classes etc. are not very likely to work (but idk. for sure, they just are very dynamic in nature)

so IMHO this seems to be more like a python-like language you can use for idk. some since computations and similar then a general purpose faster python

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.

The json module returns heterogenous dicts.

https://docs.python.org/3/library/json.html

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?

I've been mixing types in Python lists for several decades now. Why wouldn't you? it's a list of PyObjects.

An example related to JSON content is HTML content. I have a Python library that represents all of the standard HTML tags as a family of classes. It is like a lightweight DOM on the server side, and has resulted in a web server that does not use string based templating at all. It lets me construct trees of HTML completely in Python and then render them out with everything correctly escaped. I can also parse HTML into trees and manipulate them as I please (for e.g. scraping tasks and document transforms). It is all strongly typed using mypy and I adhere to the strictest generic typing I can manage.

Each node has a list of children, and the element type is `str|HtmlNode`. I find this vastly easier to use than the LXML ETree api, where nodes have `text` and `tail` attributes to represent interleaved text.

Interestingly, the LXML docs promote their design as follows: > he two properties .text and .tail are enough to represent any text content in an XML document. This way, the ElementTree API does not require any special text nodes in addition to the Element class, that tend to get in the way fairly often (as you might know from classic DOM APIs). https://lxml.de/tutorial.html#elements-contain-text

It could be a simple matter of taste! But I suspect that the difference between what they are describing as "classic DOM" vs what I am doing is that they are referring to experience with C/C++/Java libraries circa 2009 that had much less convenient dynamic type introspection. The "get in the way fairly often" reminds me of how verbose it is to deal with heterogenous data in C/C++/ObjC. In ObjC for example, you could have an array mixing NSString with other NSObject subclasses, but you had to do work to type it correctly. If you wanted numbers in there you had to use NSNumber which is an annoying box type that you never otherwise use. And ObjC was considered very dynamic in its day!

I have long felt that the root of much evil was the overbearing distinction between primitive and object types in C++/Java/Objective-C.

All of this is a long way of saying, I think "how to deal with heterogenous lists of stuff" is a huge question in language design, library design, and the daily work of programming. Modern languages have by no means converged on a single way to represent varying types of elements. If you want to create trees of stuff, at some level that is "mixing types in a list" no matter how you might try to encode it. Just food for thought!

Everyone who chooses the Python in the first hand.

return [key, value]

Someone who is using Python the wrong way.

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.

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

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

Pretty sure this means the following doesn't work either:

    config = { "name": "John Doe", "age": 32 }

From what I've seen is the "Change Date" is usually updated so you always have a few years older software as Apache License and the latest software as BSL

I suppose that's right, I don't think shedskin can call numpy yet, for instance. On the other hand it seems easier to put shedskin on an embedded device, for instance.

You absolutely can create a standalone binary with Cython: see the `--embed` option [1].

[1] https://cython.readthedocs.io/en/stable/src/tutorial/embeddi...