After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 388216 - Short longs, no longs or longer longs ?
Short longs, no longs or longer longs ?
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: gobject
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
: 442652 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-12-21 10:09 UTC by Mark McLoughlin
Modified: 2012-04-21 14:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mark McLoughlin 2006-12-21 10:09:29 UTC
Test case:

---
#!/usr/bin/env python                                                                                                        

import gtk

t = gtk.ListStore (long)

for v in [ 18, 189015844108 ]:
    print type (v), v
    t.set (t.append (), 0, v)
---

Output:

---
<type 'int'> 18
<type 'long'> 189015844108
Traceback (most recent call last):
  • File "./test-gvalue.py", line 9 in ?
    t.set (t.append (), 0, v)
TypeError: value is of the wrong type for this column
---

The issue here is that:

  - The Python long type "represents numbers in an unlimited range"

  - pyg_type_from_object() maps the Python long type to G_TYPE_LONG

  - G_TYPE_LONG is limited to the size of the C long type - e.g. 32 
    bits on i386

  - Although it appears to the user that the list store should be able
    to hold any Python long (and therefore in an unlimited range), it can 
    in fact only hold a limited range of integers

I can see several options:

  1) Punt and put it down to an inconsistency that developers will get
     used to. Document the inconsistency.

  2) Deprecate the mapping of the Python long type to a gtype

  3) Map the Python long to a new gtype which can hold the Python object.
     Do our best to make sure that e.g. the int->text conversion happens 
     for CellRendererText and integer based sorting works correctly
Comment 1 Gustavo Carneiro 2006-12-21 11:33:49 UTC
I'd go for
   2) Deprecate the mapping of the Python long type to a gtype

If a programmer really wants to store a python long, he can do it with:
   t = gtk.ListStore (object)

And if a programmer really wants to store a C long, he can do it with:
   t = gtk.ListStore (gobject.TYPE_LONG)

But:
   t = gtk.ListStore (long)
would keep doing the same thing (map to G_TYPE_LONG) but raise a deprecation warning.

Although I don't think then int->text conversion happens automatically for CellRendererText.  And I don't know whether that problem can be solved.
Comment 2 Johan (not receiving bugmail) Dahlin 2006-12-21 11:39:48 UTC
I'd rather go for 3) since long is a valid python type, we just need to make pygobject support it properly.
Comment 3 Björn Lindqvist 2008-06-28 10:50:49 UTC
*** Bug 442652 has been marked as a duplicate of this bug. ***
Comment 4 Sebastian Pölsterl 2012-04-21 14:11:40 UTC
Thanks for taking the time to report this bug. However, this bug report applies to a PyGObject version that is too old and not supported anymore.
PyGObject developers are no longer working on static bindings, so unfortunately there will not be any bug fixes for the version this report applies to.

By upgrading to a newer version of PyGObject you could receive bug fixes and new functionality. Please feel free to reopen this bug if the problem still occurs with a newer version of PyGObject.