HN user
In general, I find that compilers, transpilers, etc. are all just "interpreters", which conceptually just boil down to a given input being "re-interpreted" into a new representation. Thus, what we commonly call interpreters re-interpret programs into results, compilers just re-interpret into an executable, transpilers into a different language, etc.
Imho this is a non-issue. Python's max-function isn't limited to numerical values, but can consume iterables of anything with a defined order, i.e., things that implement the appropriate hooks in the Python data model. For such inputs, returning anything but an error (or the optionally provided default value) doesn't make much sense.
A while back I attempted to write a brainfuck interpreter in Python with similar restrictions. It was great fun!
Sometimes this may be the case but not so much here. Firstly the mention the version they used and, secondly, OtterTune are a startup based around automatic DB steup/schema optimization founded by folks from CMUs DB group, they most certainly know what they are talking about here.
From my personal experience, David Beazley's Talks/Tutorials on the matter are very enlightening.
A good starting point might be Hy [0]. Its claim to fame is being a LISP embedded in Python.
This is not strictly true. Python expressions are in fact Turing complete. For example, you can implement an entire Brainfuck interpreter [0] in a single expression.
[0] https://gist.github.com/6bab3480ab439f0e98f18d88750d3b38
It may be "close[r] to the data", but be ware Python UDFs usually still have context switches between the python interpreter and the query executor. If these pile up — as is the case if you fire off queries in, say, a loop — you will still see lousy performance. There is currently research under way, to optimize UDFs and other forms of computations over database resident data. For Python, for example, you can checkout the python to SQL compiler [0] and associated demo-paper [1] we produced for this years Sigmod. (Disclaimer: as you may have noticed thanks to that " we", I'm an author on that paper.) Though it may only support a limited subset of Python, one can already do alot with just that.
[0] https://apfel-db.informatik.uni-tuebingen.de [1]: https://db.inf.uni-tuebingen.de/publications/2022/Hirn-grust...
Not to nitpick, but do you mean the pattern matching statement when you are talking about "sum types"? Because as far as I'm aware Python doesn't have " proper" algebraic data types.
In situations like this you could use `git stash` instead of completely deleting it.
To be quite honest: I don't think there is anything along those lines. But if want to tackle it I recommend looking for PDF copy of Types and Programming Languages by Benjamin C. Pierce. It contains all necessary typing rules — barred the whole inference magic — be it System F, ADTs or Records.
EDIT: Oh and also contains the reduction rules ofcourse! Though the book assumes you now how to read inference rules. ;)
EDIT: I just found an official PDF source: http://basics.sjtu.edu.cn/~xiaojuan/tapl2016/files/Types+and...
This looks cool. If you want to delve deeper intob symbolic computation you can have a look at sympy [0]. It seems to be the "defacto standard" when it comes to Python libraries for this.
This may seem like a minor nitpick but it's something that popped out at me: italisizing a font shouldn't add or remove serifs. There is a reason why Unicode defines both sans- and serif versions of italics.
Iirc the argument bind this would be along then lines oft precendes. I.e., you didn't defend your TM against person A so why are you sueing person B.
I don't know when Portugal started this, but in Germany there is at least the concept of a "grüne Well" (literally a green wave). Simply put: if you drive at the speed limit you won't get any red lights. Sadly the german administration barely makes use of this as it doesn't make them any money...
Very cool! I'd love to do some bytecode rewriting magic for some of my projects as well, but alas it only works for statements/expressions that are legal python syntax. :/
I've added some images and a disclaimer to the readme. In case you still want to see the proper results. ;)
Sadly (or luckily?) I don't know anyone who has/uses/has to use a braille display. But I think that if the "reader"/viewer doesn't know from the get go that the following characters aren't text it'll for sure throw them through a loop... :'D
Very cool! :D
I also thought about adding color support via ANSI escape sequences, but for this project I decided against using them to keep things simple a widely accessible.
Though python has a massive set of "included batteries", simple images aren't included in those. This makes me very sad sometimes and I usually just fall back to simple BMP files... :/
Similar characters actually exist in unicode as well irrc.
...On a side note, I think you kickstarted me down the path of abstracting the drawing algorithms and implicit matrix protocol out, just to make it easier to implement this with different character sets. One set for example could be [U+2596 .. U+259F, U+2589], so basically just a 2x2 grid per character.
Very nice! I was thinking of adding something akin to this as well, at least in terms of image dithering. :)
But I'm still torn as the well behaved python programmer in me wants to add pillow as a dependency for that and the not so well behaved one wants *0* dependencies. I think I'll add it as an extra-dep when get around to it.
I thought I remembered seeing something similar a while back... This explains it! Thanks for the info. :D
It works for me using Pragamata Pro (my trusty default) and some preinstalled ones (at least mac) those being PT Mono, Spot Mono, and Andale Mono. It shouldn't be an issue as long as the "empty braille character", i.e. U+2800, doesn't get kerned to hell and back by the font.
Not to get snarky (and certainly not at you, thanks for the info ;) ) but Microsoft owns Windows 10 as well as GitHub. If anyone could add a better default monospace font to the mix it would be them... :D
Yeah, I've noticed that a lot of "monospace" fonts don't actually use the same character width for all characters... What makes it even worse is that the "monospace" font used by GitHub is one of those. It screws me over from time to time as I like to format things nicely and use a lot of unicode...
I think I will need to add some images to the readme as well, just make it looks less wonky. :(
I made dotmatrix over the weekend and I thought some you might enjoying something like it. The library is written in pure python without any dependencies. As of now I've included some simple drawing functions using Bresenham's line/circle/AA ellipse algorithms and even a function for Bézier curves with arbitrary amounts of control points using De Casteljau's algorithm.
Now don't quote me on this but I think you pronounce it:
Ffs Microsoft get your shit together, windows may be dead to you but there a over a million running systems that you bought your way into. So sit up straight in your chair and get through that decade long backlog...
Gotta say though that I intuitivly think of the dict union operator x | y as {* * x, * * y}. Which is how I would have joined two dictionaries before, when I wanted to produce a complete copy of one, i.e. not use dict.update.