On Tue, 17 Nov 2015 18:43:25 +0100
Christoph Zwerschke <[email protected]> wrote:
>  > 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

Right.  By going to bytes it's the same either way.

> Yes, but it uses template0/1 only to connect. They are Postgres
> system databases, so they are always there. Then it creates a test

They are only there if there is a database running on the local
machine.  The TEST* versions have logic to read a local configuration
file if it exists and use that data including remote host and even
non-standard ports.

> 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.

Cool.

> 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.

Are we testing the reconnect function?  I was considering making the
tests run twice with the second time connecting with an existing DB
object.  Might be overkill though.

> Again, the problem is not with Unicode in 3, only with Unicode in 2.

Understood.  As you say it is a different question.  If I revert then
we can revisit it later.

>  > 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).

Like test_pg does.

> 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.

Would you like me to revert certain things until test_pg runs before
branching?

-- 
D'Arcy J.M. Cain
PyGreSQL Development Group
http://www.PyGreSQL.org IM:[email protected]
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo.cgi/pygresql

Reply via email to