Strategy/ Advice for How to Best Attack this Problem?

[Dave Angel]

On 03/31/2015 07:00 AM, Saran A wrote:

 > @DaveA: This is a homework assignment. .... Is it possible that you 
could provide me with some snippets or guidance on where to place your 
suggestions (for your TO DOs 2,3,4,5)?
 >


> On Monday, March 30, 2015 at 2:36:02 PM UTC-4, Dave Angel wrote:

>>
>> It's missing a number of your requirements.  But it's a start.
>>
>> If it were my file, I'd have a TODO comment at the bottom stating known
>> changes that are needed.  In it, I'd mention:
>>
>> 1) your present code is assuming all filenames come directly from the
>> commandline.  No searching of a directory.
>>
>> 2) your present code does not move any files to success or failure
>> directories
>>

In function validate_files()
Just after the line
                 print('success with %s on %d reco...
you could move the file, using shutil.  Likewise after the failure print.

>> 3) your present code doesn't calculate or write to a text file any
>> statistics.

You successfully print to sys.stderr.  So you could print to some other 
file in the exact same way.

>>
>> 4) your present code runs once through the names, and terminates.  It
>> doesn't "monitor" anything.

Make a new function, perhaps called main(), with a loop that calls 
validate_files(), with a sleep after each pass.  Of course, unless you 
fix TODO#1, that'll keep looking for the same files.  No harm in that if 
that's the spec, since you moved the earlier versions of the files.

But if you want to "monitor" the directory, let the directory name be 
the argument to main, and let main do a dirlist each time through the 
loop, and pass the corresponding list to validate_files.

>>
>> 5) your present code doesn't check for zero-length files
>>

In validate_and_process_data(), instead of checking filesize against 
ftell, check it against zero.

>> I'd also wonder why you bother checking whether the
>> os.path.getsize(file) function returns the same value as the os.SEEK_END
>> and ftell() code does.  Is it that you don't trust the library?  Or that
>> you have to run on Windows, where the line-ending logic can change the
>> apparent file size?
>>
>> I notice you're not specifying a file mode on the open.  So in Python 3,
>> your sizes are going to be specified in unicode characters after
>> decoding.  Is that what the spec says?  It's probably safer to
>> explicitly specify the mode (and the file encoding if you're in text).
>>
>> I see you call strip() before comparing the length.  Could there ever be
>> leading or trailing whitespace that's significant?  Is that the actual
>> specification of line size?
>>
>> --
>> DaveA
>
>

> I ask this because I have been searching fruitlessly through for some time and there are so many permutations that I am bamboozled by which is considered best practice.
>
> Moreover, as to the other comments, those are too specific. The scope of the assignment is very limited, but I am learning what I need to look out or ask questions regarding specs - in the future.
>


-- 
DaveA