[Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

[boB Stepp]

On Sun, Jan 7, 2018 at 8:32 AM, Alan Gauld via Tutor <tutor at python.org> wrote:
> On 07/01/18 09:07, boB Stepp wrote:
>> clarify this?  What is the methodology that os.path.realpath(path) is
>> actually following to yield a particular path name?  And why does it
>> not care if path refers to a real file or not?
>
> The os.path module is mostly a string manipulation toolkit.

This is the critical piece that was eluding me.  I assumed that the
actual file system was being queried, checked and expanded as needed.

> It checks that a string looks like a path and it de/constructs
> paths from strings. But it does not pay muchy(any?) attention
> to the filesystem. It doesn't care if the paths it deals
> with are real paths or not, its purely manipulating the
> strings according to the syntax rules for paths.

I was assuming it was computing the actual path to the file given as
its argument.  Steve's comments make much more sense now as well as
the "canonical" aspect.

>> class TestOpenFileStrIntsToList(unittest.TestCase):
>>     """Tests for the function open_file_str_ints_to_list."""
>>
>>     def test_open_file_str_ints_to_list(self):
>>         """Ensure expected list of string integers is returned."""
>>
>>         path = os.path.dirname(
>>                 os.path.realpath(__file__)) + '/test_data.dat'
>>         print('realpath =', os.path.realpath(__file__))
>
> Yes, thats it although you could test using isfile() or
> better still use a try/except around the open.
>
> Also you should strictly use os.path.join() to create the path

Duly noted on os.path.join().  I have not gotten to thinking about the
UI yet, and don't mind if a file not found error is generated here in
the testing code as it will let me know I've screwed something up.
This is strictly a play project to record my manual games of
solitaire.  I doubt it will be useful to anyone else.  Once I get to
coding the UI I might wrap this in a try/except if I feel I would gain
any benefit from handling the exception.

>> BTW, I am having trouble coming up with a good name for a string that
>> looks like an integer that I plan on using int() later to convert the
>> string to an integer.  "String integer" is my best thought at this
>> time.
>
> What's it for? Where did it come from?
> type based names are rarely good, better to describe why/where.
>
> input_Id, read_Id, stored_Id etc....
>
> Or substitute Ref, or Count or whatever for Id.
>
> Then the real int var name becomes the second part:
>
> Id = int(input_Id)
>
> or
>
> count = int(stored_count)

The above has just now led me to a Homer Simpson "Doh!" moment.  When
I open the file and covert it to a list of "string" integers I
currently have:

with open(path) as infile:
       string_integers = [line.strip() for line in infile]

and then run the list through another function to get an integer list.

Why on earth didn't I just write:

with open(path) as infile:
       total_scores = [int(line.strip()) for line in infile]

which directly creates what I want directly?  [Please don't answer
this question!  ~(:>)) ]


-- 
boB