11–20 of 34 posts
The type conversion assumptions here are real problematic. "64 bits ought to be enough for anybody"-style statements ignore integers as bitfields, large constants (eg Avogadro's number), any kind of math with large intermediate terms, all kinds of stuff. Makes me very suspect about the rest of this project when they try to glide past all of these issues with nary a mention.
The type conversion assumptions here are real problematic. "64 bits ought to be enough for anybody"-style statements ignore integers as bitfields, large constants (eg Avogadro's number), any kind of math with large intermediate terms, all kinds of stuff. Makes me very suspect about the rest of this project when they try to glide past all of these issues with nary a mention.
I don't feel they are trying to glide past anything. It's the first post in the series about a product in 0.x state, it's gotta start somewhere other than perfection and they seem to know that.
kind of like numba, isn't it ?
"While Codon does offer a JIT decorator similar to Numba's, Codon is in general an ahead-of-time compiler that compiles end-to-end programs to native code. It also supports compilation of a much broader set of Python constructs and libraries."
kind of like numba, isn't it ?
See https://docs.exaloop.io/codon/general/faq "While Codon does offer a JIT decorator similar to Numba's, Codon is in general an ahead-of-time compiler that compiles end-to-end programs to native code. It also supports compilation of a much broader set of Python constructs and libraries."
The type conversion assumptions here are real problematic. "64 bits ought to be enough for anybody"-style statements ignore integers as bitfields, large constants (eg Avogadro's number), any kind of math with large intermediate terms, all kinds of stuff. Makes me very suspect about the rest of this project when they try to glide past all of these issues with nary a mention.
Looks like you can use bigger integers and they're very explicit about it not being a drop-in replacement for Python
* Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
Judas priest, after all the effin' grief we went through to learn how to handle Unicode strings in Python 3, and to finally begin to realize their value, you take this step backward? Forget the i64 limits, the lack of native Unicode strings is a flat deal-breaker. (For example, will Codon warn if it sees an "open(encoding='UTF8')" call? Or a normal open(mode='rt') if the default local encoding is UTF8?)
It doesn't help that the same doc also mentions that
* Dictionaries: Codon's dictionary type is not sorted internally, unlike Python's
Current Python dicts are not "sorted"; rather they "preserve insertion order, meaning that keys will be produced in the same order they were added sequentially over the dictionary."[2]
This is new functionality added only recently (3.7) so its lack would not inconvenience a lot of existing code. OTOH, why did they not plan to reproduce this useful feature from the start?
Possibly they were thinking of the pypi package SortedContainers[3]?
[1] https://docs.exaloop.io/codon/general/differences
[2] https://docs.python.org/3/reference/datamodel.html#index-30
A major type-incompatibility not mentioned in the linked blog post is this, from[1], * Strings: Codon currently uses ASCII strings unlike Python's unicode strings. Judas priest, after all the effin' grief we went through to learn how to handle Unicode strings in Python 3, and to finally begin to realize their value, you take this step backward? Forget the i64 limits, the lack of native Unicode strings is a flat deal-…