Skip to main content

sandbox — wiki

if 5 < 6:
    print ("error")


def adjust_to_correct_appdir():
     import os, sys
         appdir = sys.argv[0] #feel free to use __file__
         if not appdir:
             raise ValueError
         appdir = os.path.abspath(os.path.dirname(sys.argv[0]))
         if not appdir in sys.path:
         #placeholder for feedback, adjust to your app.
         #remember to use only python and python standart libraries
         #not any resource or module into the appdir
         #a window in Tkinter can be adequate for apps without console
         #a simple print with a timeout can be enough for console apps
         print 'Please run from an OS console.'
         import time


Add the code in any *.py thats directly runnable (ex. , ). It must be added near the begining of file, before importing any module living under the appdir, before opening any file with a filename relative to the appdir and before any pickle-unpickle operation.



Your app is started not from the appdir. As a result:

  1. import cannot solve imports relative to the appdir
  2. file operation with filenames relatives to appdir will fail ( like f=file('data/x.png'))
  3. pickle-unpickle can fail by being unable to resolve class definitions
  4. traceback error messages can be ambiguous

This can happen due to:

  1. the app is started from a python interpreter console wich is not in the appdir
  2. the app is started from a OS console wich is not in the appdir
  3. In windows, the app is started by doubleclick in a shortcut (that not have properly set the 'start in' field)
  4. the app is started from a launchbar, and the start directory has not been specified
  5. others?

Way to go:

The second problem can only be solved if at the very beginning of the app the working directory is changed to appdir (os.chdir(appdir)).
Also, if we know the appdir then we can add to the module search paths (sys.path.insert(0,appdir)), solving the problem 1. and, (I think, confirm please) the 3.
Python doenst have functionality to directly query: what is the appdir for app 'myapp'?, but lets seek a portable solution. An old version of this recipe tells:

appdir = os.path.abspath(os.path.dirname(sys.argv[0]))

warning that sys.argv[0] its usualy the command line used to start the app, but not guaranted. By example, if the entry point for the app lies in, and someone start the app from the python interpreter console:

>>>execfile(r'\appedir\') #in linux-mac '/appdir/'

then sys.argv[0] would be the empty string, at least in windows A most recent recipe ,the one that Im replacing, gets appdir as

appdir = os.path.abspath(os.path.dirname(__file__))

wich in the python console case will fail with NameError: __file__ is not defined

Other considerations:

If you cannot resolve appdir, then the better is to give feedback to the user (print, a tkinter window, any that only uses python and standart libraries) and terminate the app.
If you let execution go ahead, expect a lot of bug reports, with ambiguous interpretation.
If you really want to support starting from the python interpreter console, then you can :

... #in branch where sys.argv[0] or __file__ tells nothing try:     appdir=os.getcwd()     f=file(os.path.join(appdir,'signature'),'rb')     f.close()     if sig!='this is the myapp signature file - dont edit':        # started from the interpreter but not in the appdir.        raise     # medium confirmation that the cwd is really the appdir except:     #warn the user and quit

Personally, I woldnt bother.

Parting shots:

Note that the python docs are unclear (or the info if burried somewhere) as the exact circumstances in wich sys.argv[0] nor __file__ will not convey the info we want to extract. Also, from that blurriness, it is unclear if one is better than the other.
For your information, the old recipe (using sys.argv[0]) was used in magicor from a year an a half, no problems.
Sorry if this is too long, but I want to state clearly the problems so as new recipes can cover ar least the same that an older. As a matter of example, the old recipe (not writen by me) handled the two (three?) first problems, a later recipe, the one that I am replacing, forget to adress the item 1 in Problems. So, please, if you want to improve the recipe, like do test if the new code cover more, and make explicit comments about what more it covers. The only adition to the older recipe code is the termination when a reliable appdir can not be built, and it was motivated by some misleading bug reports in pyweek6.
Have a nice prog!!!

Try out that code box: where's my "<"?

if 1 &lt;= x &lt;= 2:
if 1 <= x <= 2:

Including an image

The circle with holes Pygame draw package uses a crude, aliasing, algorithm to draw single pixel width circles. Thicker circles are composed of multiple single pixel width circles. There is not much overlapping of circles so, regrettably, it leaves holes.

Until Pygame incorporates a package like SDL_gfx (in pgreloaded already) with a filled-ellipse draw function programs will just have work around it. One solution, provided by Ian Mallett on the pygame-users, "is to draw a circle on a surface, then use pygame.draw.polygon() to clean off the parts you don't need. You can use colorkey-transparency as well to get 'cut-out' arcs." For arcs Ben Friman observed "that by making tiny adjustments to the arc angles, and re-drawing the arc, most of the holes would get covered up."

Wiki content parser output

Email bug reports and patches to the pygame-users mailing list

To submit a bug report to the mailing list:

  • Join the mailing list.
  • Write an email describing the problem.  Please include how to reproduce the bug.  Including a minimal script so people can see how to reproduce the bug themselves will lead to quicker fixing.  Please include versions of python, pygame, and your OS.
  • Include BUG: at the start of the subject.

To submit a patch to the mailing list:

  • Join the mailing list.
  • Email the mailing list with a description of what the patch fixes, as well as the patch.
  • Include PATCH: at the start of the subject.
  • If you are frequently offering patches, we can discuess giving you developer write access to the SVN repository.

Joining the mailing list to submit your patch or bug report will allow more people to look at your problem.  If you do not want to join the mailing list please send your bug report or patch to renesd AT gmail DOT com.