Hacker News new | ask | show | jobs
by fernly 1255 days ago
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-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

[3] https://pypi.org/project/sortedcontainers/

1 comments

Breaking compatibility from the current spec/functionality of python should be a definite no-no for any implementation. That being said, I can still appreciate that they didn't try to write their own busted unicode implementation since many other ones have contributed to security issues.
I don't understand why you say that. Like, it's gonna cost them in adoption to diverge, they don't need a lecture to understand that, they are doing what meets their needs and sharing it.
The implementation is optimised for genomics, thats why.