I'm finding the `-3` flag to be super useful, but it's quite a huge pain to thread it through all of the places that spawn python subprocesses, sometimes requiring forking of third party code.

This would be much simpler if, like PYTHONWARNINGS, Py_Py3kWarningFlag could be specified as an environment variable.

The idea seems reasonable to me. I would think this would fall under the -3 exemption if others agree this is reasonable to implement.

+1 from me. This would help people to port their projects to Python 3.

@Brett @Berker In a similar vein, it'd be great to expose the `-b` flag in Python 3 in a similar manner to test for invalid byte comparisons.

+1, but I'd name the env var PYTHON3WARNINGS.

Who knows, when Python 4 comes around the corner, we may need a PYTHON4WARNINGS...

Thanks for your support!  Here's a patch to enable the `PYTHON3WARNINGS` environment variable.

Thanks for the patch. I left some comments on Rietveld.

Thanks for the feedback Berker.  I addressed your feedback, but unfortunately I get a 500 from Rietveld when I try to attach a new patchset.  I've uploaded the new patchset here.

Thanks for the new patch.

> I've uploaded the new patchset here.

We don't directly upload patches to Rietveld so you did the right thing :) See https://docs.python.org/devguide/patch.html for details.

Can you also add a note about this new variable to Doc/howto/pyporting.rst?

Thanks for the feedback Berker!  This is my first CPython patch :D.

Added in a note in pyporting.  I actually did a much more detailed write up here https://gist.github.com/rowillia/c0feed97c1863b2d8e5a3ed73712df65, but it seems a bit verbose for this document.

Roy's patch looks good to me in general. Benjamin, as the RM of 2.7, do you have any objections?

PYTHON3WARNINGS looks as Python 3 variant of PYTHONWARNINGS.

Yes, I suppose this falls under the general exemption in 2.x for -3
warning changes.

On Fri, Nov 25, 2016, at 09:13, Berker Peksag wrote:
> 
> Berker Peksag added the comment:
> 
> Roy's patch looks good to me in general. Benjamin, as the RM of 2.7, do
> you have any objections?
> 
> ----------
> nosy: +benjamin.peterson
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28288>
> _______________________________________

> PYTHON3WARNINGS looks as Python 3 variant of PYTHONWARNINGS.

Sadly, I can't think of a better name. Do you have a suggestion?

> Yes, I suppose this falls under the general exemption in 2.x for -3
warning changes.

Thanks, Benjamin!

What about PYTHON_OPT and allowing to pass any options via an environment variable? There is a number of precedences (gzip, less, etc).

    export PYTHON_OPT="-t -b -3"

Or PYTHON3COMP[ATIBILITY]?

> What about PYTHON_OPT and allowing to pass any options via an environment > > variable? There is a number of precedences (gzip, less, etc).
>
>    export PYTHON_OPT="-t -b -3"

I'd be open to this, but it seems like a much wider change than something that I'd have time to build in time for Python 2.7.12.  I agree that this is a better long term direction (similarly, I'd like to enable the `-bb` flag in Python 3).  I'd have to put a bunch of thought into how this would merge with command line flags.

> Or PYTHON3COMP[ATIBILITY]?

I'm open to whichever.  lemburg had suggested `PYTHON3WARNINGS` so that's what I went with.  If that's a blocker for this patch happy to change it.

I agree with Roy: while PYTHON_OPT might be nice long-term, I think that scopes it beyond a py3k change in Python 2.7 and into new feature territory.

As for a better name, PY3KWARNINGS is also possible and minimizes typo issues if that's what people are worried about.

Benjamin just announced 2.7.13rc1 is going to be Dec 3, so this patch needs to land before then if it's going to make it in the next release.

I can commit the patch this week if there are no objections to the name of the variable. I like Brett's PY3KWARNINGS suggestion, but I'm fine with either of the suggested names.

It's too late for the PYTHON3WARNINGS variable in 2.7, but Serhiy's suggestion for PYTHON_OPTS can still be implemented. Updating title and version accordingly.