Earlier quoted context omitted.
Who is out here mixing types in a list anyway?
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.
Good point.
A high-performance, zero-overhead, extensible Python compiler using LLVM
41–50 of 95 posts
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#42Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#43Earlier quoted context omitted.
Who is out here mixing types in a list anyway?
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 use…
Agreed, I was just joking. I understand heterogenous lists are possible with Python, but with the use of static type checking I feel like its pretty rare for me to have heterogenous lists unless its duck typing.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#44Earlier quoted context omitted.
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…
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.
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
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#45> 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?
return [key, value]
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#46Earlier quoted context omitted.
The differences seem relatively minor. Your specific example can be worked around by using a tuple; which in most cases does what you want.
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 even really a performance benefit compared to utf-8 as utf-8 only using us-ascii letters _is_ us-ascii and you don't have to use unicode aware string operations
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#47The 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.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#48Previous discussion (2022): https://news.ycombinator.com/item?id=33908576
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#49> 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?
Someone who is using Python the wrong way.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#50> 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?
I've been mixing types in Python lists for several decades now. Why wouldn't you? it's a list of PyObjects.