Thanks for the quick response.
Am 17.11.2015 um 17:33 schrieb D'Arcy J.M. Cain:
>> However, I noticed the port currently creates a lot of backward
>> incompatibility. The main issue that now under Python 2 we get longs
>> instead of ints, and unicode instead of str. That will certainly
>> break a lot of old code that is using PyGreSQL.
>
> Should I have switched everything to bytes? There is no string type
> any more.
Oh, maybe you misunderstood. My problem is not with the behavior under
Python 3. My problem is with the behavior under Python 2. Functions that
used to return str in Python 2 should not suddenly return unicode in
Python 2. Whether they return bytes or unicode=str in Python 3 is a
different question, but unicode=str is the natural choice in Python 3.
Similarly, functions that used to return int in Python 2 should not
suddenly return long. In Python 3 of course they must return long=int.
> I forgot about that one. Can we move those tests into one of the
> others? Alternatively, can we rename is to TEST_PyGreSQL_core.py so
> that it is grouped with the others on a directory listing? In any
> case, I want to make a few changes to that. The other two have a
> mechanism for finding the database for connecting. This one just
> assumes template0 on the local machine.
Yes, but it uses template0/1 only to connect. They are Postgres system
databases, so they are always there. Then it creates a test database
"testpg_tempdb" on its own, works on that and drops it afterwards. This
has the advantage that it can assume the database is in a defined state,
i.e. is empty, and has been created with the proper parameters.
I think I will change that and instead guarantee a defined state with a
few "DROP" and "SET" commands in the setup, like you do in your opendb()
method, so all the tests work the same way and don't need a user with
create database privilege.
Regarding the name, it also tests the high level classic interface, not
only the core. The scope is similar to TEST_PyGreSQL_classic.py, it's
just more extensive. Actually it's too large and should be split into 2
or 3 modules. I'll work on that today and think about good names.
Another issue with that test is that even though it's so large, it does
still not cover everything, particularly I don't see large objects
covered anywhere. Before refactoring we should cover these seldom used
functionality as well.
> I am not sure if we should use Unicode more in 3. However, I think I
> will revert that change for now and possibly add macros later if we
> want to change it in 3.
Again, the problem is not with Unicode in 3, only with Unicode in 2.
>> In r526 you replaced occurrences of PyInt with PyLong. That means
>> things like OIDs are returned as longs instead of ints in Python 2
>> which makes no sense for OIDs, since they are always 32 bit, and it
>> breaks the old behavior.
>
> Is there anywhere, other than the tests, that this would actually
break anything?
You can never be sure what old code does with the OIDs or other return
values, maybe checks with isinstance(..., int).
I like the first one because PyInt_FromLong is deprecated anyway and
at some point we can just drop the macro. I can just imagine twenty
years from now someone scratching their head over why we used
PyInt_FromLong and a macro to rename it to a real function. :-)
Better documentation will certainly help. But yes, I understand your point.
So if you're ok, I'll create a 4.x branch and work on refactoring the
test_pg.py monstrosity there. I will split it in parts, bring it in line
with the other two tests and add the missing test for large objects and
other parts of the classic API that aren't covered yet. Then I will
merge it over back to the trunk where it can be used to make sure the
trunk stays backward compatible.
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo.cgi/pygresql
