-
-
Notifications
You must be signed in to change notification settings - Fork 68
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
ipynb.fs.defs raise error if there is subscript line #35
Comments
(Not the maintainer but I have been working on this recently.) The way It is the intention of the authors that top-level assignments are only importable if they are assumed to be constants (having UPPER_CASE_NAMES). Anything else, including your example, should be ignored under the original intention - but certainly should not result in error. If you want your environment configs to be effective given this, I’d recommend moving them into a function or class initialisation. |
Fixed, AFAIC, thanks |
* Moves tests into the source. * Add lazy loading to address ipython#31 * Add a lazy import test * Remove the dataclasses dependency and test on 3.4 and 3.5 * Remove the black dependency * You hasty son of a gun * Dump the docs deploy to pass 3.6 * Escape lazy loading in python 3.4 * Filefinder compat * mkdir compat * pathlib compat in the tests * Add pypi version to deployments to travis
I've something like
on top of my code (I know I can do that in some other way…) and ipynb.fs.defs fails to import this into another module. I like to fix this myself but honestly don't have good clue what should be done, excepting it from defs or accepting it? As this case, my favor is to accepting it but I am not sure if that would be what all want.
The text was updated successfully, but these errors were encountered: