Thanks Ian.
I'm not worried about the os module being available. I use pygame in classes
that I teach, and it seems like its just one more thing for students to
understand and remember. I teach mostly art students, very few computer
science students. I've used relative path like this:
pygame.image.load('images/ball.png')
for a long time and they had always worked for me. Sounds like you have seen
this too. Unless I hear otherwise, I will use this approach as it is easier
for students to comprehend.
As an aside ... I did development in another language/environment (Adobe
Director/Lingo) for many many years. Whenever we needed to specify a path, we
had to build the full path including the folder delimiter character. I started
working in that environment in the days of Mac OS9. At that time, the Mac
folder separator character was the ":" colon character. I didn't realize it
but the character on a Mac is now the "/", same as the Unix character -
probably changed when OS X came out. I think either one will work on a Mac.
When I started using Python, I thought it was very clever that I can use just
the "/" character in Python, and Python seems to do whatever translation it
needs to do to make the path work on the target system.
Thanks,
Irv
> On Nov 25, 2017, at 3:59 PM, Ian Mallett <[email protected]> wrote:
>
> As far as I know, the os.path version does a string conversion to the
> platform-preferred way of specifying paths. So e.g. on Windows it replaces
> "/" with "\".
>
> This is intended for compatibility with very Windows-focused apps that
> (deliberately?) don't understand "/". However, for the system-level
> application of loading files, "/" is a de-facto standard that all systems
> recognize.
>
> The upshot is that either one will work. I personally use "/" because "\" was
> just not a good idea, and Windows ought to give up already--but it would be
> slightly more correct semantically to use the os.path conversion.
>
> Regarding the extra dependency, os is built into every distro, so I wouldn't
> worry about it.
>
> On Nov 25, 2017 12:01, "Irv Kalb" <[email protected]
> <mailto:[email protected]>> wrote:
> Here's my second question about pygame.image.load. Actually it's a question
> about specifying paths in pygame.
>
> In my classes, I talk about the concept of a path for loading images, sounds,
> etc. I suggest that students create an "images" folder and if needed, a
> "sounds" folder in their project folder. I explain the difference between
> absolute and relative paths, and I point out the reasons why relative paths
> are generally easier to use for loading such assets.
>
> I then explain that with this type of structure, that building a path to each
> asset is a matter of specifying the folder name (and optional subfolder name,
> etc.) and the file name. I talk about how the different operating systems
> use different characters as the folder separator character. But then I point
> out how Python solves this issue by allowing programmers to use the "/"
> character as the folder separator character - and how Python maps that
> character into the appropriate character for the operating system on which
> the program is running. I give an example that I create my demo programs on
> a Mac, then bring them into class and run them on a Windows machine. As long
> as I create paths like:
>
> ball = pygame.image.load('images/ball.png')
>
> This line will work on Macs and Windows (and I assume on Linux/Unix too).
>
> However, when I look at the documentation for pygame.image.load as an
> example, the documentation says:
>
>
> You should use os.path.join() for compatibility.
> eg. asurf = pygame.image.load(os.path.join('data', 'bla.png'))
>
>
> My question is: Is there any reason to do it this way? This requires
> bringing an additional package (the os package), an extra call (to
> os.path.join), and it would require much more of an explanation of what
> os.path.join does.
>
> I have also seen many other books/articles/other people's code where they do
> the same thing by building an absolute path on-the-fly. This all seems like
> a great deal of overkill.
>
> Any reason NOT to use:
>
> ball = pygame.image.load('images/ball.png')
>
> Irv
>
>
>
>
