Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Remaining TODOs in production code: platform notes, licensing questions, and one likely-stale marker

Open
  • Is something wrong?
#51 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
backend, documentation

Research direction

Start by reading the TODOs at the listed locations in mikecore/DfsDLL.py, Projections.py, DfsFile.py, Dfs123File.py, DfsuBuilder.py, and MeshFile.py, then review related issue #46 and the existing Linux tests. Determine which notes are stale, which require code or documentation decisions, and how the unresolved input and licensing questions should be settled. Done means every listed TODO has a documented resolution, appropriate code or documentation change, or has been removed when obsolete.

Written by the indexing model from the issue text.

Description

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 DeleteValue
  • mikecore/DfsFile.py:619 — # TODO: Test on dfs3 file from MIKE SHE
  • mikecore/DfsFile.py:923 — # TODO: size of item and hence the values array
  • mikecore/DfsFile.py:988 — # TODO: This assumes time in seconds?
  • mikecore/Dfs123File.py:12 — # TODO: Need to check that this is the same for all items
  • mikecore/DfsuBuilder.py:559 — # TODO unit
  • mikecore/MeshFile.py:167 — # TODO: Make into a enum
  • mikecore/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.

Dominant language
Python
Stars
5
Forks
1
Avg merge
1h 18m
Merged PRs (30d)
5

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DHI/mikecore-python

All issues in DHI/mikecore-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.