We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Brandon Rhodes expressed it well at PyCon https://youtu.be/x-kB2o8sd5c?t=1048
In his example,
import piano piano.Bench() # yes!
Is preferable to
import piano piano.PianoBench() # no!
We should not bake the namespace into the name itself.
Similarly for the Hy models, we should have
hy.List hy.Expression hy.Dict
etc. not
hy.HyList hy.HyExpression hy.HyDict
like we have now.
The text was updated successfully, but these errors were encountered:
Contrast with #1045.
Sorry, something went wrong.
We could always import hy automatically, which also pollute the global scope a bit less.
hy
We could also leave eval in there but not auto import from hy.core.language import eval like we do now.
eval
from hy.core.language import eval
Then Hy's eval would be hy.eval, (not hy.hy-eval) and Python's builtin would just be eval.
hy.eval
hy.hy-eval
Successfully merging a pull request may close this issue.
Brandon Rhodes expressed it well at PyCon
https://youtu.be/x-kB2o8sd5c?t=1048
In his example,
Is preferable to
We should not bake the namespace into the name itself.
Similarly for the Hy models, we should have
etc. not
like we have now.
The text was updated successfully, but these errors were encountered: