Syntax error: "except gflags_validators.Error, e:" line 1091 of gflags.py

[benoitpointet]

File "/Users/benoitpointet/anaconda3/lib/python3.4/site-packages/python_gflags-2.0-py3.4.egg/gflags.py", line 1091
    except gflags_validators.Error, e:

shouldn't it be the following?

except gflags_validators.Error as e:

[jaradc]

Yep! Same error. Is there anyone paying attention to this? You posted the issue on July 31 and today it's October 12, 2015 so my guess is no. I think python-gflags is only for Python 2.7. I wonder if 2to3 would fix this?

[vrusinov]

I am currently working on pushing a very new version of gflags here (at my free time, so don't expect it to happen very soon) which may or may not fix this problem (and I'm sure will introduce more problems).

So yes - we are paying attention, but it does not make much sense to push a fix to version which is currently here. Please stay tuned.

[jaradc]

No worries. I did get it fixed on my end with a few simple changes between Python 2 and 3. Those changes can be found here if interested but nothing really interesting - changing print statements and error handling syntax.

[Kurt-von-Laven]

@vrusinov, I recently noticed that python-gflags is the only Python package my team uses that doesn't support Python 3, so I am planning to migrate to argparse. I say this in the interest of transparency/providing anecdotal data as opposed to telling Google how it should prioritize support for its generous open-source contributions. (We do, all things being equal, prefer the distributed nature of gflags to the monolithic nature of argparse.) I am curious, given my plan, if there is an approximate ETA for Python 3 support in python-gflags available. I also noticed that Ubuntu maintains a Python 3 version of gflags in case that is of any help.

[gpshead]

Using argparse is what I would recommend for now. We can't commit to a timeline of adding official Python 3 support to python-gflags as it isn't the module we want people to continue using for open source code.

There are some other existing Python 3 ports of gflags out there as you have noticed.

My vision is for an gflags-like API, supporting Python 2.7 and 3.4+, that also synchronizes flags with C++ gflags when any extension modules are linked against C++ code using that. This might even be based on argparse internally if it makes sense to do so.

[Kurt-von-Laven]

Thank you, @gpshead. Will switch over to argparse then. Out of curiosity, what is the module you want people to continue using for open source code?

[gpshead]

We recommend argparse as it is what most people using Python in the world expect.

[Kurt-von-Laven]

Oh, gotcha. Thanks again.

[gpshead]

python-gflags users should migrate to absl-py:
https://github.com/abseil/abseil-py
https://pypi.python.org/pypi/absl-py/

It is the modern version of this library.