[Lasagna]: Added docstring and fixed format

[Metallifax]

Fixed and under-indentation from lines 9-15 in exemplar. Added a module level docstring in both stub and exemplar files.

[github-actions]

Hi & Welcome! 👋🏽 👋

Thank you for contributing to exercism/python 💛 💙 -- we really appreciate it! 🌟 🌈

This is an automated [🤖 🤖  ] comment for the maintainers of this repository, notifying them of your contribution. 🎉
Someone will review/reply to your changes shortly. (usually within 72 hours.)
You can safely ignore the maintainers section below.

⚠️  Please be aware ⚠️

     This repo does not generally accept Pull Requests unless they follow our contributing guidelines and are:

     1️⃣     Small, contained fixes for typos/grammar/punctuation/code syntax on [one] exercise,
     2️⃣     Medium changes that have been agreed/discussed via a filed issue,
     3️⃣     Contributions from our [help wanted][help-wanted] issue list,
     4️⃣     Larger (previously agreed-upon) contributions from recent & regular (within the last 6 months) contributors.

    Pull Requests not in these categories will be closed. 😞

---

💙 It looks like you are changing/adding files in a Concept Exercise! 💙

‼️  Did You...

Update & rebase your branch with any (recent) upstream changes.  Spell and grammar check all prose changes.  Run Prettier on all markdown and JSON files. (Optionally) run yapf (yapf config) to help format your code.  Run flake8 with flake8 config to check general code style standards.   Run pylint with pylint config to check extended code style standards.  Use pytest or the python-track-test-runner to test any changed example.py/exemplar.pyfiles  against their associated test files.  Similarly, use pytest or the python-track-test-runner to test any changed test files. Check that tests fail properly, as well as succeed.  (e.g., make some tests fail on purpose to "test the tests" & failure messages).  Double-check all files for proper EOL.  Regenerate exercise documents when you modified or created a hints.md file for a practice exercise.  Regenerate the test file if you modified or created a JinJa2 template file for a practice exercise. Run the generated test file result against its example.py.  Run configlet-lint if the track config.json, or any other exercise config.json has been modified.

✅️  Have You Checked:

. Are there any additional changes you need to make? Please make sure all associated files are present and consistent with your changes! Concept Exercise Anatomy .docs/hints.md .docs/instructions.md .docs/introduction.md .meta/config.json .meta/design.md .meta/exemplar.py (exemplar solution) <exercise-slug>_test.py (test file) <exercise-slug>.py (stub file) concepts/../introduction.md concepts/../about.md concepts/../links.json concepts/../.meta/config.json

🛠️    Maintainers   

Please take note 📒 of the following sections/review items 👀 ✨

🌈  Acknowledgements and Reputation

❓ Does this PR need to receive a label with a reputation modifier? medium is awarded by default. ❓ Does this contributor need to be added to the exercise authors or contributors? ❓ Does this contributor need to be added to the concept authors or contributors? ❓ Is there an associated issue or issues that should be linked to this PR?

💫  General Code Quality

Verify:  The branch was updated & rebased with any (recent) upstream changes.  All prose was checked for spelling and grammar.  Files are formatted via yapf (yapf config) & conform to our coding standards  Files pass flake8 with flake8 config & pylint with pylint config.  Changed example.py/exemplar.py files still pass their associated test files.  Changed test files still work with associated example.py/exemplar.py files. Check that tests fail properly, as well as succeed. (e.g., make some tests fail on purpose to "test the tests" & failure messages).  All files have proper EOL.  If a JinJa2 template was modified/created, was the test file regenerated? Does the regenerated test file successfully test the exercises example.py file?  The branch passes all CI checks & configlet-lint.

🌿  Changes to Concept Exercises

• ❓ Are all required files still up-to-date & configured correctly for this change?_
• ❓ Does <exercise>/.meta/design.md need to be updated with new implementation/design decisions
• ❓ Do these changes require follow-on/supporting changes to related concept documents?

✨  Where applicable, check the following ✨




