-
Notifications
You must be signed in to change notification settings - Fork 336
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
Why "Only lower-case latin letters allowed in names, not ..." #28
Comments
I also wonder about this. How about other characters, e.g. underscores? One type of name that would be useful to me would be numbers. This is useful e.g. for singleton dimensions. Their values could be set automatically, e.g. They would still have to be unique (there's no way to disambiguate two singleton dimensions this way) but this is understandable; it would still be useful in many situations regardless. |
Thanks for good questions, guys.
Yup. Einops enforces better code style (reliable, maintainable and readable code - that what it was created for), this is primarily to prevent 't for token, T for time' and things alike. Be verbose, you'll say thanks to yourself! That said, this decision is open for reconsidering in future releases if there are important use-cases that current API doesn't meet.
Underscores reserved in advance if some additional flags will be required. That way those will be disambiguated with passed dimensions. Other characters can't be passed with kwargs, AFAIK.
Current way is: |
|
Thanks for the reply. I don't feel too strongly either way about enforcing style; it just seemed like a simple thing to add. As for numbers, |
Unfortunately, this produces even more questions down the road: rearrange(x, 'a 2 -> 2 a')
rearrange(x, 'a 2 2 -> 2 a 2') # which one is which?
rearrange(x, '2 4 -> 4 2') # hey, I thought it is reshape, not transpose! Axis
Thanks for coming up with examples. Wouldn't
I agree it is not good example :) So far I didn't meet need myself to write long axis names, but camelCased identifiers are easier to read, I agree with that. |
Sure, but my "glue" code writes many But it is still confusing that |
I respectfully disagree. If this library is used to implement a formula, it would make sense to follow the symbols and case from the formula. Thanks for the trick with |
+1 for relaxing this. I think a better rule would be supporting any valid Python identifier as a name: Python 3 names are a bit more complex with unicode support, but I would at least support any valid Python 2 name, i.e.,
|
There is enough consensus to relax requirement. Thanks everyone for input. From now on
Code in master is already updated to allow new friendly axes. |
Nice! Just to clarify: Is |
Nice catch @shoyer
|
This feature became part of einops 0.3 release. |
Is there a reason that einops does not support upper latin letters?
I would like to use upper and lower letters.
The text was updated successfully, but these errors were encountered: