[HN Gopher] Codon: A high-performance Python-like compiler using...
___________________________________________________________________
Codon: A high-performance Python-like compiler using LLVM
Author : arshajii
Score : 231 points
Date : 2022-12-08 15:05 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| maxloh wrote:
| What's the difference with mypyc [0] ? It also compiles Python to
| native code.
|
| [0]: https://github.com/mypyc/mypyc
| return_to_monke wrote:
| the last commit to it's repo was 2 years ago.
| okso wrote:
| > The mypyc implementation and documentation live in the
| mypyc subdirectory of the mypy repository. > Since mypyc uses
| mypy for type checking, it's convenient to use a single
| repository for both. > Note that the mypyc issue tracker
| lives in this repository! Please don't file mypyc issues in
| the mypy issue tracker.
|
| See https://github.com/mypyc/mypyc/blob/master/show_me_the_co
| de....
| slt2021 wrote:
| power of Python is in ecosystem of libraries, not only Python
| syntax.
|
| Without the ecosystem of libraries, I am afraid use cases for
| Codon will be very very limited. Because Python developers (just
| like Node) got used to thinking: Need to do X? Lets see if I can
| pip install library that does it.
|
| Ultimately, python is like super flexible glue between ecosystem
| of libraries that lets anyone build and prototype high quality
| software very quickly
| victoryhb wrote:
| If Codon becomes similar enough to Python, it will be trivial
| to port Python libs to it, thus opening Codon to the vast
| Python ecosystem.
| slt2021 wrote:
| The only trivial thing in software is hello world, anything
| more complicated or useful for end users is usually far from
| being trivial, in my experience.
| _frkl wrote:
| What's the story with Python libraries that have
| c-modules/binary parts to it? Would those work? If not, then
| the previous comment stands, IMHO.
| yayr wrote:
| Can it run PyTorch, TF etc?
| PaulHoule wrote:
| How does this relate to
|
| https://cython.org/
|
| ?
|
| Would it be possible to write performance-sensitive parts of a
| Python system in Codon and link that to a CPython or PyPy runtime
| that supports more dynamic features?
| bastawhiz wrote:
| Cython takes python-ish code and compiles it to C for use as
| CPython C extensions. This compiles directly to machine code
| without the need for CPython, as far as I can tell.
| weinzierl wrote:
| I want the opposite. Is there a project that compiles to python
| (either source or bytecode)?
|
| Sort of a graalvm for python?
| odo1242 wrote:
| WebAssembly? Try compiling something to WebAssembly and running
| it in python?
| weinzierl wrote:
| I haven't thought of that. It's a good idea. I know how to
| compile to WebAssembly but how do I run it in python?
|
| A quick search leads to pywasm and it is even native python.
| But is it usable? Any other options?
| syrusakbary wrote:
| Wasmer Python can be used if you want to run Wasm in
| Python. Hope this helps!
|
| https://github.com/wasmerio/wasmer-python
| grumpopotamus wrote:
| https://coconut-lang.org/
| IceHegel wrote:
| would love to see actual benchmarks
| arshajii wrote:
| We do have a benchmark suite at
| https://github.com/exaloop/codon/tree/develop/bench and results
| on a couple different architectures at
| https://exaloop.io/benchmarks
| _aavaa_ wrote:
| Why are do the C++ implementations perform so poorly?
| camel-cdr wrote:
| My guess for word_count and faq is that the C++
| implementation uses std::unordered_map, which famously has
| quite poor performance. [0]
|
| [0] https://martin.ankerl.com/2019/04/01/hashmap-
| benchmarks-01-o...
| memco wrote:
| Don't have anything significant, but giving this a quick test
| with some of my advent of code solutions I found it to be quite
| a bit slower: time python day_2.py
| ________________________________________________________
| Executed in 57.25 millis fish external
| usr time 25.02 millis 52.00 micros 24.97 millis
| sys time 25.01 millis 601.00 micros 24.41 millis
| time codon run -release day_2.py
| ________________________________________________________
| Executed in 955.58 millis fish external
| usr time 923.39 millis 62.00 micros 923.33 millis
| sys time 31.76 millis 685.00 micros 31.07 millis
| time codon run -release day_8.py
| ________________________________________________________
| Executed in 854.23 millis fish external
| usr time 819.11 millis 78.00 micros 819.03 millis
| sys time 34.67 millis 712.00 micros 33.96 millis
| time python day_8.py
| ________________________________________________________
| Executed in 55.30 millis fish external
| usr time 22.59 millis 54.00 micros 22.54 millis
| sys time 25.86 millis 642.00 micros 25.22 millis
|
| It wasn't a ton of work to get running, but I had to comment
| out some stuff that isn't available. Some notable pain points:
| I couldn't import code from another file in the same directory
| and I couldn't do zip(*my_list) because asterisk wasn't
| supported in that way. I would consider revisiting it if I
| needed a single-file program that needs to work on someone
| else's machine if the compilation works as easily as the
| examples.
| crucialfelix wrote:
| It looks like you are compiling and running. Try compiling to
| an executable and then benchmark running that
| arshajii wrote:
| I would guess the bulk of the time is being spent in
| compilation. You might try "codon build -release day_2.py"
| then "time ./day_2" to measure just runtime.
| ubj wrote:
| Very interesting--Codon can generate standalone executables,
| object files, and LLVM IR [1]. It has strong typing for functions
| and argument return values [2]. Syntax looks more compact than
| Cython.
|
| Looking forward to giving Codon a try!
|
| [1]: https://docs.exaloop.io/codon/general/intro
|
| [2]: https://docs.exaloop.io/codon/language/functions
| CyberDildonics wrote:
| _Codon is a high-performance Python compiler that compiles Python
| code to native machine code without any runtime overhead_
|
| Further down:
|
| _Codon is a Python-compatible language, and many Python programs
| will work with few if any modifications:_
| harvie wrote:
| Unfortunately stuff like this never makes it to the upstream. And
| i am afraid to ask why. We had pypy for years, but never got
| merged with python. That is why there are still minor
| incompatibilities between pypy and "The Python", so it's not that
| useful as it might have been if it got merged with cpython at
| some point.
| camdenreslink wrote:
| No need to be afraid. The Python C extension API makes it very
| hard to make a JIT work well because of how it is implemented.
| C extensions are also part of why Python is so popular in the
| first place. If everybody wrote pure Python (like they write
| pure JavaScript), then the reference implementation would
| probably look like Pypy.
| dr_zoidberg wrote:
| I got a massive jump in performance when moving from Python 3.8
| to 3.10 (over some function call optimizations I think, based
| on the project). And 3.11 got even better (up to 50% faster on
| special cases, and 10~15% on average) with respect to 3.10.
| Python 3.12 is already getting even more speedups and a there's
| a lot more down the road[0].
|
| But Python core developers value keeping "not breaking anyones
| code" (Python 3 itself was a huge trip on that aspect and
| they're not making that mistake again), that's why things may
| seem slow on their end. But work is being done, and the results
| are there if you benchmark things.
|
| [0] See https://github.com/faster-
| cpython/ideas/blob/main/FasterCPyt... however that's over a
| year old already and I'm sure I've read/heard more specifics
| amelius wrote:
| Interesting. What is the status of the GIL these days?
| ris wrote:
| Exactly the same as it ever was, but if you're doing cpu-
| heavy stuff on python objects you're doing it wrong because
| they'll never be Fast.
| gjvc wrote:
| same. for my work project, 3.11 was performance-equivalent to
| pypy 3.9
| laerus wrote:
| It's not like you can just "merge" pypy into python, they are
| totally different implementations. CPython is written in C and
| PyPy is written in RPython which is a subset of the python
| language that gets compiled, into into an interpreter with JIT
| support. You can actually write an interpreter for any language
| using RPython and their toolset, for example Ruby
| https://github.com/topazproject/topaz
| williamstein wrote:
| Morever, a wonderful aspect of standard CPython is that you
| can compile it from source on a huge range of architectures
| in less than 5 minutes. Building Pypy from source is more
| difficult, and Pypy is significantly less portable (e.g.,
| there is no viable WebAssembly version of Pypy).
| danbmil99 wrote:
| The number one question for me would be, is it interoperable with
| existing Python and libraries?
| ot wrote:
| Can we change the title to say Python-like or something similar?
| Based on the comments so far, it seems that the detail that it
| compiles its own Python-inspired language, not actual Python, is
| lost on many.
|
| EDIT: A list of differences here:
| https://docs.exaloop.io/codon/general/differences
|
| The summary minimizes with "many Python programs will work with
| few if any modifications", but it actually looks like a
| substantially different language.
| adsharma wrote:
| For py2many, there is an informal specification here:
|
| https://github.com/py2many/py2many/blob/main/doc/langspec.md
|
| Would be great if all the authors of "python-like" languages
| get together and come up with a couple of specs.
|
| I say a couple, because there are ones that support the python
| runtime (such as cython) and the ones which don't (like
| py2many).
| dang wrote:
| Ok, we've liked it in the title above.
| darawk wrote:
| That list actually seems genuinely pretty minimal. Reading your
| comment I was expecting a long major list of changes, but it's
| only 3 things, most of which seem relatively unlikely to impact
| most programs, with the possible exception of dictionary sort
| order.
| wpietri wrote:
| Really? The lack of Unicode strings immediately disqualifies
| this for most things I've worked on the last few years. No
| emojis, no diacritics, no non-US users. Ok for internal tools
| for American companies with an older workforce, I guess, but
| I wouldn't use this for anything that takes input from the
| general public (e.g., customers).
| darawk wrote:
| I suppose I'm thinking more about data science /
| engineering oriented things, since that's what I tend to
| use Python for.
| [deleted]
| KerrAvon wrote:
| Read the entire page. Those three bullet points aren't the
| extent of it. This is like the difference between Ruby and
| Crystal; the same syntax, similar culture, but they're
| fundamentally different languages.
| antoinealb wrote:
| The list of small things are for data structure. However, the
| language is a lot less dynamic than Python:
|
| > Since Codon performs static type checking ahead of time, a
| few of Python's dynamic features are disallowed. For example,
| monkey patching classes at runtime (although Codon supports a
| form of this at compile time) or adding objects of different
| types to a collection.
|
| While monkey patching is maybe not done so much in Python
| (outside of unit testing), adding objects of different to a
| collection is definitely a common operation!
| unsafecast wrote:
| From what I understand, this will be possible in the future
| with implicit union types. Wouldn't work with _arbitrary_
| types, but with a set of types that can be computed at
| compile time (my guess is that this is possible in most
| real-world cases).
| williamstein wrote:
| You convinced me to change the description of a "Python-like
| language" I'm working on to say "Python-like" instead of
| "Python": https://www.npmjs.com/package/pylang
| jxy wrote:
| > Since Codon performs static type checking ahead of time, a
| few of Python's dynamic features are disallowed. For example,
| monkey patching classes at runtime (although Codon supports a
| form of this at compile time) or adding objects of different
| types to a collection.
|
| This may or may not be the biggest concerns.
| linuxftw wrote:
| Python is a language with several implementations (PyPy,
| CPython, JPython). Not all python programs work in all of those
| implementations.
|
| So, I think this might qualify as much as a python
| implementation as PyPy.
| e12e wrote:
| I don't think python without heterogenous lists and
| dictionaries is really python?
| linuxftw wrote:
| I can't think of a time I ever needed to do such a thing,
| and I've written many thousand lines of python. Python
| supports OOP, so classes will get you quite far in this
| regard.
| otikik wrote:
| Pythonic?
| Waterluvian wrote:
| The main challenge with those three issues, to me at least, is
| that it cannot even tell you, "yep, you need minor changes for
| Codon to work." It'll just work until it doesn't at runtime
| because your violates one of those three assumptions. So to
| migrate, we would have to go and figure out all the possible
| cases those things matter and guard against them. Not really
| unpalatable, just not so much a nice migration path.
|
| Also, I'm not actually sure what they mean by internal dict
| sorting. Do they mean insertion order stability?
| wiremine wrote:
| From the README, for those who didn't scroll that far:
|
| "While Codon supports nearly all of Python's syntax, it is not
| a drop-in replacement, and large codebases might require
| modifications to be run through the Codon compiler. For
| example, some of Python's modules are not yet implemented
| within Codon, and a few of Python's dynamic features are
| disallowed. The Codon compiler produces detailed error messages
| to help identify and resolve any incompatibilities."
| LarsDu88 wrote:
| Do people not know about numba which unlike this project is FOSS
| and integrates with numpy???
| nerdponx wrote:
| And Numba is actually CPython, unlike this which is just
| "Python-like".
|
| There's also Nuitka as yet another alternative.
|
| Or you're going to use a "Python-like" compiled language,
| consider using Nim.
| ipsum2 wrote:
| For context, Numba also uses the LLVM and it works with Python
| code via decorators.
| killingtime74 wrote:
| Doesn't it require you to annotate every function if you want
| to compile to a binary? That makes it more like Cython than
| this.
| https://numba.readthedocs.io/en/stable/user/pycc.html#overvi...
| xapata wrote:
| Numba doesn't market itself very well.
| bornfreddy wrote:
| Does it make sense to use Numba with Django / Flask / FastApi?
| LarsDu88 wrote:
| If you're trying to do intense numerical computations on the
| backend...
| poulpy123 wrote:
| after reading it's not a python compiler but a compiled language
| based on the python syntax
| JonChesterfield wrote:
| One of the faq things refers in passing to integers being 64bit
| instead of arbitrary precision. That's a bit more fundamental
| than some cpython modules don't work. Haven't found a language
| reference yet.
|
| edit: it's statically typed ahead of time - that feels like
| something that needs a detailed description of what it's doing,
| given the baseline of like-python
| bogwog wrote:
| I wonder if the differences will cause any real compatibility
| issues with existing Python libraries?
| williamstein wrote:
| It would cause major issues to libraries for mathematics
| (such as sympy or sagemath) that assume integers are
| arbitrary precision. Large integers are common in number
| theory and cryptography, where people also care very much
| about performance.
| pmontra wrote:
| I googled 'codon and django' and unsurprisingly found a lot of
| bioinformatic stuff. I tried to add language and compiler to no
| avail. The only query that got results was codon python compiler.
| Overall I think it's a name that clashes with a lot of DNA/RNA
| research.
|
| While searching I found a paper from 2021 about Codon [1]. The
| author is not in the About page of Exaloop [2] but the supervisor
| of that thesis is there. From the "Future Work" section:
|
| > we plan to add union types and inheritance. On the IR side
| [Intermediate Representation], we hope to develop additional
| builtin transformations and analyses, all the while expanding the
| reach of existing passes. As far as library support, we plan to
| port existing high-performance Python libraries like NumPy [...]
| to Codon; this will allow Codon to become a drop-in replacement
| for Python in many domains.
|
| Maybe they already did.
|
| [1] Codon: A Framework for Pythonic Domain-Specific Languages by
| Gabriel L. Ramirez
| https://dspace.mit.edu/bitstream/handle/1721.1/139336/Ramire...
|
| [2] https://exaloop.io/about.html
| inetknght wrote:
| Having worked in the DNA analysis space and admittedly haven't
| read the article... my first thought was that Codon was some
| python library for DNA stuffs that gets compiled via LLVM for
| performance.
| melenaboija wrote:
| > "...typically on par with (and sometimes better than) that of
| C/C++"
|
| What makes it faster than C++?
|
| I see this in the documentation but I am not sure it helps me
| (not an expert):
|
| > C++? Codon often generates the same code as an equivalent C or
| C++ program. Codon can sometimes generate better code than C/C++
| compilers for a variety of reasons, such as better container
| implementations, the fact that Codon does not use object files
| and inlines all library code, or Codon-specific compiler
| optimizations that are not performed with C or C++.
| __ryan__ wrote:
| JIT.
| ot wrote:
| JIT can be faster than a static compiler if it takes
| advantage of runtime feedback, but that's not the case here:
|
| > 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.
| boomanaiden154 wrote:
| It can be, but if you're using PGO, the performance gains
| from JIT are a lot less significant and you lose the
| compilation overhead at runtime that you have with JIT.
| sambeau wrote:
| Who would create a language that only has ASCII strings in this
| day and age?
| [deleted]
| naasking wrote:
| Someone who's just trying to get something up and running.
| Unicode is complicated.
| tasty_freeze wrote:
| Here is the quote of the thing you are referring to:
|
| > Codon currently uses ASCII strings unlike Python's unicode
| strings.
|
| Note the word "currently." Implementing this while also
| tracking the constantly evolving Python language through its
| various versions is a lot of work. They apparently prioritizing
| other things over this particular aspect.
| jnxx wrote:
| Just out of curiosity: Why is it possible to compile Common Lisp
| Code (or Scheme, or Clojure) to high-performance native or jit-
| compiled code, but not Python? It is said that "Python is too
| dynamic", but is not everything in Lisp dynamic, too?
|
| And none of these languages is less powerful than Lisp, lack
| Unicode support, or whatever, so this can't be the reason.
| hathawsh wrote:
| The demand for compiled Python hasn't been as high as the
| demand for other languages, so the number of people who have
| worked on it is much smaller than the number who have built
| JITs for ECMAScript and others. Python has long been fast
| enough for many things, and where it isn't, it's easy to call C
| code from CPython.
|
| Python does have lesser-used dynamic capabilities that probably
| don't exist in Common Lisp. Those capabilities make it
| difficult to optimize arbitrary valid Python code, but most
| people who need a Python compiler would be happy to make
| adjustments.
| miohtama wrote:
| It's because Python object attributes can change any time, as
| they are accessed dynamically. Nothing can be inlined easily.
| The object structure is pointer heavy.
|
| Here is some old 2014 post:
|
| http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/
|
| As other commenters pointed out, some of these Python features,
| which are unused 99,99% time, could be sacrified for additional
| speedup by breaking backwards compatibility.
| register wrote:
| The same applies to Common Lisp. Maybe it's because type
| deduction is more difficult in Python than in CL?
| mytherin wrote:
| It is possible to JIT compile Python just fine. There are
| projects like PyPy that have been doing this for a long time
| [1]. The reason these alternative projects never take off is
| because many of Python's most used libraries are written
| against CPython's C API. This API is giant, and exposes all of
| the nitty gritty implementation details of the CPython
| interpreter. As a result, changing _anything_ significant about
| the implementation of the interpreter means those libraries no
| longer work. In order to not break compatibility with the
| enormous amounts of packages the internals of the CPython
| interpreter are mostly locked in at this point with little
| wiggle room for large performance improvements.
|
| The only real way out is to make Python 4 - but given the
| immense pain of the Python 2 -> 3 transition that seems
| unlikely.
|
| [1] https://www.pypy.org
| xapata wrote:
| Ugly, confusing naming choices: ``@par`` instead of
| ``@parallel``.
| jlokier wrote:
| How do you feel about _`def`_ instead of _`define`_?
| tomas789 wrote:
| What is the difference between Codon and Pypy other than Codon
| not being targeted as a drop-in replacement for Cpython?
| arshajii wrote:
| Some info on that at
| https://docs.exaloop.io/codon/general/faq#how-does-codon-
| com......
| williamstein wrote:
| Their benchmarks (https://exaloop.io/benchmarks) show that
| Codon is much, much faster than pypy. I also just tried some
| microbenchmarks with their fib example (iterated many times
| with higher parameters) and got similar results. It's
| unfortunate for now that this isn't open source, but it's
| really valuable to demonstrate to us Python lovers what's
| possible using LLVM!
| cogman10 wrote:
| Their benchmarks are not to be trusted (after reading the
| source).
|
| - They cheat, they rewrite code to use coden specific
| features to "win" (ie, parallelization and GPU
| optimizations)
|
| - They don't warm up. They are simply running their
| competition directly rather than allowing any sort of
| warmup. (In other words, they are measuring cold boot and
| startup time)
|
| Now, if they want to argue about startup time or whatever
| mattering for performance then fine. However, the
| representation of "20x faster!" is simply deception.
|
| TBF, they are upfront about cheating
|
| > Further, some of the benchmarks are identical in both
| Python and Codon, some are changed slightly to work with
| Codon's type system, and some use Codon-specific features
| like parallelism or GPU.
| williamstein wrote:
| Thanks for doing the work to point all of this out.
| "Benchmarketing".
| qwefsdf wrote:
| Anybody claiming it's almost Python is kidding themselves. This
| compiler needs to do static type checking. This is inherently
| impossible in Python. Not just because of some obscure corner
| cases that nobody uses. It's baked into the language itself.
|
| Reality-check: Why do you think type hints and type checkers like
| mypy and pyright take such a long time to get going and even they
| are not there yet? If this was all so easy with just ignoring
| some obscure rarely used features then mypy would work with
| essentially no type annotations, all just automatic inferences.
| Anybody who has tried to work with type annotations in Python
| knows how hard this is.
|
| So, those guys are quite obviously overselling their product. I
| can understand it, academic life is hard, and once you've
| completed your Ph.D., what can you do. You need to stand out. But
| these claims don't pass the smell test, sorry.
| LargoLasskhyfv wrote:
| What about GraalVM? Are they overselling, too?
| brrrrrm wrote:
| does this support any form of FFI? It'd be nice if users could
| shim in lightweight APIs that clone libraries like numpy/pytorch
| -- it'd immediately make some machine learning super portable!
| grumpopotamus wrote:
| Any benchmark comparisons to mypyc yet?
| redleader55 wrote:
| Free for non-production use... it's a "no" for me.
| williamstein wrote:
| Woah - also, their license automatically becomes open source
| (Apache) three years from now.
| kevincox wrote:
| The problem with these is always security updates. If you
| want to run on the old stuff you have to make your own
| security patches. Of course maybe that is exactly something
| that it makes sense to pay for.
| blahgeek wrote:
| It's also confusing... I mean, what does "non-production use"
| mean anyway? Does it mean "non-commercial use"? Or
| "testing/debug/staging environment"? Or "does not produce any
| valuable output"...?
| worldsavior wrote:
| It means if a company uses this program, they can't use it
| without paying the developer.
| dragonwriter wrote:
| > It means if a company
|
| "company" is not a particularly well-defined term.
| georgyo wrote:
| But companies can still experiment with it without paying.
| IE, you can integrate it and run benchmarks to see if it
| would actually help your pain points.
| williamstein wrote:
| According to this article
| https://perens.com/2017/02/14/bsl-1-1/ about the Business
| Source License, the intention conveyed by the word
| "production" for that license is use "in any capacity that is
| meant to make money".
| dmos62 wrote:
| > "in any capacity that is meant to make money"
|
| I'll note that that's the definition of "commercial".
| williamstein wrote:
| What I want to know is: "can I add Codon to a site like
| https://cocalc.com that I host as long as users of Codon
| explicitly agree to only use it in a way that is compatible
| with the license?" I have absolutely no idea if that would
| be allowed by the rules or not.
| unsafecast wrote:
| I think that's supposed to apply to you, not your users.
| My understanding is that you pay if you make money using
| it. I can definitely see how you can easily interpret it
| in many other ways though.
| ThinkBeat wrote:
| I have not dug into the project yet, but if it delivers on the
| features it mentions it should be a game changer for a lot of
| companies, heavily invested in Python.
|
| Paying to use it seems fair.
| acedTrex wrote:
| numba is already a thing though
| sillysaurusx wrote:
| Surprised this sentiment is so common. It's like, do you want
| open source devs to work for free forever? Even Redis had to
| pivot to a business license.
|
| I'm not sure what the terms are in this particular case, but in
| general, wanting someone to pay if they're deploying it to lots
| of customers seems reasonable.
| lozenge wrote:
| I can swap one load balancer or cache for another. However,
| if my programming language has unfavourable terms I will have
| to rewrite all my code. Oh, and the knowledge I gained will
| be non transferable to another job or project because it'll
| always be a niche language. Better to spend the time learning
| how to get the same performance out of Numba or whatever
| other alternatives people mentioned here.
|
| By the way, Redis is still BSD licensed.
| redleader55 wrote:
| There are a lot of products released under GPL, for example,
| that make money for their authors. It's just that they don't
| make money with licensing fees.
| ipsum2 wrote:
| > Even Redis had to pivot to a business license.
|
| Wrong, Redis has a BSD-3 license:
| https://github.com/redis/redis
|
| Optional add-ons to Redis may have non-free licenses.
| nu11ptr wrote:
| I understand both perspectives.
|
| On the one hand, in the same way any sort of fee (even $1) is
| a big impediment to adoption over free, so is the idea that
| "if I try this out and like it, I'll now be stuck with
| whatever costs they stick me with now and in the future". In
| a fast moving world, open source is just easier because if
| you change your mind, you haven't wasted money. In addition,
| there are only so many costs a project can afford and it is
| hard to know as it progresses where those will popup, so you
| avoid when you can.
|
| That said, developers need to eat, and it is easy to
| appreciate the fact that they are letting you see the source,
| play with it, but pay if you want to use. I also fully
| support their right to license their software as they see
| fit.
| mywittyname wrote:
| A lot of developers don't have/control budgets and might not
| have the clout required to get a tool like this approved.
|
| I agree that the devs of these tools need to be paid, but
| that particular avenue presents some roadblocks.
| v3ss0n wrote:
| Why not contribution to PyPy and Why not MyPyC
| bastawhiz wrote:
| Pypy uses its own JIT. This project does AOT with LLVM. They're
| not compatible.
|
| MyPyC requires type annotations to work. This does not.
| [deleted]
| munificent wrote:
| _Since Codon performs static type checking ahead of time, a few
| of Python 's dynamic features are disallowed. For example, monkey
| patching classes at runtime (although Codon supports a form of
| this at compile time) or adding objects of different types to a
| collection._
|
| This seems like a _very_ different language from Python if it won
| 't let you do: [1, 'a string']
| didip wrote:
| I welcome this change. I am willing to sacrifice a few Python
| features for the sake of speed.
| __mharrison__ wrote:
| Not "Python", but if you are doing that in Python, then you are
| doing it wrong.
| [deleted]
| jnxx wrote:
| I have been using Python since 25 years, and never needed that
| one.
| ris wrote:
| You've never had to read arbitrary json?
| insanitybit wrote:
| I just did a quick check (apparently DuckDuckGo has a built
| in JSON validation function lol love it) and `[1, "foo"]`
| does pass their JSON validation.
|
| Not surprised but I did want to confirm.
| joshmaker wrote:
| In 25 years you've never once created a list with more than
| one type of object in it?
| cjohnson318 wrote:
| Maybe a list with ThingObject or None, but my lists are
| usually homogenous.
| mrfox321 wrote:
| thats just homogenous Sequence[Optional[T]], though.
| mangecoeur wrote:
| I have also been using python a long time and i honestly
| can't remember a time i used mixed type list.
| querez wrote:
| In my code this comes up often, e.g. when I use tuples
| instead of namedtuple or a dataclass.
| bastawhiz wrote:
| Tuples aren't lists though. Tuples are really just
| structs with indexes instead of names.
| gautamdivgi wrote:
| I'll second that. I've been doing python for a while and
| haven't used the mixed type list. I've actively avoided
| doing something like that. The situation doesn't come up
| often.
| throwaway894345 wrote:
| I mean, it depends on what you mean by "type". A list of
| some Protocol type (what other languages call "interfaces")
| is still a homogenous list even though the concrete types
| are heterogeneous. This is almost always what you want when
| you're thinking of "a heterogeneous list".
| terhechte wrote:
| Same here. If I needed that I might use a tuple.
| amelius wrote:
| And then it crashes when you convert it to JSON.
| victor82 wrote:
| Seems there is not bytearray implemented, can't test further :(
| shadowofneptune wrote:
| This gives the same feeling as AssemblyScript: it says it is one
| language, up to the point it isn't. That may make it easier for
| some people, but feels so uncertain. Both have a very slim set of
| articles in place of a proper manual; they lean on their parent
| languages.
___________________________________________________________________
(page generated 2022-12-08 23:00 UTC)