(as a reminder: Concept Exercise Anatomy) Exercise introduction.md Do all code examples compile, run, and return the shown output? Are all the code examples formatted per the Python docs? Exercise instructions.md Exercise hints.md Check that exercise design.md was fulfilled or edited appropriately Exercise exemplar.py Only uses syntax previously introduced or explained. Is correct and appropriate for the exercise and story. Exercise <exercise_name>.py (stub) Includes appropriate docstrings and function names. Includes pass for each function Includes an EOL at the end Exercise <exercise_name>_test.py Tests cover all (reasonable) inputs and scenarios At least one test for each task in the exercise If using subtests or fixtures they're formatted correctly for the runner Classnames are <ExerciseName>Test Test functions are test_<test_name> Exercise config.json --> valid UUID4 Corresponding concept introduction.md Corresponding concept about.md Concept config.json All Markdown Files : Prettier linting (for all markdown docs) All Code files: PyLint linting (except for test files) All files with text: Spell check & grammar review.

🚀  Changes to Practice Exercises

Is the exercise is in line with Practice Exercise Anatomy? .docs/instructions.md(required) Was this file updated and regenerated properly? .docs/introduction.md(optional) .docs/introduction.append.md(optional) .docs/instructions.append.md (optional) Are any additional instructions needed/provided?  (e.g. error handling or information on classes) .docs/hints.md(optional) Was this file regenerated properly? .meta/config.json (required) .meta/example.py (required) Does this pass all the current tests as written/generated? .meta/design.md (optional) .meta/template.j2 (template for generating tests from canonical data) Was a test file properly regenerated from this template? .meta/tests.toml Are there additional test cases to include or exclude? Are there any Python-specific test cases needed for this exercise? <exercise-slug>_test.py Does this file need to be regenerated? Does this file correctly test the example.py file? Does this file correctly report test failures and messages? <exercise-slug>.py (required) Does this stub have enough information to get  the student started coding a valid solution?

🐣  Brand-New Concept Exercises

Is the exercise is in line with Concept Exercise Anatomy? Exercise introduction.md Do all code examples compile, run, and return the shown output? Are all the code examples formatted per the Python docs? Exercise instructions.md Exercise hints.md Check that exercise design.md was fulfilled or edited appropriately Exercise exemplar.py Only uses syntax previously introduced or explained. Is correct and appropriate for the exercise and story. Exercise <exercise_name>.py (stub) Includes appropriate docstrings and function names. Includes pass for each function Includes an EOL at the end Exercise <exercise_name>_test.py Tests cover all (reasonable) inputs and scenarios At least one test for each task in the exercise If using subtests or fixtures they're formatted correctly for the runner Classnames are <ExerciseName>Test Test functions are test_<test_name> Exercise config.json --> valid UUID4 Corresponding concept introduction.md Corresponding concept about.md Concept config.json All Markdown Files : Prettier linting (for all markdown docs) All Code files: Flake8 & PyLint linting All Code Examples: proper formatting and fencing. Verify they run in the REPL All files with text: Spell check & grammar review.

Our   💖   for all your review efforts! 🌟 🦄

[Metallifax]

And while I'm here, is there a way that contribute many more changes at once or are we better off going one concept at a time? I'd be comfortable doing many changes in a branch but I'll take it under advisement.

@BethanyG, another thing I noticed that in this exercise the dashes are missing from the docstring param and return lines after the type in both files, example:

:param elapsed_bake_time: int baking time already elapsed.
:return: int remaining bake time derived from 'EXPECTED_BAKE_TIME'.

as opposed to

:param elapsed_bake_time: int - baking time already elapsed.
:return: int - remaining bake time derived from 'EXPECTED_BAKE_TIME'.

Just to be certain, from what I gathered from #2974, you said you could take them or leave them, but I also get the argument that they can look noisy to the reader. Easy fix, but I'm the same, take it or leave it kind of deal. Let me know what you think.

[BethanyG]

@Metallifax - Thank you so much for this. Sincere apologies for not replying sooner. I'm a bit swamped, so won't be able to review until the weekend.

Just to be certain, from what I gathered from #2974, you said you could take them or leave them, but I also get the argument that they can look noisy to the reader. Easy fix, but I'm the same, take it or leave it kind of deal. Let me know what you think.

