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 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
