On Mon, Apr 4, 2022 at 4:46 PM Joel Holdsworth <jholdsworth@xxxxxxxxxx> wrote: > > I'm using pylint 2.12.2 on Python 3. I agree there are still many pylint warnings - especially if we start trying to cut down the disable list. However, quite a few of them are false positives. > [...] > > I used autopep8 to locate the issue I fixed here. It's not nearly as thorough as pylint, but PEP8 itself is very patchy in regard to the issues the authors chose to address. > Thx for the feedback! I will play. > > > I personally have an interest in making sure this script keeps running correctly > > under python2, so I plan to test this when I can. I imagine this is already > > accounted for in the t98xx suite somewhere, but I haven't found it. > > Can you give me a bit more information about this, because I was going to try and push for the git-p4 to discard Python 2 support later this year in a bid to simplify the code, reduce the testing burden, and move toward cleaner pylint output. > Now that you question it, I'm thinking a bit about how I got there: I work with a Perforce repository that has a long and colorful history, with users from many countries on at least three different platforms (windows, linux, osx), and as such both user metadata and changelist descriptions have used inconsistent encodings. When running git-p4 under python2, any author and CL description metadata that is not valid utf8 is simply carried over as-is, and the "invalidly encoded" data just carries into the git repo. (that can later be interesting when working with the resulting git repo in python3, of course - at a minimum decoding errors then need to be swallowed, when minor data loss is acceptable) Under python3, the import fails when some of this stuff gets decoded into unicode strings. Obviously the right thing to do is to figure out exactly what fails under python3, and figure out how to fix it, but I have historically just swept it under the rug and kept using python2 which doesn't bother trying to "interpret" the inconsistently-encoded byte sequences. I'll try to look into this and see whether git-p4 itself can be made to be more forgiving under python3, or whether there is an even better solution where inconsistently-encoded Perforce metadata can somehow be harmonized. Either way, I'll try to contribute some test_expect_failure tests.
