@ignore

[jernejfrank]

Solves #1168.

Changes

• implemented ignore decorator
• used it internally in mutate to automatically hide helper functions --> resolved a TODO
• exposed it for general use

How I tested this

• unit test
• on the abstract mutate example (for both step and mutate)

Checklist

• [x] PR has an informative and human-readable title (this will be pulled into the release notes)
• [x] Changes are limited to a single goal (no scope creep)
• [x] Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• [x] Any change in functionality is tested
• [x] New functions are documented (with a description, list of inputs, and expected output)
• [x] Placeholder code is flagged / future TODOs are captured in comments
• [x] Project documentation has been updated if adding/changing functionality.

[jernejfrank]

Looks good! Small nits. One thought -- is @ignore (the name I suggested) the best name?

Other thoughts (would love your ideas):

• @hamilton_ignore
• @exclude
• @hamilton_exclude

And another thought -- should we have an option in @mutate and step to not ignore them? E.G. is there any way we may want to also include it in the pipeline (instinct says no here...)

Having a look with fresh eyes I agree, we should make it explicit that it is for hamilton to avoid confusion. How about hamilton_skip?

[zilto]

Looks good! Small nits. One thought -- is @ignore (the name I suggested) the best name? Other thoughts (would love your ideas):

• @hamilton_ignore
• @exclude
• @hamilton_exclude

And another thought -- should we have an option in @mutate and step to not ignore them? E.G. is there any way we may want to also include it in the pipeline (instinct says no here...)

Having a look with fresh eyes I agree, we should make it explicit that it is for hamilton to avoid confusion. How about hamilton_skip?

Thoughts on naming:

• we have @cache(behavior="ignore")
• we can think of caching as "skipping a node"
• As far as I understand, using @ignore is equivalent to prefixing the function with _. Instead of the decorator name indicating "what it does" (ignore, exclude), why not indicate "what it is". For consistency with the Hamilton documentation, I would call this @helper or @utility because you're indicating that this is a utility function.

Other nit:

• use underscores instead of whitespaces in path examples/mutate/abstract functionality blueprint

[elijahbenizzy]

I think it should be very specific that Hamilton is the one doing it -- so I'm in favor of @hamilton_exclude.

That said, I don't think this should be the first way to do things (it should be with _), but there are times it'll be useful (the docs here hit it right, it should show up in the docs, but not in the "How-to" section)

[elijahbenizzy]

Looks good, let's just change the wording of the docs to indicate that _ is preferred!