Robert Haas <robertmh...@gmail.com> writes:
> I mean, both Perl and Python are Turing-complete. Anything you can do
> in one, you can do in the other, especially when you consider that
> we're not likely to accept too many dependencies on external Perl or
> Python modules. That's why I see this as nothing more or less than
> exercise in letting people use the programming language they prefer.
I think that's an oversimplified analysis. Sure, the languages are
both Turing-complete, but for our purposes here they are both simply
glue languages around some set of testing facilities. Some of those
facilities will be provided by the base languages (plus whatever
extension modules we choose to require) and some by code we write.
The overall experience of writing tests will be determined by the
testing facilities far more than by the language used for glue.
That being the case, I do agree with your point that Python
equivalents to most of PostgreSQL::Test will need to be built up PDQ.
Maybe they can be better than the originals, in features or ease of
use, but "not there at all" is not better.
But what I'd really like to see is some comparison of the
language-provided testing facilities that we're proposing
to depend on. Why is pytest (or whatever) better than Test::More?
I also wonder about integration of python-based testing with what
we already have. A significant part of what you called the meson
work had to do with persuading pg_regress, isolationtester, etc
to output test results in the common format established by TAP.
Am I right in guessing that pytest will have nothing to do with that?
Can we even manage to dump perl and python test scripts into the same
subdirectory and sort things out automatically? I'm definitely going
to be -1 for a python testing feature that cannot integrate with what
we have because it demands its own control and result-collection
infrastructure.
regards, tom lane
