paultag
I wrote down a few of my thoughts a few weeks ago at https://notes.pault.ag/why-write/ -- I find myself scanning text to see if it's LLM before I actually engage with the content.
It is getting harder to do by the day, and has slowly moved from a mental exercise (look for specific markers) into a "gut feel" based on how the pieces fit together.
Most of this just has to be done. I take your point, but I couldn't find much. And I'm a debian developer - who knows what most non-Debian people would find. The best APIs are in `libapt`, which is C++, and cgo won't work with that all that well.
So, yes, you're right. This is yet another project. That's uncool, but there's not a ton of other ways out, short of me making a clean C shared library and get everyone to switch to that :)
Sorry, I didn't document this since i'm rushing stuff out as soon as I get it together -- I was looking at the Trove classifiers, and setting candidate to true iff it says it's Python 3 compatable but no Python 3 package :)
Also, our releases aren't timed, they're based on bug count, so the timing of the releases wasn't even the main point (and doesn't really matter) :)
I also typoed Python 3 as Python 2 in one of the lines, so, uh, just switch those two numbers. I'm pretty sure it works like that.
Either way, getting Buster off Python 2 means the transition will be more bug free, since we'll have a bit of slack time.
Yes, it's hilarious that version of Mailmain needs to be ported to Python 3.
It works both ways, and bi-directional interop is intended! Just `import hy` then you can import any `.hy` on `sys.path` :D
(yes, this means you can make Hy code pip installable, just like Hy itself!)
If you want a clear failure mode - if this installs requests globally, think about the chaos if you're on Debian stable, with 0.12.1, before the API break - after a pip install, you may end up with all the software on your system broken.
When this happens, please don't file bugs with Debian. Thanks.
* Python (sucks)
* 2-way
* Yep! CLOS syntax
* Yep! hy.contrib.loop - to be promoted soon
* Yep, they're OK, relies on dispatch char that's static
* Very little, actually - it compiles to (pretty sane) Python AST / Bytecode - so good pdb works to debug Hy :)
if anyone wants to learn more, we have a pretty sweet team over in #hy on freenode, and have some MLs and stuff sprinkled around.
I, of course, prefer (defn) and (first) / (rest), but I know killing (defun) (car) and (cdr) will make a few people go nuts.
We'll have to make it sane before 1.0 :)
Thanks for hacking with Hy :3
Allll taken care of :)
In Python, the AST approximates this. Perhaps I'm lax in usage, but I think there's a continuum of homoiconicity - some things (like C) have no language functionality to deal with their own source code. Other languages (like CL) are very good at this, since you write the language in it's own data structures. Other languages (like Python, or Racket) aren't homoiconic, but they approximate what makes homoiconicity special.
Firstly, AST visitors in Python (or whatever) are clunky and lots of code to do what you say. Hell, I think that it's borderline unpythonic.
You have to consider lots of things, such as whether or not you can put an stmt where you're inserting code, and write a lot of, frankly ugly, Python code to do it.
Hy macros (and really Lisp macros) that are first-class members of the language are nice, because they're a lot more clean to write.
In addition, since Hy does some nasty stuff under the hood to generate clean Python AST, you can do stuff like:
(print (if true true flase))
Fundamentally, a Hy macro IS an AST macro, just on the parsed and tokenized Hy code (which turns into AST), rather then fiddling with Python AST (which isn't even a stable interface).
That answer the question? :)
Happy to answer questions.