Created attachment 250827 [details] [review]
patch: Port tools/defs_gen to Python 3.

Without knowing much Python I have ported glibmm's python files so they run
with both python 2 and python 3.
The conversion program 2to3 did most of the job, but it did not find the many
uses of deprecated python 2 string functions. I had to fix them manually.

I have tested with python 2.7.3 and 3.2.3, and with the xxx_generate_docs.sh
and xxx_generate_methods.sh scripts in glibmm/tools/gen_scripts and
gtkmm/tools/gen_scripts. All generated files are identical to what is
generated by python 2 without the attached patch.

If you are good at python, you are welcome to review my patch.
If no one volunteers to review it, or supplies a better patch, it can probably
be pushed.

https://wiki.gnome.org/GnomeGoals/Python3Porting mentions some things to check
after porting. I wonder if these things apply to glibmm.

 - Make sure to change the shebang to: #!/usr/bin/python3

   Not done. It's still #!/usr/bin/env python. Shall it be changed when the
   source code runs with both python 2 and python 3?

 - For modules which have to support both python 2 and 3, add a
   with-python configure option.

   Not done. Does it apply to source code that runs with both python 2 and
   python 3? I suppose glibmm does not have to support python 2.

 - In JHBuild, change the "pygobject-python2" dependency of your module to
   "pygobject".
   
   Not done. Glibmm does not depend on python, at least not directly.
   That's reasonable. You don't need python in order to build glibmm. You only
   need it when you want to regenerate the *docs.xml and the .defs files.

Review of attachment 250827 [details] [review]:

Why adding the __pycache__ folder to git?

Anyway the patch looks good except the maketrans stuff in h2def.

::: tools/defs_gen/h2def.py
@@ +408,3 @@
+            # Python 2
+            trans = string.maketrans(string.ascii_uppercase + '_',
+                                     string.ascii_lowercase + '-')

This code is really weird. 

trans = bytes.maketrans(bytes(string.ascii_uppercase + '_', 'UTF-8'),
                        bytes(string.ascii_lowercase + '-', 'UTF-8'))

This would be better, don't you think ?

On my previous comment there is some lines missing. What I meant is instead of this:

403            try:
404	            # Python 3
405	            trans = str.maketrans(string.ascii_uppercase + '_',
406	                                  string.ascii_lowercase + '-')
407	        except AttributeError:
408	            # Python 2
409	            trans = string.maketrans(string.ascii_uppercase + '_',
410	                                     string.ascii_lowercase + '-')

May be it should be:

trans = bytes.maketrans(bytes(string.ascii_uppercase + '_', 'UTF-8'),
                        bytes(string.ascii_lowercase + '-', 'UTF-8'))

(In reply to comment #2)
> Why adding the __pycache__ folder to git?

I don't suggest adding it to git. My patch adds it to glibmm/.gitignore.
Python 3 creates this directory, and I don't want 'git status' to list it as
an untracked file.

> Anyway the patch looks good except the maketrans stuff in h2def.

I said I'm not good at Python. I did this just because it looks as if no one
else working with glibmm wants to do the job.

With your suggestion, the code does not run with Python 2. That's probably not
necessary, but I thought it would be nice. The maketrans stuff is the only
part of the code where I had problems making the ported code run with Python 2.

Created attachment 250899 [details] [review]
patch: Port tools/defs_gen to Python 3.

This is a patch without maketrans().

I'm uncertain what to do with this bug. Shall I push the patch in comment 5
and close the bug?

As mentioned in comment 1, my patch does not include the "Things to check after
the porting", mentioned at https://wiki.gnome.org/GnomeGoals/Python3Porting,
because I don't think they apply to glibmm.

The instructions at https://wiki.gnome.org/GnomeGoals/Python3Porting says

  If you choose to work on a module, create the bug report on the GNOME
  bugzilla for the relevant module, and make it block bug 684666. This way
  people will know someone already works on it, and won't duplicate the work
  you're doing.

This made me believe that Matthias, the reporter of this bug, worked on it
or had persuaded someone else to work on it.
https://mail.gnome.org/archives/gtkmm-list/2013-July/msg00071.html made me
realize that I was probably wrong.

Sure. Why wouldn't you want to push the patch?

I have pushed the patch in comment 5.
https://git.gnome.org/browse/glibmm/commit/?id=05037ee0d60f1ff62120e737af3dfd369784eb78