Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk
Yury Zhuravlev 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk
Yury Zhuravlev 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
