Re: [pygame] Building paths & pygame.image.load documentation

[Irv Kalb <Irv@xxxxxxxxxxxxxx>]

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 <ian@xxxxxxxxxxxxxx> 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" <Irv@xxxxxxxxxxxxxx> 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