Re: Resolving the python 2 -> python 3 mess

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Resolving the python 2 -> python 3 mess
Date: 2020-02-18 01:25:41
Message-ID: CADkLM=e94yBB-mET+RjZ9+r=SxFweMxHO-xMWanfsgKcTJnL_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hubert Zhang 2020-02-18 01:27:39 Re: Print physical file path when checksum check fails
Previous Message Tom Lane 2020-02-17 23:57:49 Re: Resolving the python 2 -> python 3 mess