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 <i...@geometrian.com> 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" <i...@furrypants.com > <mailto:i...@furrypants.com>> 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 > > > >