These try-catch imports are supposed to “help students” but with single-quote f-strings, they actually present an unnecessary cognitive hurdle.
I fixed them using black formatter, which formatted many other lines.
Before:
_____________________________________________________________________________ ERROR collecting lasagna_test.py _____________________________________________________________________________
ImportError while importing test module '/home/semaphore/exercism/python/guidos-gorgeous-lasagna/lasagna_test.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../../../.pyenv/versions/3.13.2/lib/python3.13/importlib/__init__.py:88: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
lasagna_test.py:20: in <module>
raise ImportError(f'\n\nMISSING CONSTANT --> \nWe can not find or import the constant {item_name} in your'
E ImportError:
E
E MISSING CONSTANT -->
E We can not find or import the constant 'EXPECTED_BAKE_TIME' in your 'lasagna.py' file.
E Did you misname or forget to define it?
After:
_____________________________________________________________________________ ERROR collecting lasagna_test.py _____________________________________________________________________________
ImportError while importing test module '/home/semaphore/exercism/python/guidos-gorgeous-lasagna/lasagna_test.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../../../.pyenv/versions/3.13.2/lib/python3.13/importlib/__init__.py:88: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
lasagna_test.py:22: in <module>
raise ImportError(
E ImportError:
E
E MISSING CONSTANT -->
E We can not find or import the constant 'EXPECTED_BAKE_TIME' in your 'lasagna.py' file.
E Did you misname or forget to define it?
If the repo doesn’t currently use Black formatting, I suspect the repo maintainer isn’t particularly interested in a PR that applies Black to all the files.
Not being the maintainer, I’m not well positioned to suggest alternatives.
I’d just like to point out that PRs in general should do one thing. Conflating massive format changes with bug fixes make PRs confusing and are not ideal. That said, you probably shouldn’t change/file any Python PRs without prior maintainer (which isn’t me) buy in.
We ask that all changes to Exercism are discussed on our Community Forum before being opened on GitHub. To enforce this, we automatically close all PRs that are submitted.
I’m sure the Python maintainer will chime in here shortly
Hi @slouchpie. Thanks for wanting to contribute. It’s appreciated.
However, as the Contributing Guidelines state, we’re not accepting community contributions to this repo currently. The energy and time it takes to review the mass of community PRs means that maintainers are unable to put their time to improving the track in accordance with their existing plan.
This PR is a good example of that. It would be great to discuss the f-strings issue and see if we can come up with a nice solution to that, but a cold-PR with a net-change of 15,000 lines of code isn’t something that anyone has the time to engage with before there’s been a consensus that Black should be the new formatter on this repo.
Python uses templates to regenerate the test suites so I think if the track maintainer went forward with this, we’d also need to make sure the templates don’t reintroduce the broken f strings next time they’re run.
Track maintainer here. As Jeremy has said, we appreciate your desire to contribute — but this repo is closed to community contribution. Any potential contribution needs to be discussed here on the forum first and may or may not get approval.
Isaac is correct. We specifically do not use Black across the entire repo and we are not planning to do so any time soon. I am not interested in engaging in a discussion about it at this time given that there is not a consensus in the Python community at large that Black is the only way to format code.
Those f-strings do not toss any syntax errors, they don’t trigger pylint, they don’t cause runtime errors, and they don’t violate PEP8.
Your main critique seems to be that you found them hard to read because I chose to use a single quote for the outer wrapper. That’s not bad or broken – its a formatting choice you (and perhaps other students) disagree with.
If you want to discuss it at length with regard to f-strings in particular, I suggest you start a separate forum thread for it so that students and maintainers can weigh in meaningfully.
As Jeremy has said, submitting a PR that includes 15, 000 lines of code, changing 144 exercises/200 files all at once is burdensome for reviewers and maintainers. Especially when it changes many things beyond f-string quoting. Please don’t do that in the future.
We already Black format the generated test files. We don’t format the example files on purpose. They aren’t exemplars - they are there to prove the exercise is solvable, and they are written at the discretion of the person who ported or created the exercise for the track.
We’ve even got a few example solutions that use conventions from deprecated versions of Python. But as long as they pass tests, they meet the spec.
For what it’s worth, if you only wanted to change the linter, opening an issue on GitHub would have been preferable. That way, you could have raised your concerns here on the forums first, without feeling like the PR was rejected.
— but this repo is closed to community contribution. Any potential contribution needs to be discussed here on the forum first and may or may not get approval.