matthew-brett / nibabel

95%

placeholder: 96%

LAST BUILD ON BRANCH remove-imageopener-decorator

branch: remove-imageopener-decorator

CHANGE BRANCH

x

Reset

• remove-imageopener-decorator
• 419-using-regexps
• add-chriss-neuro-radio-jpeg
• add-coveralls
• add-minc2-tests
• add-numpy-pre-testing
• add-ordereddict
• add-proxy-slicing
• add-utils-module
• add-voxel-size
• alternative-gifti-fix
• array-image-casting
• arraywriter-refactor
• ascconv-refactor
• back-compat-gifti
• bat-script-fix
• better-installation-advice
• brainvoyager-docs
• breaking-parrec
• cached-arr-seq-append
• caret-fixes-continued
• cifti-fix
• cifti2-refactorings
• cifti2-refactorings2
• clean-dependencies
• concat-image-outside-loop
• defer_viral_memmap
• dicom-thoughts
• doc-fix-2.0
• doc-pre-release
• docs-using-get-fdata
• endian-fix-streamlines
• enh/cifti2
• error-on-slice
• expand-affine-tutorial
• explaining-proxies
• extend-testing
• extending-parrec
• fancy-deprecations
• fix-cifti2-pixdim-check
• fix-dft-old-pydicom
• fix-dicom-link
• fix-doctests
• fix-freesurfer-load
• fix-negative-ecat
• fix-par-parsing
• fix-pdf-build
• fix-shebang-lines
• fix-travis-tests
• fix-viewer-slicing
• fix-warns-testing
• fixing-parrec
• generalize-header-data-layout
• gifti-serialization-bug
• img-size-fix
• in-memory
• in-memory-doc-rewrite
• int-long-check-fix
• integration
• intercept-scaling
• intp-support
• mac-precision-fix
• master
• minc-defense
• minor-edits-391
• minor-fixes-suggestions
• mmap-api
• module-global-gzip
• more-dtypes-for-fileslice
• more-lenient-trackvis
• more-multiframe-links
• more-requirements
• move-mailing-list
• move-parrec2nii
• nasty-windows-fixes
• nifti12-refactor
• none-none-fix
• offset_length_lists
• parrec-arrayproxy-api
• parrec-codes-to-1
• parrec-endianness
• parrec-fix-refactor
• parrec-top-level
• parrec-v4-support
• pauls-viewer
• percentiling
• ppc64le-fixes
• pre-release-changelog
• prepare-for-arrayproxy
• py33-byte-string-recursion
• py35-doctests
• pydicom-compatibility
• python-org-appveyor
• read-par-exts
• rebase-eric-work
• refactor-api-validators
• refactor-aseq-init
• refactor-create-empty-header
• refactor-csa-test
• refactor-ecat
• refactor-gifti-init-and-docstrings
• refactor-nibabel-data
• refactor-parrec
• refactor-tck-read
• refactor-test-tools
• refactor-test-write_data
• refactor-to-new-api
• release-preparations
• reload-reloaded
• remove-_write_header
• remove-doctest-markup
• remove-minc-header-data-fetch
• reworking-raw-scaling
• rst-table-py32-fix
• scratch
• sheared-rank-fix
• small-fixes
• small-streamlines-edits
• smoothing-tutorial
• suggestion-for-per-array-dicts
• test
• test-500
• test-homu-bot
• tiny-fixes
• tmp
• to-containers
• to-output-space
• to-relative-imports
• todo
• trk-1
• trk-codes-with-check
• trk-hdr-str
• update-plus-for-296
• update-release-list
• use-pre
• use-scriptrunner
• viewer-requires-mpl-1p3
• viewer-tiny-edits
• windows-fixes
• wip-scaling-refactor
• workaround-allclose-bug
• zenodo-dois
• zero-offset-on-load
• zero-terminal-strings

Build # 583

Build Type

push

travis-ci

Committed by matthew-brett

Commit Message

RF: remove imageopener decorator

I was finding the decorator for ImageOpener confusing.

Pros for the decorator:

* Adding allowed `valid_exts` and specifying how it should be opened happen in
  the same place (decorator at top of class);
* Using a decorator allows change of internal storage of the ImageOpener
  class.

Cons:

* Decorators can be hard to read, especially when the decorator is a function
  call (so the decorator returns a decorator);
* It's hard to see at a glance which extensions are valid, because the
  decorator is at the top of the class, and adds later to `valid_exts`,
  whereas the apparent definition of `valid_exts` is after the docstring;
* The decorator has to know about the internals of the class (in this case,
  the `valid_exts` attribute);
* The role of the decorator is to signal that a certain extension has to be
  opened in a certain way, but it seems a bit odd that this signal also adds
  the extension to the class.  To me it seems more natural to make this signal
  a line of its own, next to the `valid_exts` definition;
* Modifying the ImageOpener dictionary directly doesn't stop us from making
  the dictionary a property or another object type, and changing the
  underlying storage;
* No decorator means less code.

Run Details

16698 of 17516 relevant lines covered (95.33%)

0.95 hits per line