I know its an answer you want, but I remain strongly ambivalent. 😆 I truly will go with whatever feels right to you. The only thing I am really "allergic" to is the use of a colon, since that symbol sets off the params.

And while I'm here, is there a way that contribute many more changes at once or are we better off going one concept at a time? I'd be comfortable doing many changes in a branch but I'll take it under advisement.

I think as long as you keep that branch up to date with things that are merged into main (and your PR description is clear), we should have no issues. Normally, we'd want changes for each exercise in their own PRs, but since these are stubs and docstrings, I think its fine to put them all in one group. That might also make it easier to make them more consistent. Just keep your eyes peeled for changes to main. Merge conflicts are not as fun as you might think. 😉

And I will be around at the weekend, should you have any questions or issues or need help. ✨

[Metallifax]

@BethanyG No worries on the wait, just happy to invest my time here.

I know its an answer you want, but I remain strongly ambivalent.

Then we'll let statistics decide! I went through each of the concepts that have full docstrings and tallied how many docstrings have dashes and which ones don't in this Google sheet. The results are:

Dashes:	7
No Dashes:	6

@IsaacG Also brought up how the predominant style include the dashes as per PEP257, so I'll just add the dashes as I go and fix that consistency problem at the same time if no one objects to this, get two birds stoned at once kind of deal.

Just keep your eyes peeled for changes to main. Merge conflicts are not as fun as you might think.

Should I make my own branch after this PR goes through or just reuse an older one and pull the newer changes on that? I'm used to working on branches in my private repositories where I can freely branch at my leisure, but I assume the rules change a bit in a production repo -- would love the advice when time allows. TIA.

[Metallifax]

Another possible change I noticed is the spacing between the # TODO: lines and the functions:

# TODO: define the 'EXPECTED_BAKE_TIME' constant
# TODO: consider defining the 'PREPARATION_TIME' constant
#       equal to the time it takes to prepare a single layer


# TODO: define the 'bake_time_remaining()' function
def bake_time_remaining():
    """Calculate the bake time remaining.
    ...

Double space between PREPERATION_TIME and the bake_time_remaining() TODO

    ...
    based on the `EXPECTED_BAKE_TIME`.
    """

    pass

# TODO: define the 'preparation_time_in_minutes()' function
#       and consider using 'PREPARATION_TIME' here

# TODO: define the 'elapsed_time_in_minutes()' function

Single space between the rest.

My reasoning stems from the two blank lines between functions and classes rule (E302), but hey, this is the first exercise so how much that really matters is debatable.

[BethanyG]

Hi @Metallifax - I am soooo sorry at the delay! 😱 Really really swamped with things.

Should I make my own branch after this PR goes through or just reuse an older one and pull the newer changes on that? I'm used to working on branches in my private repositories where I can freely branch at my leisure, but I assume the rules change a bit in a production repo -- would love the advice when time allows. TIA.

I'd do a fresh one. Maybe name it for the issue we have open for docstrings? That helps remind me what it's for. 😄

Because you don't have write access to the repo, the easiest workflow is to fork and then branch. That way, you can push to your fork, and open an PR from there.

To answer your questions about the TODOs:

for this one

# TODO: define the 'EXPECTED_BAKE_TIME' constant
# TODO: consider defining the 'PREPARATION_TIME' constant
#       equal to the time it takes to prepare a single layer


# TODO: define the 'bake_time_remaining()' function
def bake_time_remaining():
    """Calculate the bake time remaining.

My logic was that the top 2 TODOs were module-level constants, so I wanted more space between them and the rest of the TODOs and functions in the file. But if it's looking odd to you, you can go ahead and change it. 😄 I trust your judgement on this one.

[BethanyG]

@Metallifax - thanks again for submitting these! 😄

[Metallifax]

@BethanyG Thanks for the reply and I appreciate the trust. I'll follow your tips on branching and include the spacing change of this exercise as one of the items the be patched. I'm working on portfolio stuff in preparation for internship applications and can't tell you how much it has helped to work on this repo with you guys. Cheers!