Re: [PATCH v4 00/22] git-p4: Various code tidy-ups

[Tao Klerks <tao@klerks.biz>]

On Mon, Apr 4, 2022 at 4:46 PM Joel Holdsworth <jholdsworth@nvidia.com> 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.