Anecdotally, nearly everything I do is ~2.7. The python community as a whole seems deathly allergic to upgrading to 3. /shrug
Mostly I don't worry about it. You can set the python you want in a virtual env with the -p flag so that it's different for different projects, for instance: $ mkvirtualenv -p /usr/bin/python3.2 envnamefoo So that when you're doing something with the foo project you workon envnamefoo and magically the command 'python' points to the version you specified. Put set up instructions in the readme. IMHO with very few exceptions projects should be in a virtualenv anyway. I do like the little version check to remind you that you're doing it wrong. Should probably say RTFM while you're at it. -n On Tue, Aug 27, 2013 at 11:32 AM, K Wilson <kwilson...@gmail.com> wrote: > > What a headache! It's all starting to feel a bit perl3-4-5-ish. > > I don't think we should try to standardize on either version but > here is a suggestion, since several of us are using python for > PSAS stuff. > > 1) The future is now? Lose this for python3? > # from __future__ import division > > 2) Consider adding this(or similar) check at the top of a source file: > > import sys > if sys.version_info < (3, 0): > sys.stdout.write("Sorry, this application requires Python 3.x, not > Python 2.x\n") > sys.exit(1) > > or if you want to run 2.x change as appropriate. > > Not advocating for any requirements, just something to think about > going forward. > > -K > > > > > > > > > > _______________________________________________ > psas-avionics mailing list > psas-avionics@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics _______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics