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

From Corey Huinker
Subject Re: Resolving the python 2 -> python 3 mess
Date
Msg-id CADkLM=e94yBB-mET+RjZ9+r=SxFweMxHO-xMWanfsgKcTJnL_Q@mail.gmail.com
Whole thread Raw
In response to Resolving the python 2 -> python 3 mess  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Resolving the python 2 -> python 3 mess
List pgsql-hackers
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.  One would hope that the Python crowd
weren't dumb enough to do that, but I don't know whether it's true.
If there are nasty cases like that, maybe what we have to do is allow
plpythonu/plpython2u functions to be dumped and reloaded into a
python-3-only install, but refuse to execute them until they've
been converted.

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.
 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Resolving the python 2 -> python 3 mess
Next
From: Hubert Zhang
Date:
Subject: Re: Print physical file path when checksum check fails