71–80 of 95 posts
Earlier quoted context omitted.
The json module returns heterogenous dicts. https://docs.python.org/3/library/json.html
Yeah, just because it can do that doesn't mean that it is good design.
> Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon. This is targeting a Python subset, not Python itself. For example, something as simple as this will not compile, because lists cannot mix types in Codon ( https://docs.exaloop.io/codon/language/collections#strong-…
> Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
That rules out almost anything web-ish for me.
The use case I could imagine is places where you have a bunch of python programmers who don't really want to learn another language but you have modest amounts of very speed-sensitive work.
E.g., you're a financial trading company who has hired a lot of PhDs with data science experience. In that context, I could imagine saying, "Ok, quants, all of your production code has to work in Codon". It's not like they're programming masters anyhow, and having it be pretty Python-ish will be good enough for them.
Earlier quoted context omitted.
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…
> Strings: Codon currently uses ASCII strings unlike Python's unicode strings. wtf this is a supper big issue making this basically unusable for anything handling text (and potentially even just fixed indents, if you aren't limited to EU+US having non us-ascii idents in code or text is common, i.e. while EU companies most times code in english this is much less likely in Asia, especially China and Japan. it isn't eve…
> Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon. This is targeting a Python subset, not Python itself. For example, something as simple as this will not compile, because lists cannot mix types in Codon ( https://docs.exaloop.io/codon/language/collections#strong-…
Yeah, this right here would kill it for me: > Strings: Codon currently uses ASCII strings unlike Python's unicode strings. That rules out almost anything web-ish for me. The use case I could imagine is places where you have a bunch of python programmers who don't really want to learn another language but you have modest amounts of very speed-sensitive work. E.g., you're a financial trading company who has hired a lot…
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.
> Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon. This is targeting a Python subset, not Python itself. For example, something as simple as this will not compile, because lists cannot mix types in Codon ( https://docs.exaloop.io/codon/language/collections#strong-…
Yeah, this right here would kill it for me: > Strings: Codon currently uses ASCII strings unlike Python's unicode strings. That rules out almost anything web-ish for me. The use case I could imagine is places where you have a bunch of python programmers who don't really want to learn another language but you have modest amounts of very speed-sensitive work. E.g., you're a financial trading company who has hired a lot…
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.
numba, cython, pypy...
Earlier quoted context omitted.
The json module returns heterogenous dicts. https://docs.python.org/3/library/json.html
Yeah, just because it can do that doesn't mean that it is good design.
> Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon. This is targeting a Python subset, not Python itself. For example, something as simple as this will not compile, because lists cannot mix types in Codon ( https://docs.exaloop.io/codon/language/collections#strong-…
Who is out here mixing types in a list anyway?
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!
The challenge is not just to make Python faster, it's to make Python faster __and__ port the ecosystem of Python modules to your new environment.
Earlier quoted context omitted.
Yeah, just because it can do that doesn't mean that it is good design.
It is the design of JSON! Which is a reflection of the same dynamic typing choice made in the original design of Javascript.
Tell me again why we somehow standardized on sending the equivalent of JSObject.toString() for everything? Especially when "standardized" isn't