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@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
--
https://mail.python.org/mailman/listinfo/python-list
