On Sun, Jan 7, 2018 at 8:32 AM, Alan Gauld via Tutor <tutor@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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
