The remaining TODOs in production code are notes to self rather than defects. Listing them so they are visible, and because at least one looks stale enough to just delete.
Platform-conditional behaviour
mikecore/DfsDLL.py:56 and mikecore/Projections.py:43 — # TODO: On linux, this looks different! Both sit where a path or library name is resolved. The package does ship and test on Linux, so either the note has been addressed and is stale, or there is a real remaining difference worth naming.
Licensing
mikecore/Projections.py:114 and mikecore/Projections.py:329 — # TODO: should this require a license? An open question about whether these projection entry points need a license check. Answering it once, in the docs, is more useful than the question sitting in two places.
Possibly stale
mikecore/DfsFile.py:611 — a bare # TODO: implement sitting above four lines that appear to do the work. Most likely a leftover; worth confirming and removing.
Unresolved details
mikecore/DfsFile.py:570 and :604 — identical: # TODO: Check which items are loaded and which delete value to store, and if only one, store in DeleteValuemikecore/DfsFile.py:619 — # TODO: Test on dfs3 file from MIKE SHEmikecore/DfsFile.py:923 — # TODO: size of item and hence the values arraymikecore/DfsFile.py:988 — # TODO: This assumes time in seconds?mikecore/Dfs123File.py:12 — # TODO: Need to check that this is the same for all itemsmikecore/DfsuBuilder.py:559 — # TODO unitmikecore/MeshFile.py:167 — # TODO: Make into a enummikecore/MeshFile.py:323 — # TODO: Throw an exception?
MeshFile.py:323 is the same class of question as #46 — what to do with input that does not match expectations — and could be settled with it.
No code change proposed. The point is that the package currently carries these only in the source, where nobody looking at the issue tracker can see them.
The remaining TODOs in production code are notes to self rather than defects. Listing them so they are visible, and because at least one looks stale enough to just delete.
Platform-conditional behaviour
mikecore/DfsDLL.py:56andmikecore/Projections.py:43—# TODO: On linux, this looks different!Both sit where a path or library name is resolved. The package does ship and test on Linux, so either the note has been addressed and is stale, or there is a real remaining difference worth naming.Licensing
mikecore/Projections.py:114andmikecore/Projections.py:329—# TODO: should this require a license?An open question about whether these projection entry points need a license check. Answering it once, in the docs, is more useful than the question sitting in two places.Possibly stale
mikecore/DfsFile.py:611— a bare# TODO: implementsitting above four lines that appear to do the work. Most likely a leftover; worth confirming and removing.Unresolved details
mikecore/DfsFile.py:570and:604— identical:# TODO: Check which items are loaded and which delete value to store, and if only one, store in DeleteValuemikecore/DfsFile.py:619—# TODO: Test on dfs3 file from MIKE SHEmikecore/DfsFile.py:923—# TODO: size of item and hence the values arraymikecore/DfsFile.py:988—# TODO: This assumes time in seconds?mikecore/Dfs123File.py:12—# TODO: Need to check that this is the same for all itemsmikecore/DfsuBuilder.py:559—# TODO unitmikecore/MeshFile.py:167—# TODO: Make into a enummikecore/MeshFile.py:323—# TODO: Throw an exception?MeshFile.py:323is the same class of question as #46 — what to do with input that does not match expectations — and could be settled with it.No code change proposed. The point is that the package currently carries these only in the source, where nobody looking at the issue tracker can see them.