Обсуждение: Proposal: Remove regress-python3-mangle.mk
Hello. Now we generate tests for plpython3 of plpython2 tests. I think we should write independently 2 test suite. Why is that bad: 1. Differences between python2 and python3 more than can be solved by regexps. And these differences are growing. 2. We must be careful to write tests, so as not to break the converter. And we can not verify the possibility python3. 3. Because we use sed we do not tests for plpython3 under Windows. And I have trouble with CMake too. Yes, we will have 2 times more similar code but you need to relates to the python2 and python3 as the different languages. Thank you for attention. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
On Tue, Apr 19, 2016 at 06:31:34PM +0300, Yury Zhuravlev wrote: > Now we generate tests for plpython3 of plpython2 tests. I think we should > write independently 2 test suite. > Why is that bad: > 1. Differences between python2 and python3 more than can be solved by > regexps. And these differences are growing. Considering we have 2756 lines of Python test SQL and just thirteen lines of sed to mangle them, the current method is scaling nicely. > 2. We must be careful to write tests, so as not to break the converter. And > we can not verify the possibility python3. I may not understand that second sentence. We have multiple buildfarm members verifying the python2 case and multiple members verifying the python3 case. > 3. Because we use sed we do not tests for plpython3 under Windows. And I > have trouble with CMake too. Even if removing regress-python3-mangle.mk happened to be good for PL/Python, we need build systems flexible enough to implement steps like it without a struggle. Our current build systems, the src/tools/msvc system and the GNU make system, have that flexibility. We could port regress-python3-mangle.mk to Perl and run it on Windows; it just hasn't been a priority. > Yes, we will have 2 times more similar code but you need to relates to the > python2 and python3 as the different languages. The PL/Python implementation does not view them as different languages; the bulk of its code is the same for both python2 and python3. We'd want almost the same test cases in both suites. Maintaining a single, adaptable test suite is cheaper than forking that suite. nm
Noah Misch wrote: > Considering we have 2756 lines of Python test SQL and just thirteen lines of > sed to mangle them, the current method is scaling nicely. What pitfalls hides this approach? Convert python2 code to python3 it is really bad practice. >I may not understand that second sentence. We have multiple buildfarm members >verifying the python2 case and multiple members verifying the python3 case. I wrote about special python3 features what not testing today. We testing Python3 as subset of Python2. >The PL/Python implementation does not view them as different languages; But it is really different languages. If we do not want to have two different code base, then it is necessary to use than this: https://pythonhosted.org/six/ The license allows us to copy this code into postgres. Or use standart Python tool 2to3: https://docs.python.org/2/library/2to3.html Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Yury Zhuravlev <u.zhuravlev@postgrespro.ru> writes: > Noah Misch wrote: >> I may not understand that second sentence. We have multiple buildfarm members >> verifying the python2 case and multiple members verifying the python3 case. > I wrote about special python3 features what not testing today. We testing > Python3 as subset of Python2. It's not our job to test Python features, especially not version-dependent features. > If we do not want to have two different code base, then it is necessary to > use than this: https://pythonhosted.org/six/ > The license allows us to copy this code into postgres. > Or use standart Python tool 2to3: > https://docs.python.org/2/library/2to3.html You have not explained why we need to change anything. The current approach may be a bit of a kluge, but it works fine for our purposes, AFAICS. Also, I would bet that those tools would not know anything about converting PL language names between 'plpythonu' and 'plpython2u' and 'plpython3u'; so even if we used one of them, we would still need a layer pretty similar to what we have. regards, tom lane
Tom Lane wrote: > Also, I would bet that those tools would not know anything > about converting PL language names between 'plpythonu' and 'plpython2u' > and 'plpython3u'; so even if we used one of them, we would still need a > layer pretty similar to what we have. I do not see this as a problem because we can build Postgres only with one version of Python (2 or 3). Or am I missing something? >may be a bit of a kluge For python developer it is really strange... PS I see Postgres philosophy - do not touch what works well, even if it looks terrible. :) -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Yury Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
> Tom Lane wrote:
>> Also, I would bet that those tools would not know anything
>> about converting PL language names between 'plpythonu' and 'plpython2u'
>> and 'plpython3u'; so even if we used one of them, we would still need a
>> layer pretty similar to what we have.
> I do not see this as a problem because we can build Postgres only with one
> version of Python (2 or 3).
What's your point? The tests still have to load the correct version
of the PL language by name, and create functions that reference that
version by name. Moreover, "make installcheck" should work even
against an installation with both .so's installed.
regards, tom lane
On 4/19/16 10:23 PM, Noah Misch wrote: >> 3. Because we use sed we do not tests for plpython3 under Windows. And I >> > have trouble with CMake too. > Even if removing regress-python3-mangle.mk happened to be good for PL/Python, > we need build systems flexible enough to implement steps like it without a > struggle. Our current build systems, the src/tools/msvc system and the GNU > make system, have that flexibility. We could port regress-python3-mangle.mk > to Perl and run it on Windows; it just hasn't been a priority. Well, you could write the mangling script in Python, but that's harder than it sounds. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services