Earlier quoted context omitted.
Why would you do this over `return key, value` which produces a tuple? Just curious.
To quote the Zen of Python: Explicit is better than implicit. Readability counts.
How does that apply in this case?
A high-performance, zero-overhead, extensible Python compiler using LLVM
81–90 of 95 posts
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#82Earlier quoted context omitted.
Yeah, just because it can do that doesn't mean that it is good design.
how would you represent an arbitrary JSON array in python then? A potentially heterogeneous list seems the obvious solution.
Why would I want to do that? I'm rarely ingesting arbitrary JSON. Rather I'm designing my data structures in a sensible way and then maybe serializing them to JSON. Just because JSON can represent heterogenous lists doesn't mean it is a good idea to use heterogenous lists in my programs.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#83Earlier quoted context omitted.
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.
If your language obstructs heterogeneous lists your programs will tend to lack them. Look for classes containing multiple hashtables from the same strings to different object types as a hint that they're missed. Whether that's a feature is hard to say. Your language stopped you thinking in those terms, and stopped your colleagues from doing so. Did it force clarity of thought or awkward contortions in the implementat…
Heterogeneity is easily achieved in statically typed languages via sum types.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#84Earlier quoted context omitted.
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.
dicts ordering keys in insertion order isn't an implementation detail anymore and hasn't been for years.
I get that all dicts are now effectively an `collections.OrderedDict`, but I've never seen practical code that uses the insertion order. You can't do much with that info (no `.pop()`, can't sort a dict without recreating it) beyond maybe helping readability when you print or serialize it.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#85There is also RPython (used by PyPy) (https://rpython.readthedocs.io/), which is a strict subset of Python, allowing for static analysis, specifically for the translation logic needed by PyPy. Thus, I was told that RPython is not really intended as a general purpose language/compiler but only really specifically to implement sth like PyPy.
But it's anyway maybe an interesting comparison to Codon.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#86Earlier quoted context omitted.
All versions of python are python. If lang is not compatible with any of python versions, then the lang isn’t python. False advertising is not nice. (even if the fineprint clarifies)
> If lang is not compatible with any of python versions, then the lang isn’t python. Python versions are not compatible between themselves, as python does not preserve backward compatibility, ergo python is not python.
Interestingly I recently had to run a script I wrote for 3.11 on an old system that has 3.6, and the only thing I had to remove were a few type hints (which of course don't affect function). Seems pretty backwards compatible to me.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#87Instead of building their GPU support atop CUDA/NVIDIA [0], I’m wondering why they didn’t instead go with WebGPU [1] via something like wgpu [2]. Using wgpu, they could offer cross-platform compatibility across several graphics API’s, covering a wide range of hardware including NVIDIA GeForce and Quadro, AMD Radeon, Intel Iris and Arc, ARM Mali, and Apple’s integrated GPU’s. They note the following [0]: > The GPU mod…
Because WebGPU is a API designed for browsers, targeting hardware designs from 2016.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#88Earlier quoted context omitted.
how would you represent an arbitrary JSON array in python then? A potentially heterogeneous list seems the obvious solution.
Why would I want to do that? I'm rarely ingesting arbitrary JSON. Rather I'm designing my data structures in a sensible way and then maybe serializing them to JSON. Just because JSON can represent heterogenous lists doesn't mean it is a good idea to use heterogenous lists in my programs.
The JSON spec does not require a schema. If you want to write a library that can support any valid JSON you have little options. That's useful if you are implementing something like jq just to give an example.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#89Please stop trying to make python fast. Move over to Julia already.
Re: A high-performance, zero-overhead, extensible Python compiler using LLVM
#90Earlier quoted context omitted.
To quote the Zen of Python: Explicit is better than implicit. Readability counts.
How does that apply in this case?
"return key, value" is implicit. While "return [key, value]" is explicitly telling the full return-value. And it's (for me) more readable than "return (key, value)".