-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can you make "inline-python-macros" an optional dependency? #66
Comments
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 python!{ "
a = 2
while a != 0:
print("hello")
a -= 1
"} |
Why not just use a generic const parameter? You don't really need 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 |
Yeah, as you already indicate, this will break parsing of string literals in the code. |
Hi, thank you for your prompt reply. The main reason for using |
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.
The text was updated successfully, but these errors were encountered: