I have two questions about pygame.image.load. Here's the first:
I use IDLE when I teach classes. But when I am trying to develop something for
myself, I use PyCharm Community Edition. There are many things I like about
PyCharm and one of them is the analysis of errors that is available in the
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
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
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:
pyga
On Nov 25, 2017 16:53, "Irv Kalb" 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.
Irv Kalb wrote:
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.
This is WRONG. Pyt
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
Ian Mallett wrote:
As far as I know, the os.path version does a string conversion to the
platform-preferred way of specifying paths.
No, it doesn't -- that only happens if you use normpath():
>>> os.path.join("abc/def", "ghi")
'abc/def\\ghi'
>>> os.path.normpath('abc/def\\ghi')
'abc\\def\\ghi'
Irv Kalb wrote:
I started working in that environment in the days of Mac
OS9. At that time, the Mac folder separator character was the ":" colon
character.
Yes, in those days it was vitally necessary to use the os.path
functions for cross-platform code.
VMS is another example of a system whi
Ian Mallett wrote:
Hmm I didn't know this, never really viewing Macs as suitable for
development.
Classic MacOS wasn't great for development, but MacOSX is
a flavour of Unix, so you get all the usual developer comforts.
--
Greg
10 matches
Mail list logo