[Tutor] Type annotation errors

[Alan Gauld]

On 04/06/2020 19:14, boB Stepp wrote:

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

But is that really useful? If you don;t know if the file has headers or
not you have to examine the type of the result to find out.
If you do know in advance you can just have two separate functions. And
if you don't know if it has headers why not create a function that
examines the file before parsing so you can write

if hasHeaders(file):
    parseHeaderFile(file)
else:
    parseNoHeaders(file)

Then you know what type of result you get. Better to check the
state of the data than try to derive types afterwards.

Functions that  try to handle two different types of input by
returning two different types of output are really just two
functions bound in one. (Different if you can return a
single data type for two inputs)

I don't know the book so maybe he is heading towards a single
unified object model with polymorphic methods so that you
can treat the two results as a single ParseResult object.
It is certainly possible to create a polymorphic solution,
but it is a lot of work.

But otherwise I'd say it's a bad design that inevitably leads
to maintenance headaches.


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

Sorry, but it sounds like it should be a library of functions.
That is one function overloaded way too far. Maintaining it
will be a nightmare. Imagine the number of regression tests
required for even a minor change! I know we can automate them
but it's still a sign of a design anti-pattern.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos