I agree with Larry that the OP was asking something that might be fair to use in an interview process where perhaps an exact answer is not as important as showing how the person thinks about a process. The original question can be incomplete or vague. Do they give up? Do they ask careful questions that might elicit missing parts? Do they examine alternatives and then pick a reasonable one and document exactly which possible version(s) their presented code should solve?
In this case, as mentioned, one approach is to isolate the determination of what a word means from the rest of the problem. In effect, the code can be: - read in all lines of text. - words = function_name(text) - optionally, manipulate the words such as making them all the same case, removing some characters, throwing some way. - count the words in words remaining using some method such as a dictionary. - output reports as requested. You could then design any number of functions you can slide into place and the remaining code may continue working without changes. It may not matter if you can specify the specific definition of text if you show the general solution, and maybe instantiate some fairly simple way of making words. Note, the above logic applies not to just python but most programming environments. If someone interviewed me for a job in say, Rust, which I am just now learning out of curiosity, I might not know how to program some parts of a problem like this, let alone make use of the idioms of that language right away. But if they want someone who can rapidly learn the local ways and adapt, then the best they can do is try to see if you think like a programmer and can think abstractly and be able to do lots of work even while waiting for more info from someone on what they want for a specific part. Or, in a case like this problem, I wonder if they would want to hear a suggestion that this may more easily be done in languages that support something like the dictionary or hash or associative array concept or that have available modules/packages/crates/etc. that provide such functionality. -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Larry Martell via Python-list Sent: Saturday, June 8, 2024 11:54 AM To: Mats Wichmann <m...@wichmann.us> Cc: python-list@python.org Subject: Re: From JoyceUlysses.txt -- words occurring exactly once On Sat, Jun 8, 2024 at 10:39 AM Mats Wichmann via Python-list < python-list@python.org> wrote: > On 6/5/24 05:10, Thomas Passin via Python-list wrote: > > > Of course, we see this lack of clarity all the time in questions to the > > list. I often wonder how these askers can possibly come up with > > acceptable code if they don't realize they don't truly know what it's > > supposed to do. > > Fortunately, having to explain to someone else why something is giving > you trouble can help shed light on the fact the problem statement isn't > clear, or isn't clearly understood. Sometimes (sadly, many times it > doesn't). The original question struck me as homework or an interview question for a junior position. But having no clear requirements or specifications is good training for the real world where that is often the case. When you question that, you are told to just do something, and then you’re told it’s not what is wanted. That frustrates people but it’s often part of the process. People need to see something to help them know what they really want. > -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
