The concept exercise “Cater Waiter” on the Python track has a completely different docstring style than all of the previous concept exercises in the concept tree. (It seems like this was changed a few days ago in this PR.) Personally, I prefer the previous style, but I was also wondering why this was just changed for one exercise, and not all of them.
There also seems to be some typos in the docstrings in the stub:
On line 17, the parameter description has an extra space between (str): and The. (ocd sorry)
On line 21, it says the tuple contains (dish_name, ingredient set), where “dish name” has an underscore, which is inconsistent with other tuple content descriptions (such as on line 72: (dish name, dish special ingredients)).
On line 38, the drink_name parameter is referred to, but it is not surrounded by backticks, unlike all other parameter mentions.
On line 55, The is spelled TThe.
On line 119, the intersection parameter is said to have type “constant” (is this an actual type?), but it is actually of type “set”.
Also, the first line of the singleton_ingredients() docstring (line 115) is confusing:
Determine which dishes have a singleton ingredient (an ingredient that only appears once across dishes).
It says the function determines which dishes have a singleton ingredient, but it is actually supposed to determine which ingredients are singleton ingredients.
Thanks for this. I thought I checked these pretty thoroughly, but evidently I was tired. I’ll go back in and correct things in the stub and the exemplar, once I addressed the other issues you’ve filed here on the forum.
I think you will find that all the docstrings for both the concept exercise stubs and concept exercise exemplar files have now been changed to use the Google Style format, minus the typehinting because we don’t teach typehints here on Exercism.
There was a discussion on Discord about the format for the Python docsrings. I had thought they were already Google/NumPy style, but they were actually reStructuredText (which is the native format for Sphinx - the docs package that the Python Documentation uses).
Since they were being called out as not to a recognizable standard and the original intent was to use Google’s style, I decided to change/update them. You can see the PRs here.
I’'ll ping back when I get to this change – but please bear with me, as I have the other issues you filed to address first, along with some other tooling changes I still need to make.
The intersections are in this file, and are indeed sets of ingredients. However, they are assigned to names/constants and imported for use in the solution. Technically, constant isn’t a type, but it’s there as a reminder that it is imported. I’ll think on it a bit and see if there is something else we can do to more accurately reflect that. Open to suggestions.
Looking at the files on Github now, I see that all of them were indeed changed. Sorry for the confusion! As I was in the middle of learning mode, the change seemed rather odd.
Hmm… For me, it was clear enough from the parameter description. There being constant where a type would normally be just confused me into thinking that “constant” might be an actual type in Python.
That’s understandable, fixing typos is definitely lower priority.
P.S. Sorry for all the extra work (but I think I just found some more typos )
Can you do me a favor? Since I have a bunch of stuff to take care of already, can you log all the rest of the typos you find as an issue on the repo? It will get closed, but I can reopen it. Since there are so many at this point, its easier to track in GitHub than to go back and forth to the forum.
Many Thanks.
This is one reason why we don’t usually want to make a bunch of changes all at once – sometimes, they introduce more errors than they solve.
Alrighty. Decided to do this before the Analyzer feedback changes, since they might get more involved. This is addressed in PR 4167, to be merged after CI clears.
)