Python Program Help
On 7/22/20 7:16 AM, Dennis Lee Bieber wrote:
> On Tue, 21 Jul 2020 06:38:55 -0700 (PDT), ksikor14--- via Python-list
> <python-list at python.org> declaimed the following:
> Since this is apparently a homework assignment, I'm not going to
> provide fixes -- just some comments.
(not entirely poking-fun: is a good learning opportunity for OP!)
>> (3) Prompt the user for data points. Data points must be in this format: string, int. Store the information before the comma into a string variable and the information after the comma into an integer. The user will enter -1 when they have finished entering data points. Output the data points. Store the string components of the data points in a list of strings. Store the integer components of the data points in a list of integers. (4 pts)
> Ugh! Forgive my bluntness but WHO created that "enter -1" to signal the
> end of the data input, especially when the input format is a string
> followed by an integer, using a comma to differentiate the fields. Python
> makes it so easy to use an /empty input line/ to signal end of data.
Am fairly sure that I've seen this question before - likely requiring
implementation in another language. (FORTRAN, BASIC-Plus on a VAX or
Agreed, poor form old-chap - just not cricket, wot!
>> (4) Perform error checking for the data point entries. If any of the following errors occurs, output the appropriate error message and prompt again for a valid data point.
>> If entry has no comma
>> Output: Error: No comma in string. (1 pt)
>> If entry has more than one comma
>> Output: Error: Too many commas in input. (1 pt)
>> If entry after the comma is not an integer
>> Output: Error: Comma not followed by an integer. (2 pts)
> Personally -- besides that I'd use an empty record to end input, I
Despite the fact that it would be an easy mistake for a user to make -
pressing Enter? Would it not be better to require an active decision/action?
> would NOT use "...:\n" in the prompt strings. To me it is much cleaner to
> use "...: " as the prompt, which puts the input data on the same line.
User Experience accounts for a significant proportion of the definition
of 'success', for any project!
> This coding style requires duplicating code... It also is relying on
> That makes two places that need to be edited if a change is made to the
> code. Especially if you try to sanitize the termination input. It is
>> words = point.split(",")
>> if len(words) == 1:
>> print("Error: No comma in string.")
>> elif len(words) > 2:
>> print("Error: Too many commas in input. ")
> Personally, I'd consider this an overly strict requirement -- I'd be
> expecting the /last/ ", stuff" to be the integer, and anything prior to be
> part of the author name ("Alexandre Dumas, Senior, 238")
Disagree - and one of the points of the exercise: Librarians have tomes
inches-thick which discuss 'cataloging rules' - including where commas
may, and may-not, be used!
Your point valid though, only the <last> comma has significance...
(at this time!)
> It is apparent that no test is made to ensure names output are
> shortened to the report format... One "improvement" would be to retain the
> maximum name length (and maximum count) and adjust the output formatting to
> fit those maximums.
Data should not be 'thrown away'! If the report-specification 'shortens'
the data-field, then isn't that the purpose of output-formatting?
Given all the 'pretty', I'd suggest that the learning-objectives*
include Python's string formatting language!
* um, er, given earlier comment about age/language, perhaps the words
"should have" should have appeared in that sentence?