py3k: Use print function instead of statement

[QuLogic]

A pretty large PR since it touches every file. You may wish to look at only the first commit, because that one applies only to files in which print is actually used. The second commit is a blanket addition of the __future__ import to the remaining files to ensure everything is consistent.

[thinkle]

I believe if we were to migrate to python 3 nearly all GTK related code would change. Other than migrating to python 3, is there any good reason to switch the syntax around print statements? After a decade of using the old style print statements, I can't say I love the new (I realize it makes more sense to have print work like any other function, but there's a lot of ingrained muscle memory in using print as it)

[QuLogic]

Yes, it's for moving to Python 3. Gourmet is one a dwindling few applications requiring Python 2 on my system, and I'd prefer if it wasn't. Even Gramps went to Python 3 a while ago, which is a bit surprising.

These changes are backwards-compatible though; it's not a complete switch yet.

[thinkle]

Gotcha. Well if you really want to push Gourmet down this path, the gtk
piece is the harder one. Here's a guide:
https://wiki.gnome.org/action/show/Projects/PyGObject/IntrospectionPorting?action=show&redirect=PyGObject%2FIntrospectionPorting

I'm not sure if the new gtk3 bindings are supported on Windows yet so that
could be a showstopper. Also, I don't yet know of any actual upsides to
gtk3/python 3 (ie I haven't heard of something we want in Gourmet that we
can't do with pygtk+python 2) nonetheless I'm sure this is a transition
Gourmet will have to make one day, so if you have the energy for it, I'm
sure we'll appreciate it sooner or later :)

On Sat, Jun 25, 2016, 2:23 PM Elliott Sales de Andrade <
notifications@github.com> wrote:

Yes, it's for moving to Python 3. Gourmet is one a dwindling few
applications requiring Python 2 on my system, and I'd prefer if it wasn't.
Even Gramps went to Python 3 a while ago, which is a bit surprising.

These changes are backwards-compatible though; it's not a complete switch
yet.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#855 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAi8W-daYEJkyP4I_auJxg7LbrPMb91hks5qPXIpgaJpZM4I5GRB
.

[QuLogic]

Gramps switched to both, so it shouldn't be completely impossible.

[QuLogic]

BTW, this PR is complete as-is. I don't want to work on any further changes until these big ones are merged.

[ockham]

I'm not sure if the new gtk3 bindings are supported on Windows yet

There are. FWIW, I've filed an issue for that upgrade a while back that has some more information: #696

Somewhat OT: at some point, I was highly motivated to upgrade Gourmet to a newer tech stack (Gtk 3, Python 3 -- that's #697). Before doing that, I set out to migrate it to an actual ORM (#712) with classes like Recipe and Ingredient, which IMO would've made the codebase a whole lot easier to work with. Alas, as with so many things, it turned out to be quite a lot more work than I had hoped, and I was never able to finish that project. Some of my ORM efforts can be found in the develop branch -- maybe it'll be of use to someone some day.

[micahcochran]

BTW, this PR is complete as-is. I don't want to work on any further changes until these big ones are merged.

@QuLogic
I've got to agree if a project can't accept a relatively small contribution to make it more the code base more Python 3.x compatible (while only taking away from compatibility from some unsupported versions of Python 2.x). Why would/should a volunteer work on a contribution that is much more complicated?

[thinkle]

I can test these changes at some point but correct me of I'm wrong: this is a change that touches a huge chunk of the codebase and doesn't introduce any new functionality. From my perspective, this has a chance of breaking things as downside and nothing as an upside. It's also a process that can be automated so I see no reason to pull the trigger earlier rather than later. I'd rather run it through its paces once there's a demonstrable benefit - that's part of why this has languished. If there were a pull request that provided benefits to users I'd be more motivated to test and merge sooner.

…

On Sun, Apr 9, 2017, 1:13 PM Micah Cochran ***@***.***> wrote: BTW, this PR is complete as-is. I don't want to work on any further changes until these big ones are merged. @QuLogic <https://github.com/QuLogic> I've got to agree if a project can't accept a relatively small contribution to make it more the code base more Python 3.x compatible (while only taking away from compatibility from some unsupported versions of Python 2.x). Why would/should a volunteer work on a contribution that is much more complicated? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#855 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAi8W01syNxOlZ5fxBYrJwe-9Vto8uU1ks5ruRGtgaJpZM4I5GRB> .

[micahcochran]

You are correct about no new features.

However, Python 2.7's end-of-life will be 3 years tomorrow. It will be retired on April 12, 2020.

At some point, Linux distributions will stop packaging Python 2.7 due to the security risks of it not being maintained. When Python 2.7 is removed from Linux distros, gourmet will be removed, too.

Print statements are the easiest place to start porting from Python 2.x to 3.x. I will say that some of the Unicode differences between 2/3 can be a pain to port.

I have no qualms with a PR being thoroughly tested before being merged.

[QuLogic]

Since print statements are a behavioural syntax change in the interpreter, there is basically no way to even try anything in Python 3 without doing it first. Sure, I could open PRs for the other changes first, but I'd have no way to prove that they actually did anything on Python 3 without hanging onto this one as an additional patch, and it's large enough for that to be a futile effort.

The difference between a print statement and a print function call on Python 2 is minimal anyway. If you change a statement to a function and don't include the __future__ import, it prints as a tuple instead of space-separated strings. But 99% of these are debugging things, so nobody will really mind. If you add the __future__ import and forget to convert statements to functions, it's a syntax error, so I couldn't have possibly forgotten it.

If it helps, the entirety of the functional patch was made automatically using futurize. There is very little chance it could go wrong. I've converted several code bases with it and never had a problem with print function calls. The comments were done manually and maybe there's a bug there, but you'd have to uncomment it to find out and you'd probably notice any problems. TBH, I think the commented code should be deleted anyway.

[saxon-s]

Python 2.7 will be end-of-life in less than 2 years time (Apr 12, 2020). These print function changes were submitted more than 2 years ago. Why is there such reluctance to migrate Gourmet to Python 3?

[micahcochran]

@saxon-s
Since then, there has been an idea to do a complete redesign as Gourmet 2. See #897 and #898

[saxon-s]

@micahcochran
I am aware of the Gourmet 2 discussions. The reality is GRM 1 is real and GRM 2 is not. GRM 2 will take time before it sees the light of day. Until then, GRM 1 needs to be maintained. My point is, discouraging submissions is not the way to achieve this. As you pointed out in April of last year ... "if a project can't accept a relatively small contribution to make it more the code base more Python 3.x compatible (while only taking away from compatibility from some unsupported versions of Python 2.x). Why would/should a volunteer work on a contribution that is much more complicated?"

[jraber]

Gourmet was retired from Fedora because it depends on Python 2 which is now officially EOL. Is there anyone working on porting Gourmet to Python 3?

[maweki]

@saxon-s @jraber we're working on a python3 migration over at https://github.com/kirienko/gourmet and it looks quite good.