So, at first I thought this approach is doomed, because you lose comments, and what looks like a comment to Rust may not look like one to Python. Example:

  x = y // 2 # floor division

https://doc.rust-lang.org/proc_macro/struct.Span.html

And I noticed source_text, which "preserves the original source code, including spaces and comments"!!!

Why not just use this from the start then?? Seems like the easy way out, no?

(Disclaimer: I don't know Rust, can't even write hello world.)

The author likely just barely missed its introduction. While the article is written recently, the implementation it talks about was published first in early April 2019, right about when source_text was first introduced into nightly.

I am the one who contributed Span::source_text to rust. My motivation for doing that was exactly the same as the author of the blog post, and was to help implementing the cpp! macro which embeds C++ within rust just like this python! macro. https://docs.rs/cpp/ However, I still can't make use of it today because it is not stable yet, and even proc_macro2 does not implement it (and this is not trivial to implement there)

Wow. The fact that you care about this being stable implies that you plan to use this "for real"; the fact that you actually implemented this implies you care enough to put in some real work. So you must have a use case in mind, and I am not imaginative enough to guess what it might be. Is it just about convenience so you don't need to bother with putting your C++ code in a different file? Or is there more to it?

> Is it just about convenience so you don't need to bother with putting your C++ code in a different file?

Yes, mostly. I find that having the code in place makes a big difference. I do not like useless levels of indirection and context switches while coding. This way is much better then having to edit three files (the .cpp, the ffi module, and the caller) each time I want to do a call into C++ while making sure they are in sync.