Обсуждение: Different responses to description request between Mac and Linux

I am working on extending a library for RobotFramework and added a
keyword for column description retrieval but noticed that when I run it
on Mac OS X 10.6 I am getting:
Column(name='id', type_code=20, display_size=None, internal_size=8,
precision=None, scale=None, null_ok=None)
but when I run the exact same test against the exact same database from
an Ubuntu 10.10 Linux box I am getting:
('id', 20, None, 8, None, None, None)

The only difference that I can find is that the Mac box is running
psycopg2 2.4 installed via (python setup.py install) while the Ubuntu
box is running psycopg2 2.2.1 installed via package management.  Is it
possible that this version difference is what is accounting for the
response difference?

Thanks,
jer

--
Jerry Schneider
QA Manager
iPlant Collaborative
BIO5 Research Institute
University of Arizona
Linux registered user #475536
Ubuntu registered user #28583

On Tue, Mar 22, 2011 at 12:51 AM, Jerry Schneider <jerry57@gmail.com> wrote:
> I am working on extending a library for RobotFramework and added a keyword
> for column description retrieval but noticed that when I run it on Mac OS X
> 10.6 I am getting:
> Column(name='id', type_code=20, display_size=None, internal_size=8,
> precision=None, scale=None, null_ok=None)
> but when I run the exact same test against the exact same database from an
> Ubuntu 10.10 Linux box I am getting:
> ('id', 20, None, 8, None, None, None)
>
> The only difference that I can find is that the Mac box is running psycopg2
> 2.4 installed via (python setup.py install) while the Ubuntu box is running
> psycopg2 2.2.1 installed via package management.  Is it possible that this
> version difference is what is accounting for the response difference?

Yes: from 2.4 cursor.description is provided as namedtuple if
available (http://initd.org/psycopg/docs/cursor.html#cursor.description).

Named tuple are accessible as regular tuple via indexing and hash the
same, see <http://docs.python.org/library/collections.html#collections.namedtuple>
so there should be no backward compatibility problem (but if you have
found any... let's talk about that).

If your concern are doctest (the first thing that comes to mind that
may have been broken by the namedtuple... but that's because doctests
are a broken idea) you can use tuple(x) to transform a namedtuple back
in a regular tuple.

-- Daniele

On 3/21/11 7:24 PM, Daniele Varrazzo wrote:
> On Tue, Mar 22, 2011 at 12:51 AM, Jerry Schneider<jerry57@gmail.com>  wrote:
>> I am working on extending a library for RobotFramework and added a keyword
>> for column description retrieval but noticed that when I run it on Mac OS X
>> 10.6 I am getting:
>> Column(name='id', type_code=20, display_size=None, internal_size=8,
>> precision=None, scale=None, null_ok=None)
>> but when I run the exact same test against the exact same database from an
>> Ubuntu 10.10 Linux box I am getting:
>> ('id', 20, None, 8, None, None, None)
>>
>> The only difference that I can find is that the Mac box is running psycopg2
>> 2.4 installed via (python setup.py install) while the Ubuntu box is running
>> psycopg2 2.2.1 installed via package management.  Is it possible that this
>> version difference is what is accounting for the response difference?
> Yes: from 2.4 cursor.description is provided as namedtuple if
> available (http://initd.org/psycopg/docs/cursor.html#cursor.description).
>
> Named tuple are accessible as regular tuple via indexing and hash the
> same, see<http://docs.python.org/library/collections.html#collections.namedtuple>
> so there should be no backward compatibility problem (but if you have
> found any... let's talk about that).
>
> If your concern are doctest (the first thing that comes to mind that
> may have been broken by the namedtuple... but that's because doctests
> are a broken idea) you can use tuple(x) to transform a namedtuple back
> in a regular tuple.
>
> -- Daniele

Thanks Daniele, that is what I needed to know.  No these aren't being
used for doctests, but rather verification tests that the columns are
setup/defined correctly after a database upgrade.  I will adapt the
keyword I was creating using the connections.namedtuple.

jer

--
Jerry Schneider
QA Manager
iPlant Collaborative
BIO5 Research Institute
University of Arizona
Linux registered user #475536
Ubuntu registered user #28583