Python 3 support.

[alice@…]

Howdy!

I'm attempting to add Python 3 compatibility on version 4 of TurboMail (now called marrow.mailer) and ran into the problem that PyMTA is not, itself, Python 3 compatible. This axes the SMTP tests, and my goal is 100% coverage in both Python 2 (done) and Python 3.

[fs]

That'd be an interesting feature for sure but I'm not sure when I'll come to that. The good news is however that the only real dependency (pycerberus) is already ported to Python 3.

[alice@…]

In the mean-time I'll replace use of pymta with a small quantity of smtplib monkey patching:  http://www.psychicorigami.com/2007/09/20/monkey-patching-pythons-smtp-lib-for-unit-testing/

[alex.gronholm@…]

All done :)
 https://bitbucket.org/agronholm/pymta

[fs]

Replying to alex.gronholm@…:

All done :)
 https://bitbucket.org/agronholm/pymta

This repo has no commits - do you plan on porting pymta to Python3 or did you just forgot to actually push your changes?

[alex.gronholm@…]

Oops, forgot to push. Done now.

[alex.gronholm@…]

No comments? Anything?

[fs]

Replying to alex.gronholm@…:

No comments? Anything?

Sorry, I was away for a few days and didn't have time to check out your code. However I'm excited that you actually submitted patches. :-)

Are there any limitations in your current code (e.g. supported python versions, tests, deployment, ...)?

[alex.gronholm@…]

Right now the tests don't seem to run on lower than Python 2.5 but I'm fixing it now. The aim is to support Python 2.3 to 3.2+.

[fs]

Replying to alex.gronholm@…:

Right now the tests don't seem to run on lower than Python 2.5 but I'm fixing it now. The aim is to support Python 2.3 to 3.2+.

Cool. Though I think might be able to ignore 2.3 – support for RHEL 4 will end in February and I don't know any other maintained distro which still ships that version. If you can make it work with 2.3 easily, fine but otherwise RIP 2.3.

[anonymous]

Trouble is, I can't even get Python 2.4 to compile anymore. Strangely I was able to compile 2.3 though, but none of my previous tricks have worked to get 2.4 running.

[alex.gronholm@…]

I'm down to 2 failing tests on Python 2.3.

[alex.gronholm@…]

Heck, all the tests pass even on Python 2.4 (managed to compile it after all). Just not 2.3.

[alex.gronholm@…]

I've pushed the fixes to get it working with py2.4 to bitbucket. If you feel that's good enough, go ahead and pull. Otherwise I'll just try to figure out what's eating 2.3 (hard to debug since nose.tools.set_trace() does not work on py2.3).

[alex.gronholm@…]

Problem solved. The entire test suite now completes successfully on py2.3+.

[alex.gronholm@…]

So, any comments? Are we good to go?

[fs]

Replying to alex.gronholm@…:

So, any comments? Are we good to go?

Honestly I didn't have more than a minute to look in the code. I hope I'll get to it until Thursday. Probably I'll just merge your code when the tests pass on my system as well. I can always refactor it later on.

[fs]

Alex, I merged your changes now. Thank you very much.

There are some small things that I don't like (e.g. no release.py anymore so I have to update the version number multiple times for every release - that is too error-prone for me and also breaks my release scripts). However I don't want to let you wait longer just because I need time to catch up.

[alex.gronholm@…]

Your release.py was largely unnecessary, and you used it the wrong way. Importing it caused all modules to get imported as a side effect, and that caused setup.py to fail due to unfulfilled dependencies. If you feel there is no way around it (as most library authors don't seem to need such a module), you should directly load and execute the file in setup.py and conf.py. Don't import it.