-
-
Notifications
You must be signed in to change notification settings - Fork 47
-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
Coding style conventions/guide #101
Comments
To document our decision today, we will use This is a move away from strict adherence to the scipy API (we don't like using the name |
move code out of init.py, use standard import abbreviations, etc
We had some discussions on #94 about coding style. @jakirkham suggested we open a specific issue to discuss them.
I have three specific things that I find "inelegant" (yes, I know, it's imprecise) as currently implemented in
dask_image
.dask.array
instead ofda
,numpy
instead ofnp
. Some of these abbreviations are very ingrained in the community and the full specification is surprising to read. (Not to mention annoying to write.)__init__.py
. Again, this is unconventional.scikit-image
doesn't use these and still gets a nice API generation from sphinx, so I don't think it's a major hurdle to get sphinx to behave well for a more conventional code structure.I'll throw a bonus idea in here: we should rename
input
in all the ndimage functions. It was a bad choice from SciPy, and they're stuck with it, but I don't think dask-image should be bound by it.Anyway, whatever is decided with the above points, it should probably be codified somewhere, and preferably it should reference the style guides for bigger projects, so that these aren't "just for dask-image" conventions.
The text was updated successfully, but these errors were encountered: