Re: Resolving the python 2 -> python 3 mess - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Resolving the python 2 -> python 3 mess
Date
Msg-id 572.1582041551@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resolving the python 2 -> python 3 mess  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Resolving the python 2 -> python 3 mess
List pgsql-hackers
Corey Huinker <corey.huinker@gmail.com> writes:
>> A possible gotcha in this approach is if there are any python 2/3
>> incompatibilities that would not manifest as syntax errors or
>> obvious runtime errors, but would allow old code to execute and
>> silently do the wrong thing.

> Unfortunately, I think there are cases like that. The shift to Unicode as
> the default string means that some functions that used to return a `str`
> now return a `bytes` (I know of this in the hashlib and base64 modules, but
> probably also in URL request data and others), and to use a `bytes` in
> string manipulation you have to first explicitly convert it to some string
> encoding. So things like a function that wraps around a python crypto
> library would be the exact places where those was-str-now-bytes functions
> would be used.

So, as with Jesse's example, what I'm wondering is whether or not 2to3
will fix that for you (or even flag it).  The basic difference between
the two alternatives I suggested is whether we force people to put their
python function through that converter before we'll even try to run it.
Subtleties that 2to3 doesn't catch seem like non-reasons to insist on
applying it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Juan José Santamaría Flecha
Date:
Subject: Re: Clean up some old cruft related to Windows
Next
From: Amit Langote
Date:
Subject: Re: plan cache overhead on plpgsql expression