I’m doing a lot of 2-D tech art stuff lately: texture packing, apng genration etc.
Our engine is in flux and as capabilities increase, I find the art team needing reprocess large amounts of bitmaps.
To that end I’ve been making little .bat files that process a folder’s images via commandline, giving the non-technical artists a simple ‘double-click this’ tool for updating their animations. But windows batch is a weak spot for me, the syntax is obnoxiously cryptic and I have no good instructions on it. It’s clear that it can do some decent scripty things like looping and if statements and searching for specific filenames/extensions/attributes - but It’s a hard slog and lots of stack overflow posts for me to get there. Also, I like making GUI tools for artists with shiny buttons and user empowering interfaces.
Plus, I would like to learn python.
SO: Is python a good language for making a GUI for processing large batches of stuff via command line tools? does it interface well with the windows file system -reading DIR contents into variables and looping through them? Can it be made system agnostic (some of our team is on a mac?)
Does this sound like a good way to dip my toes in python?
Python is great and easy to learn.
It works great cross platform and it’s very easy to loop through files.
Doing batch commands is how I learnt python too. And as I’ve been told, Python was originally constructed for that purpose? Don’t quote me on that though.
python is great for these things. you have easy access to directory stuff, (via the os module) and there are plenty of gui’s out there that plug in really quickly. Also, it’s cross platform with a few extra lines of code.
check out, “learning python the hard way” it’s a book that’s really good for beginners, if you REALLY want to learn it.
1.) if I write a tool in python for the art team, do the artists need to also install python to use it? (is there away to package the scripts as an executable?)
2.) should I start with Python3 or some other version?
Look at py2exe. It’s one of the few methods of packaging up the Python interpreter with your tool. It usually takes a little tweaking to make it optimal, but nothing too strenuous. Lets you omit modules/packages your tool doesn’t need, etc.
Until recently I would have recommended starting with Python 2.7.x. I think it’s a close call these days, though. I’d say take a look at any third-party extensions you may need to use and make sure there’s Python 3 support before going that direction. If it’s really just standard library stuff you’re using, it’s really up to you.
Like Adam said, py2exe. Though I’d start to invest in some deployment infrastructure, it’ll save you time in the long run, rather than packaging with py2exe.
I’d highly suggest python3, as long as the code doesn’t need to be compatible with python 2.7 (like for Maya/Mobu). Things are going full steam ahead with python3 and you may as well learn what’s next (as well as a cleaner, better language).
I’d second Rob’s comment on pushing for Python in the infrastructure. We made Python installs standard issue here years ago and it’s saved us tons of time.
py2exe is useful in a pinch, but it can be a maintenance headache. Especially once you get more than a couple tools out there using it.
Infrastructure = being part of the source safe app (perforce depot for example) that everyone has to have sunk uptodate by default then set the python paths, system environment to look to that by default. As well as simply register the py files with python under windows so you can double click them to execute them if you are running them ineffect as batches.
Thanks again for the helpful advice. I now have Python 3 runnign and connected to my favorite IDE (Komodo edit.)
I began following one of the Diving into Python links but after failing to run the first program I guessed that it was aimed at python 2.x, so I switched to the link above.
one question: there’s a bazillion .py modules on the web, and I’m guessing there is a logical and expected location in my C:Python32\ directory for them.
It looks like C:\Python32\Lib\ is the best choice, judging by the ammount of .py files already there. Is this correct?
[edit:] it appears this is not correct. placing my .py into C:Python32\Lib doesn’t work, nor C:Python32\Scripts, nor C:Python32\ itself.
I can’t run the script via Komodo>Run…
(C:\Python32\python.EXE: can’t open file ‘humansize.py’: [Errno 2] No such file or directory)
nor can I type “>>> import filname.py” in the interpreter
I seem to have hit a fundamental lack of understanding here. Where does python “look” for .py files?
and if the answer is “where you tell it to look,”
then HOW do I tell Python to look somewhere?
When i am in the interpreter and I type “import filename.py”, where is the interpreter looking?
Sorry if this comes across a little frustrated (I am!.)
It seems I have no trouble grasping a new scripting syntax, but this back-end “these files need to go here for stuff to work” type of thing always seems to elude me…and seems the least clearly documented part…
When you import a “module”, Python will search for it in each folder listed in sys.path. Import the sys module and check that to see the default list. You can add to that list by appending new folders to it just like any other Python list.
The traditional place to plop external modules/packages is in C:\Python32\lib\site-packages. But you can really put them anywhere if you’re willing to alter sys.path accordingly.
There’s other means of manipulating module locations, like environment variables, but the above covers the basics.
an example of what Adam is talking about would look something like this:
import sys
pathToYourDir = 'c:/somewhere/folder/modules'
#see what is in the sys path
print(sys.path)
if not pathToYourDir in sys.path:
sys.path.append(pathToYourDir)
#when you are donesy you can pop it out
sys.path.pop(sys.path.index(pathToYourDir))
thanks again all for your help. Getting closer to having my setup working -at least enough to follow Dive Into Python 3…my last problem seems to be more of a Komodo Edit specific issue, I’ll bother their forums.
