[Tutor] Critiquing a function exercise from dabeaz (Was: Type annotation errors)

boB Stepp robertvstepp at gmail.com
Fri Jun 5 21:40:15 EDT 2020


Don't know why, but dn's email did not arrive in my inbox.  I am beginning
to believe that Gmail applies random filtering to writers from UK, NZ,
Australia, etc.  So I've copied and pasted from the Tutor Archives.

DL Neil wrote:
> boB wrote:
>> Peter wrote:
>> In terms of following along with Beazley's course material this would be
>> cheating.  Classes have not been presented yet.  Even very simple ones.
>> ~(:>))
>> 
>>> PPS: For someone who knows a little C the obvious fix for your version 
>>> is to
>>> cast the union to the expected type:

>This is a little difficult to rationalise:
>- we are not trying to get ahead of the course material
>- but we are prepared to launch into complex (if not complicated) mypy
>Apologies, I can see the 'why' but can't help but feel it is only that 
>imbalance which has led to the problem...

HALT!  *I* am solely responsible for mixing in type annotations, not Mr.
Beazley.  As you know I have been working on learning these.  While I am
working through his course I am practicing type annotations.  Beazley does
briefly mention type annotations, but so far he has not asked the reader of
his course to do anything with them.  Any resulting messy annotations are
the sole responsibility of daboB (*not* dabeaz).

>I'd like to discuss the (actual) problem, and then dispute the 
>claim-pursuant:

>[from another part of the thread]
><<<
>In this exercise set he wishes to create a module fileparse which can
>accept a csv-like file and allow one to obtain a list of dictionaries (one
>per file row) if the file has headers or a list of tuples if not,
>representing the collection of records.  Additionally he wishes to allow
>for setting arguments to choose only certain data columns (If the file has
>headers), do type conversions by providing a list of functions to do the
>conversions, and setting a different delimiter than the default comma.  At
>the end of the exercises he comments:

>"If you’ve made it this far, you’ve created a nice library function that’s
>genuinely useful. You can use it to parse arbitrary CSV files, select out
>columns of interest, perform type conversions, without having to worry too
>much about the inner workings of files or the csv module."
> >>>

>I'm firmly joining with others who have suggested that rather than 
>"nice" it is actually quite 'ugly'. The routine, as-is, violates the 
>Single Responsibility Principle (SRP). It is trying to deal with CSV 
>files that have column headings AND those which don't. That's not an 
>horrendous crime, per-se (but see later). However, the idea that the 
>routine will output either a list of dicts or a list of tuples, most 
>certainly is a major transgression!

Bear in mind that as I have been working my way through the material
Beazley has been gradually adding in more Python and having the reader make
modifications to already existing code that the reader has written.  To my
eyes, he has gradually been tightening up the code and making it more
realistic.  For the current function exercise that is taking quite a
beating in this forum I will report the next segment of the story.  I am
now in "3.3 Error Checking"
(https://dabeaz-course.github.io/practical-python/Notes/03_Program_organization/03_Error_checking.html).
In "Exercise 3.8:  Raising exceptions" he says:

"The parse_csv() function you wrote in the last section allows
user-specified columns to be selected, but that only works if the input
data file has column headers.

Modify the code so that an exception gets raised if both the select and
has_headers=False arguments are passed. For example:

>>> parse_csv('Data/prices.csv', select=['name','price'],
>>> has_headers=False)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
     File "fileparse.py", line 9, in parse_csv
         raise RuntimeError("select argument requires column headers")
         RuntimeError: select argument requires column headers
         >>>
"

I had wondered about this point as well as some others and was curious
whether he would address it later.  So, typically for the course so far, he
gets around to addressing this particular item.  It would not surprise me
at all if the parse_csv module eventually morphs into something less likely
to raise Tutor hackles.  I will keep you posted!

-- 
Wishing you only the best,

boB Stepp


More information about the Tutor mailing list