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 676746 - Can't call GdkWindow.raise() due to reserved word
Can't call GdkWindow.raise() due to reserved word
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
Git master
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-05-24 14:59 UTC by Simon Schampijer
Modified: 2012-06-25 07:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Override GdkWindow.raise() to GdkWindow.raise_() due to reserved word in Python (926 bytes, patch)
2012-05-24 15:05 UTC, Simon Schampijer
rejected Details | Review
initial patch attempt (1.42 KB, patch)
2012-05-26 15:40 UTC, Jose Rostagno
none Details | Review
Escape identifiers which are Python keywords (3.20 KB, patch)
2012-06-01 13:08 UTC, Martin Pitt
committed Details | Review

Description Simon Schampijer 2012-05-24 14:59:34 UTC
'raise' is reserved in Python, meaning that you can't call GdkWindow.raise:

>>> w = Gtk.Window()
>>> w.realize()
>>> w.get_window().raise()
  • File "<stdin>", line 1
    w.get_window().raise()
SyntaxError: invalid syntax


Workaround:

>>> getattr(w.get_window(), 'raise')()


PyGTK worked around this by calling the method raise_()

More info: https://mail.gnome.org/archives/python-hackers-list/2011-December/msg00011.html
Comment 1 Simon Schampijer 2012-05-24 15:05:15 UTC
Created attachment 214872 [details] [review]
Override GdkWindow.raise() to GdkWindow.raise_() due to reserved word in Python
Comment 2 Daniel Drake 2012-05-24 15:24:16 UTC
The patch looks OK to me but it might be better to make pygi detect this case and create the attr with the _ automatically, for this and other reserved keywords.
Comment 3 Simon Schampijer 2012-05-24 15:43:12 UTC
Yes, Tomeu was suggesting the same and pointed to a possible place to do that: http://git.gnome.org/browse/pygobject/tree/gi/types.py#n87
Comment 4 Jose Rostagno 2012-05-26 15:40:06 UTC
Created attachment 215051 [details] [review]
initial patch attempt

This is an initial attempt to implement this.

I don't know if def _setup_fields(cls): and def _setup_constants(cls): also need this.

Test are missing, maybe someone can help me with them.
Comment 5 Martin Pitt 2012-06-01 11:47:33 UTC
Comment on attachment 214872 [details] [review]
Override GdkWindow.raise() to GdkWindow.raise_() due to reserved word in Python

I think we should rather go with the generic solution.

Thanks!
Comment 6 Martin Pitt 2012-06-01 12:03:10 UTC
For a test case, I'd rather resort to using identifiers in GLib and GObject. GObject does not have any which are Python keywords, but GLib actually has a few:

Variant.print()
Timer.continue()
BookmarkFile.add_application() has an "exec" argument
Thread.yield()

My search also brought up IOCondition.in, but as these are presented as upper-case in Python it doesn't count.

(In reply to comment #4)
> I don't know if def _setup_fields(cls): and def _setup_constants(cls): also
> need this.

Most likely not constants as they are in upper case (see above), but probably for field names; we'll need to add a field name to gobject-introspection's GIMarshallingTests for this.
Comment 7 Martin Pitt 2012-06-01 12:18:27 UTC
Unfortunately all these existing examples in GLib are not GObjects, but structs and fundamentals, so the patch in MetaClassHelper is not sufficient. E. g. it does not help for

        v = GLib.Variant('i', 1)
        v.print_(False)

How about we tie this into _wrap_g_base_info_get_name()? This is as close to GI as we can get, and the first step into the Python realm, where we actually can check for Python keywords.
Comment 8 Martin Pitt 2012-06-01 13:08:33 UTC
Created attachment 215408 [details] [review]
Escape identifiers which are Python keywords

How about this patch? Peer review appreciated; in particular, I'm looking for opinions about hardcoding the keyword list for every major release or whether it's better to do the (more correct, but much more expensive) keyword.iskeyword() call to the Python module.
Comment 9 Martin Pitt 2012-06-01 13:54:23 UTC
Summary of discussion with Dieter:

 - We could consider generating the keyword list at build time (into a .h file which we #include), and then just add the special cases.

 - We only want this list to grow monotonously with newer major versions, to avoid breaking existing API (e. g. if they ever drop the "print" keyword, we still want existing my_variant.print_() calls to continue to work.

 - This patch will #error out when we build against a Python 4 or later, and shows the command how to generate the keyword list (at least for Python 2 and 3), so it's not a hidden trap.

 - This is not the most elegant approach, but very robust.
Comment 10 Paolo Borelli 2012-06-25 07:30:33 UTC
Review of attachment 215408 [details] [review]:

the patch looks good to me and I agree that this approach is robust
Comment 11 Martin Pitt 2012-06-25 07:45:52 UTC
Comment on attachment 215408 [details] [review]
Escape identifiers which are Python keywords

Thanks for the review. Pushed with a proper changelog and some minor tweaks in the new comment.