Jesse Zhang <sbjesse@gmail.com> writes:
> I really like the "stub .so" idea, but feel pretty uncomfortable for the
> "transparent" upgrade. Response inlined.
Fair enough, but ...
>> 2. On platforms where Python 2.x is no longer supported, transparently
>> map plpythonu and plpython2u to plpython3u. "Transparent" meaning that
>> dump/reload or pg_upgrade of existing plpythonu/plpython2u functions
>> will work, but when you run them, what you actually get is Python 3.x.
> It's fair enough that plpythonu changes its meaning, people who really
> want the stability should explicitly use plpython2u.
Yeah, but then what do you want to do with functions declared plpython2u?
Have them fail even if they'd work fine under Python 3? Doesn't really
seem like that's helping anyone.
>> 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.
> "True division", one of the very first (2011, awww) few breaking changes
> introduced in Python 3 [1], comes to mind. While it's not the worst
> incompatibilities between Python 2 and 3, it's bad enough to give pause
> to the notion that a successful parsing implies successful conversion.
Hm. I agree that's kind of nasty, because 2to3 doesn't fix it AFAICT
(and, likely, there is no way to do so that doesn't include solving
the halting problem). However, it's not clear to me why forcing users
to do a conversion is going to help them any with that, precisely
because the automated conversion won't fix it. They're going to have
to find such issues the hard way whenever they move to Python 3, no
matter what we do.
regards, tom lane