Open jymchng opened 7 months ago
By the way, will parsing literal string be better at preserving the whitespaces span without nightly? My only qualm is that Python literal string with "
might not get parsed correctly, e.g.
python!{ "
a = 2
while a != 0:
print("hello")
a -= 1
"}
I am attempting to write a proc-macro
tnconst![... python codes ...]
that gets evaluated at compile time to give atypenum::UInt/PInt/NInt
type level integer.
Why not just use a generic const parameter? You don't really need typenum
anymore these days, right?
We could remove the macro in a backwards compatible way by putting the macro behind a default-enabled feature.
However, I personally think you will be better off just copying the Context
struct to your project and avoid the dependency on inline-python
.
python!{ " a = 2 while a != 0: print("hello") a -= 1 "}
Yeah, as you already indicate, this will break parsing of string literals in the code.
I am attempting to write a proc-macro
tnconst![... python codes ...]
that gets evaluated at compile time to give atypenum::UInt/PInt/NInt
type level integer.Why not just use a generic const parameter? You don't really need
typenum
anymore these days, right?We could remove the macro in a backwards compatible way by putting the macro behind a default-enabled feature.
However, I personally think you will be better off just copying the
Context
struct to your project and avoid the dependency oninline-python
.
Hi, thank you for your prompt reply.
The main reason for using typenum
is that generic const operations are not stablized yet.
Hi @m-ou-se and @de-vri-es, thank you both for writing this crate.
Hi @m-ou-se, I am a big fan of yours, read your book on Atomics and Locks cover to cover and your blog posts on this crate.
Hi both,
I am attempting to write a proc-macro
tnconst![... python codes ...]
that gets evaluated at compile time to give atypenum::UInt/PInt/NInt
type level integer.I want my crate to stay on stable. I don't actually require the
python!{}
macro because a proc-macro cannot invoke any arbitrary macro within.However, you listed the crate with
python!{}
as a dependency, hence it brings it offstable
. I find theContext
very useful and I can use it for the backend oftnconst![... python codes ...]
.Hence, can you make the dependency an optional one?
Understand that this is a breaking change. Hence, I am also prepared to fork it - please allow me to do that as well.
Thank you.