Skip to content
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

Open
jymchng opened this issue Mar 25, 2024 · 4 comments
Open

Can you make "inline-python-macros" an optional dependency? #66

jymchng opened this issue Mar 25, 2024 · 4 comments

Comments

@jymchng
Copy link

jymchng commented Mar 25, 2024

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 a typenum::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 off stable. I find the Context very useful and I can use it for the backend of tnconst![... 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.

@jymchng
Copy link
Author

jymchng commented Mar 25, 2024

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
"}

@de-vri-es
Copy link
Contributor

I am attempting to write a proc-macro tnconst![... python codes ...] that gets evaluated at compile time to give a typenum::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.

@de-vri-es
Copy link
Contributor

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.

@jymchng
Copy link
Author

jymchng commented Mar 26, 2024

I am attempting to write a proc-macro tnconst![... python codes ...] that gets evaluated at compile time to give a typenum::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.

Hi, thank you for your prompt reply.

The main reason for using typenum is that generic const operations are not stablized yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants