Python Program Help

[dn]

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.

Logic error?
<smirking>

(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 
RSTS-machine c.1970s?)

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
processing-
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.

+1
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

+1


>>     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?
-- 
Regards =dn