Python 3 support is definitely on the wanted features list. I'd probably prefer to support all supported Python versions directly from the same source instead of merging this as a separate branch.

I'll be honest, the main reason is I know I'd forget to merge across branches from time to time if they were maintained separately ;)

You've proven Py3k support is within reach, and this definitely serves as a good starting point.

Thanks,

James

Sure. Though I guess the question is which to make main and which to convert to? Personally I vote for py3 and 3to2 it for people, or as a package ion pypi premade.

But as that's a different issue, I'll close this, and instead work out some way to automate the 3to2 and reopen perhaps, or open a new one.

Had a little spare time tonight so I threw together a 2to3 based solution, it is available in the python3 branch.

I opted for 2to3 instead of 3to2 because Python 2 is still definitely the common case, plus Python 3 users already have 2to3 and are accustomed to seeing it. 3to2 isn't packaged in either Debian or Gentoo(the two systems I had to hand) and that worried me a little, as they can't be packaging any modules with a build dependency on it.

Update: It isn't merged to master as it has received only five minutes testing, and I'm still not entirely sold that it is the right approach.

Is python-github2 packaged in debian or gentoo? Wondering because if it isn't then the user is already using pip/easy_install which does have 3to2, so I think that'd be a moot point in not working from a python 3 base.

Also if the project has no deps that require python 2, it's a perfect candidate to move to the main line python rather than stick with 2.7.

No, github2 isn't available in the official repository of any mainstream distribution as far as I'm aware.

That said my point wasn't just about whether you can install the package, it is also about how robust it is. I may not have made it clear, but the simple fact there aren't a whole heap of packages with build deps on 3to2 is a concern. As is the statement that only 2.7 is fully supported by 3to2, when currently we support 2.4+. As a point of reference the last two bug reports before yours were from users who were still using 2.6, and common platforms like GAE still use 2.5.

I'll also note that pip and easy_install aren't the only alternatives, I've never deployed using either but I do use github2 ;)

If a 3to2-based solution can pass a tox run it may be usable, have you tried?

I agree with JNRowe. 2to3 is better since the project was started and most python users, use python2.x and python3 users are more familiar in dealing with 2to3 plus it could break alot of people using the api as of now. Just my two cents. good work @goosemo

That there aren't a lot of packages using python 3 being a reason to not use 3 is a chicken before the egg issue. It will only apply as long as everyone applies it to their modules. That being said I don't have an issue keeping a python 3 branch up to date, as I'm going to be using this primarily in a python 3 project.

On the tox run, I'm pretty sure I can get it to pass (python 3.1). The tests need to be fixed, as well as the sphinx build. The tests I don't think are responding how they should for the newest version, as in py3 the responses need to be decoded. How were the two files in tests/data/ made? I was going to see if I needed to default encode them first in the mock to act more how the urllib in 3 does.

Okay, I think we're talking in circles for some reason and I'm not sure why. I'm going to fire some bullet points out, and see if we are in agreement about this.

• Python 2.x support is staying, too many people(myself included) need it.
• Python 3.x support would be useful, but it must not break existing users
• Separate branches for Python 2 and Python 3 practically guarantees that eventually they are going to get out of sync through missed merges.

The 2to3 solution I proposed means supporting 2.4 through 3.2. It works now. The only change I'd make when merging it to master is to apply 2to3 to the tests at runtime and update tox.ini.

It isn't clear whether a 3to2 solution can even support 2.4→2.7, without that it is a no-go. A tox run would need to pass for the py2[4567] environments after 3to2 changes are applied.

These points made and it makes basically no difference whether it is 2to3 or 3to2. I'll still lean toward 2to3 until I see a working 3to2 implementation given that the former works and is standard practice, while the latter is yet to prove it can work.

To your specific points:

That being said I don't have an issue keeping a python 3 branch up to date, as I'm going to be using this primarily in a python 3 project.

The 2to3 solution is either just a setup.py build or pip install away from being used in a Python 3 project. You can do so directly from the repo today. There is no need for a separate branch.

How were the two files in tests/data/ made?

Set a cache using Github(cache="<location>"), the directory will populate with any calls made from that object. All the mock does is replay httplib2 cache compatible items.

The tests need to be fixed, as well as the sphinx build.

After running 2to3 on the tests to fix the Unicode literal usage the tests pass with 3.1 and 3.2 using the python3 branch I pushed.

I don't understand the Sphinx build point. Fixing it to work with a Python 3 only system would require a version of Sphinx compatible with Python 3, and the latest release isn't. Or was there another problem you're referring to?

As there haven't been any alternatives proposed, or problems reported, I'm planning on merging the python3 branch early next week. I'm holding off doing so at the moment to allow a little more time for any problems or alternatives to bubble up.

I've merged the python3 branch, so we're using 2to3 to support Python 3 now.

If a working alternative is proposed later there are no real barriers to switching to it then.

A new release with these changes will be cut before the middle of next week.

Thanks,

James

Python 3 support via 2to3 is in the 0.4.0 release that has just hit PyPI.

I'm pretending early Monday morning is the middle of this week ;)

Thanks,

James