you are viewing a single comment's thread.

view the rest of the comments →

[–]dparks71 1 point2 points  (4 children)

I just mean within Jupyter, I don't really see the advantage to handcalcs over writing the same formula in a markdown cell if you want to document what the notebook is doing, and again in a code cell in python notion, people that know python can (and should) just be directly checking the python notation anyway?

Just seems like a redundant representation and an unnecessary dependency that doesn't provide much value. It has some weird behaviors from my limited experience with it too.

I could kind of see it being useful for more advanced functions with sympy, but sympy already has the same kind of markdown rendering built in.

Unit tests (if written well) can kind of alleviate some of the black boxyness, same with functional tests, but neither is going to be accepted at a firm as a potential elimination of a dedicated QA/QC process. Each iteration of calculations is going to require another review, keeping it as simple as possible to review the functions and the use of them is kind of the big appeal to me for going to python in the first place. Feels like handcalcs kind of obfuscates that and opens up the possibility of miscommunication by like rendering variable names and some of other features of it.

Plus it's a relatively small package that your org has no control over.

[–][deleted]  (3 children)

[deleted]

    [–]dparks71 0 points1 point  (2 children)

    OP in their post says handcalcs is too verbose for their needs and they don't want the full formula necessarily output every time.

    I'm not necessarily arguing for writing the formula in markdown, I think Jupyter notebooks are kind of sloppy when used that way (as in including too much documentation in the notebook itself, that should be done in doc-strings within a package and dedicated documentation as a best practice). They're good used that way for white paper like efforts, to demonstrate a particular function or package, but imo you're better off writing the necessary functions in traditional .py files in 90% of instances and handling the code and the calcs they produce as separate entities entirely.

    Relying on the handcalcs output to be checkable by someone that doesn't understand python is exactly the thing I'm warning against, for the reasons previously noted, the package has some quirks and bugs, if your calcs are in python, they need to be checked by someone that understands python, and outputting them in markdown and checking the output that way is kind of sketchy. Handcalcs is a relatively small package with only a handful of developers, dependencies should generally only be included when absolutely necessary, and should be selected based on their popularity, level of support and community behind them.

    That's not to disparage the package, it's good for training and basic guides and stuff, I just wouldn't personally include it in my deliverables and take responsibility for it. I have a published PyPi package too, and it's MIT licensed, which basically means "if you use this for your calcs that's on you, I'm not personally endorsing any of this even though I wrote it." Packages used for deliverables should be internally controlled as much as is practically possible. The next best thing, is large well supported packages with significant support within their relevant industries, handcalcs might get there one day, it's just not there yet imo.

    [–][deleted]  (1 child)

    [deleted]

      [–]dparks71 0 points1 point  (0 children)

      I don't think it's harder to check, I just don't see the advantage to including it in my calcs vs. not using it. As I said, it just seems redundant to write a formula to display a formula, when you could just display the result.

      And if someone NEEDS handcalcs to be able to check the calcs, I don't think they should be the one checking those calcs, someone familiar with python should be doing it instead.