[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



Also note that many parts of Python (since 3.6 I believe) now support Path-like
objects. Taking a quick look at the documentation (as I've not used them
before), it looks like your code would change to:

    from pathlib import Path
    pygame.image.load(Path('images/ball.png'))

If I run the path object through str(), I can see that on my system (which
creates a PosixPath) it outputs 'images/ball.png', while a WindowsPath will
output 'images\\ball.png'.

As long as it works in pygame, then that is probably the easier to understand
approach that still follows good practices and has maximum compatibility (as
long as you're not using older versions of Python).

On Sat, 2017-11-25 at 18:14 -0700, Ian Mallett wrote:
> On Nov 25, 2017 16:53, "Irv Kalb" <Irv@xxxxxxxxxxxxxx> wrote:
> 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.
> 
> Understood and agreed. I generally recommend relative, forward-slashed paths
> in every case, until and if some Windows utility decides to complain, which
> they usually don't anymore. The main holdout is the shell, which Windows
> continues, I assume just to be pissy. Fair enough; the UNIX equivalent, Bash,
> deliberately pretends to uncomprehend "\r".
> 
> I never use hardcoded absolute paths, since a relative path or a user-
> specified path is always (can't think of counterexample, and never ran into
> one) better.
> 
> 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.
> 
> Hmm I didn't know this, never really viewing Macs as suitable for development.
> It's good it has converged to the forward-slash convention though.
> 
> 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.
> 
> You'll see the same behavior in C, so either the standard library does the
> appropriate conversion before the ultimate syscall, or the syscall itself
> understands forward-slashes.
> 
> Thanks,
> 
> Irv
> 
> Ian

Attachment: signature.asc
Description: This is a digitally signed message part