[Trac-dev] status of 1.3.3 (python3 development)?

[i***@iprcom.com]

I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been declared
yet, but what is the state of the python3 support progress?

I've read through all the docs starting
at https://trac.edgewall.org/query?status=!closed&keywords=~python3 and
others and two things are not clear:

- which out of https://trac.edgewall.org/ticket/10083
or https://trac.edgewall.org/ticket/12130 (using six) will get the most
love?
- what else is there to do that we/I can help with - or perhaps the above
tickets can be broken up a bit?...

Has anyone started the 1.3.3 work in a private repo -
e.g. https://github.com/jun66j5/trac/tree/python3 - and how is that going?

Many thanks,
Ian

[Tim Graham]

I've been waiting for a green light to resume my work on it. I'm not aware
of any other activity.

Post by i***@iprcom.com
I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been
declared yet, but what is the state of the python3 support progress?
I've read through all the docs starting at
https://trac.edgewall.org/query?status=!closed&keywords=~python3 and
- which out of https://trac.edgewall.org/ticket/10083 or
https://trac.edgewall.org/ticket/12130 (using six) will get the most love?
- what else is there to do that we/I can help with - or perhaps the above
tickets can be broken up a bit?...
Has anyone started the 1.3.3 work in a private repo - e.g.
https://github.com/jun66j5/trac/tree/python3 - and how is that going?
Many thanks,
Ian

[Christian Boos]

Hello,

Post by i***@iprcom.com
I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been
declared yet, but what is the state of the python3 support progress?

On this topic...

I've just seen the following from Python-announce, it's probably not the

Post by i***@iprcom.com
Python 3.4 is now in "security fixes only" mode. This is the final

stage of support for Python 3.4. Python 3.4 now only receives security
fixes, not bug fixes, and Python 3.4 releases are source code only--no
more official binary installers will be produced.

It's great that we can now focus on using only Python 2.7 for trunk, and
though I'd love to be able to continue to have only that version in
mind, I see that the interest for supporting Python 3.x is there, so I
won't stand in the way, and maybe even help out a bit...

But I don't want to have to take into account more quirks than necessary
by supporting already deprecated 3.x versions. So can we please forget
about 3.4 support, at the very least?

Supporting 3.5 and 3.6 will "only" triple the maintenance cost for
running tests and the risks of hitting bugs and quirks specific to this
or that Python version (we already were there). Personally I'll focus on
3.5, I think.

So here's my strong vote for supporting only Python 3.5 and 3.6 for Trac
1.3.2, let's forget about the earlier 3.x versions.

-- Christian

P.S: and Ian, it's Jinja2, not jinga2 (nor ginsha ;-) )

[RjOllos]

Post by Christian Boos
Hello,

Post by i***@iprcom.com
I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been
declared yet, but what is the state of the python3 support progress?

On this topic...
I've just seen the following from Python-announce, it's probably not the

Post by i***@iprcom.com
Python 3.4 is now in "security fixes only" mode. This is the final

stage of support for Python 3.4. Python 3.4 now only receives security
fixes, not bug fixes, and Python 3.4 releases are source code only--no
more official binary installers will be produced.
It's great that we can now focus on using only Python 2.7 for trunk, and
though I'd love to be able to continue to have only that version in
mind, I see that the interest for supporting Python 3.x is there, so I
won't stand in the way, and maybe even help out a bit...
But I don't want to have to take into account more quirks than necessary
by supporting already deprecated 3.x versions. So can we please forget
about 3.4 support, at the very least?
Supporting 3.5 and 3.6 will "only" triple the maintenance cost for
running tests and the risks of hitting bugs and quirks specific to this
or that Python version (we already were there). Personally I'll focus on
3.5, I think.
So here's my strong vote for supporting only Python 3.5 and 3.6 for Trac
1.3.2, let's forget about the earlier 3.x versions.
-- Christian
P.S: and Ian, it's Jinja2, not jinga2 (nor ginsha ;-) )

I fully agree with only supporting Python 3.5 and 3.6, along with Python
2.7.

My motivation for moving to Python 3.x is similar to your motivation for
not supporting Python 3.4 and earlier. Python 2.7 is in maintenance mode
and won't be supported beyond 2020. Eventually we'll need a plan for moving
off Python 2.7, and having a pathway to 3.x sooner rather than later will
be better for the project.

I've been working on rebasing Jun's python3 branch (#12130) for the past
week. The tests are passing on Python 2 and I have 6 more errors to fix on
Python 3.6. I'll make the branch public soon since I expect there is a lot
more work to do, including code review.

- Ryan

[RjOllos]

Post by RjOllos

Post by Christian Boos
Hello,

Post by i***@iprcom.com
I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been
declared yet, but what is the state of the python3 support progress?

On this topic...
I've just seen the following from Python-announce, it's probably not the

Post by i***@iprcom.com
Python 3.4 is now in "security fixes only" mode. This is the final

stage of support for Python 3.4. Python 3.4 now only receives security
fixes, not bug fixes, and Python 3.4 releases are source code only--no
more official binary installers will be produced.
It's great that we can now focus on using only Python 2.7 for trunk, and
though I'd love to be able to continue to have only that version in
mind, I see that the interest for supporting Python 3.x is there, so I
won't stand in the way, and maybe even help out a bit...
But I don't want to have to take into account more quirks than necessary
by supporting already deprecated 3.x versions. So can we please forget
about 3.4 support, at the very least?
Supporting 3.5 and 3.6 will "only" triple the maintenance cost for
running tests and the risks of hitting bugs and quirks specific to this
or that Python version (we already were there). Personally I'll focus on
3.5, I think.
So here's my strong vote for supporting only Python 3.5 and 3.6 for Trac
1.3.2, let's forget about the earlier 3.x versions.
-- Christian
P.S: and Ian, it's Jinja2, not jinga2 (nor ginsha ;-) )

I fully agree with only supporting Python 3.5 and 3.6, along with Python
2.7.
My motivation for moving to Python 3.x is similar to your motivation for
not supporting Python 3.4 and earlier. Python 2.7 is in maintenance mode
and won't be supported beyond 2020. Eventually we'll need a plan for moving
off Python 2.7, and having a pathway to 3.x sooner rather than later will
be better for the project.
I've been working on rebasing Jun's python3 branch (#12130) for the past
week. The tests are passing on Python 2 and I have 6 more errors to fix on
Python 3.6. I'll make the branch public soon since I expect there is a lot
more work to do, including code review.
- Ryan

More generally, we've been putting together a table to help guide decisions
in which versions of packages to support. My feeling is that we should aim
to support the dependencies in the latest LTS version of at least Ubuntu,
Debian, and CentOS at the time of a major Trac release. Debian 8 currently
has Python 3.4.2, but it looks like Debian 9 will be available long before
Trac 1.4, and I'm guessing Debian 9 will have at least Python 3.5.

https://trac.edgewall.org/wiki/TracDev/ApiChanges/1.3#CompatibleDistros

- Ryan

[RjOllos]

Post by RjOllos

Post by Christian Boos
Hello,

Post by i***@iprcom.com
I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been
declared yet, but what is the state of the python3 support progress?

On this topic...
I've just seen the following from Python-announce, it's probably not the

Post by i***@iprcom.com
Python 3.4 is now in "security fixes only" mode. This is the final

stage of support for Python 3.4. Python 3.4 now only receives security
fixes, not bug fixes, and Python 3.4 releases are source code only--no
more official binary installers will be produced.
It's great that we can now focus on using only Python 2.7 for trunk, and
though I'd love to be able to continue to have only that version in
mind, I see that the interest for supporting Python 3.x is there, so I
won't stand in the way, and maybe even help out a bit...
But I don't want to have to take into account more quirks than necessary
by supporting already deprecated 3.x versions. So can we please forget
about 3.4 support, at the very least?
Supporting 3.5 and 3.6 will "only" triple the maintenance cost for
running tests and the risks of hitting bugs and quirks specific to this
or that Python version (we already were there). Personally I'll focus on
3.5, I think.
So here's my strong vote for supporting only Python 3.5 and 3.6 for Trac
1.3.2, let's forget about the earlier 3.x versions.
-- Christian
P.S: and Ian, it's Jinja2, not jinga2 (nor ginsha ;-) )

I fully agree with only supporting Python 3.5 and 3.6, along with Python
2.7.
My motivation for moving to Python 3.x is similar to your motivation for
not supporting Python 3.4 and earlier. Python 2.7 is in maintenance mode
and won't be supported beyond 2020. Eventually we'll need a plan for moving
off Python 2.7, and having a pathway to 3.x sooner rather than later will
be better for the project.
I've been working on rebasing Jun's python3 branch (#12130) for the past
week. The tests are passing on Python 2 and I have 6 more errors to fix on
Python 3.6. I'll make the branch public soon since I expect there is a lot
more work to do, including code review.
- Ryan

I think it's worth considering to just do a switch to Python 3.5+ in Trac
1.5.1 rather than supporting 2.7 and 3.5+.
* Python 2.7 is end-of-life in 2020 (PEP:0373)
* Optimistically, Trac 1.6 would be July 2018
* We could continue to support Trac 1.4.x through 2020
* Targeting fewer python versions can increase development velocity on the
trunk
* We can take advantage of the improvements in Python3 without concern for
a six compatibility layer
* Backward compatibility for old python versions will likely continue to be
less important with the adoptions of containers and other isolated
environments

I would like to look to the future, improve my proficiency in the latest
versions of Python focus and focus on adding features. It feels like we've
had an excessive focus on the past (e.g. active development supporting
Python 2.5 continues for Trac 1.0-stable) and I think it hinders the
project. I can think of some counterpoints, I just don't think any of them
are as important as the points I've listed. Django is dropping support for
Python2 in the next major release (1).

Are there any arguments for needing to continue to have the latest stable
release run on Python 2.7 in mid-to-late 2018? It would seem to me that
anyone wanting to stay with the latest Trac can spend the next 12-18 months
on their migration plan for this tiny web app.

- Ryan

(1) https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

[Peter Suter]

Post by RjOllos
I think it's worth considering to just do a switch to Python 3.5+ in
Trac 1.5.1 rather than supporting 2.7 and 3.5+.
* Python 2.7 is end-of-life in 2020 (PEP:0373)
* Optimistically, Trac 1.6 would be July 2018
* We could continue to support Trac 1.4.x through 2020
* Targeting fewer python versions can increase development velocity on
the trunk
* We can take advantage of the improvements in Python3 without concern
for a six compatibility layer
* Backward compatibility for old python versions will likely continue
to be less important with the adoptions of containers and other
isolated environments
I would like to look to the future, improve my proficiency in the
latest versions of Python focus and focus on adding features. It feels
like we've had an excessive focus on the past (e.g. active development
supporting Python 2.5 continues for Trac 1.0-stable) and I think it
hinders the project. I can think of some counterpoints, I just don't
think any of them are as important as the points I've listed. Django
is dropping support for Python2 in the next major release (1).
Are there any arguments for needing to continue to have the latest
stable release run on Python 2.7 in mid-to-late 2018? It would seem to
me that anyone wanting to stay with the latest Trac can spend the next
12-18 months on their migration plan for this tiny web app.
- Ryan

Sounds reasonable to me, personally. My impression has also been that
the project suffers from this "focus on the past". (I would include
"still using SVN" and "contribution model by patches" here.)


[OT: I wonder if it would be possible to create a GitHub bot that posts
all GitHub issues, PR's and comments to Trac tickets, and a Trac plugin
that posts Trac replies back to GitHub.]


One big concern for me is Mercurial support. The current MercurialPlugin
means Trac and Mercurial must run on the same Python version. And
Mercurial has long been very opposed to Python 3 support. This now seems
to have changed somewhat, but I think it's still unclear when it will be
supported.
https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support
https://www.mercurial-scm.org/wiki/Python3

Possibly switching to the server-command protocol would help there, as
Mercurial could then run on its own separate Python version.
https://trac.edgewall.org/ticket/10411

- Peter

[RjOllos]

Post by Peter Suter

Post by RjOllos
I think it's worth considering to just do a switch to Python 3.5+ in
Trac 1.5.1 rather than supporting 2.7 and 3.5+.
* Python 2.7 is end-of-life in 2020 (PEP:0373)
* Optimistically, Trac 1.6 would be July 2018
* We could continue to support Trac 1.4.x through 2020
* Targeting fewer python versions can increase development velocity on
the trunk
* We can take advantage of the improvements in Python3 without concern
for a six compatibility layer
* Backward compatibility for old python versions will likely continue
to be less important with the adoptions of containers and other
isolated environments
I would like to look to the future, improve my proficiency in the
latest versions of Python focus and focus on adding features. It feels
like we've had an excessive focus on the past (e.g. active development
supporting Python 2.5 continues for Trac 1.0-stable) and I think it
hinders the project. I can think of some counterpoints, I just don't
think any of them are as important as the points I've listed. Django
is dropping support for Python2 in the next major release (1).
Are there any arguments for needing to continue to have the latest
stable release run on Python 2.7 in mid-to-late 2018? It would seem to
me that anyone wanting to stay with the latest Trac can spend the next
12-18 months on their migration plan for this tiny web app.
- Ryan

Sounds reasonable to me, personally. My impression has also been that
the project suffers from this "focus on the past". (I would include
"still using SVN" and "contribution model by patches" here.)

I have on my near-term todo list to writeup steps for contributing when
working from a GitHub fork. It's been discussed in a few tickets over the
past several years.

I have some experience working with SubGit and the SVN-Git mirroring works
pretty well. If we configured SubGit we could commit directly to Git or
SVN. I'd also be fine with setting Subversion read-only and working
primarily from Git. SubGit is useful for that case as well. There's some
discussion about this in Lynx #41.

Post by Peter Suter
[OT: I wonder if it would be possible to create a GitHub bot that posts
all GitHub issues, PR's and comments to Trac tickets, and a Trac plugin
that posts Trac replies back to GitHub.]

The Django project has some tooling that might be useful. So far we get
about 1 PR from GitHub per year.

I'm guessing the ability to accept pull-requests will get us more than
ticket synchronization. I know we can setup SVN-Git mirror with SubGit on
the Edgewall server. I'm unsure whether it would also be possible to mirror
between the Git on Edgewall and Git on GitHub with r/w to both.

However, just the ability to commit directly to a Git repository would be a
big step forward in that we could easily grab pull requests from GitHub and
commit them.

The switch to Git seems like biggest potential gain as it would save some
overhead in committing to SVN from a Git repository.

Post by Peter Suter
One big concern for me is Mercurial support. The current MercurialPlugin
means Trac and Mercurial must run on the same Python version. And
Mercurial has long been very opposed to Python 3 support. This now seems
to have changed somewhat, but I think it's still unclear when it will be
supported.
https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support
https://www.mercurial-scm.org/wiki/Python3
Possibly switching to the server-command protocol would help there, as
Mercurial could then run on its own separate Python version.
https://trac.edgewall.org/ticket/10411

Thanks, that's a significant factor. It's hard to imagine that Mercurial
would continue to only support Python2 past its end-of-life and still hope
to stay relevant. Maybe some more research is warranted here, to see if
there's been additional discussion about the timeline for Python3 support
beyond what's listed on the wiki.

- Ryan

[Peter Suter]

Post by RjOllos

Post by RjOllos
I think it's worth considering to just do a switch to Python

3.5+ in

Post by RjOllos
Trac 1.5.1 rather than supporting 2.7 and 3.5+.
* Python 2.7 is end-of-life in 2020 (PEP:0373)
* Optimistically, Trac 1.6 would be July 2018
* We could continue to support Trac 1.4.x through 2020
* Targeting fewer python versions can increase development

velocity on

Post by RjOllos
the trunk
* We can take advantage of the improvements in Python3 without

concern

Post by RjOllos
for a six compatibility layer
* Backward compatibility for old python versions will likely

continue

Post by RjOllos
to be less important with the adoptions of containers and other
isolated environments
I would like to look to the future, improve my proficiency in the
latest versions of Python focus and focus on adding features. It

feels

Post by RjOllos
like we've had an excessive focus on the past (e.g. active

development

Post by RjOllos
supporting Python 2.5 continues for Trac 1.0-stable) and I think it
hinders the project. I can think of some counterpoints, I just

don't

Post by RjOllos
think any of them are as important as the points I've listed.

Django

Post by RjOllos
is dropping support for Python2 in the next major release (1).
Are there any arguments for needing to continue to have the latest
stable release run on Python 2.7 in mid-to-late 2018? It would

seem to

Post by RjOllos
me that anyone wanting to stay with the latest Trac can spend

the next

Post by RjOllos
12-18 months on their migration plan for this tiny web app.
- Ryan

Sounds reasonable to me, personally. My impression has also been that
the project suffers from this "focus on the past". (I would include
"still using SVN" and "contribution model by patches" here.)
I have on my near-term todo list to writeup steps for contributing
when working from a GitHub fork. It's been discussed in a few tickets
over the past several years.
I have some experience working with SubGit and the SVN-Git mirroring
works pretty well. If we configured SubGit we could commit directly to
Git or SVN. I'd also be fine with setting Subversion read-only and
working primarily from Git. SubGit is useful for that case as well.
There's some discussion about this in Lynx #41.
[OT: I wonder if it would be possible to create a GitHub bot that posts
all GitHub issues, PR's and comments to Trac tickets, and a Trac plugin
that posts Trac replies back to GitHub.]
The Django project has some tooling that might be useful. So far we
get about 1 PR from GitHub per year.
I'm guessing the ability to accept pull-requests will get us more than
ticket synchronization. I know we can setup SVN-Git mirror with SubGit
on the Edgewall server. I'm unsure whether it would also be possible
to mirror between the Git on Edgewall and Git on GitHub with r/w to both.
However, just the ability to commit directly to a Git repository would
be a big step forward in that we could easily grab pull requests from
GitHub and commit them.
The switch to Git seems like biggest potential gain as it would save
some overhead in committing to SVN from a Git repository.

(Potentially Trac<->GitHub ticket synchronization could be a "killer
feature" also for other projects that use GitHub for community exposure,
but need some Trac features for coping with tickets. At least I've seen
such requests a few times in discussions of GitHub Issues. But it's just
an random idea probably not worth the huge effort, I don't have much use
for it myself. Personally, I prefer Mercurial and use hggit to interact
with Git repositories.)

Post by RjOllos
One big concern for me is Mercurial support. The current
MercurialPlugin
means Trac and Mercurial must run on the same Python version. And
Mercurial has long been very opposed to Python 3 support. This now seems
to have changed somewhat, but I think it's still unclear when it will be
supported.
https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support
<https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support>
https://www.mercurial-scm.org/wiki/Python3
<https://www.mercurial-scm.org/wiki/Python3>
Possibly switching to the server-command protocol would help there, as
Mercurial could then run on its own separate Python version.
https://trac.edgewall.org/ticket/10411
<https://trac.edgewall.org/ticket/10411>
Thanks, that's a significant factor. It's hard to imagine that
Mercurial would continue to only support Python2 past its end-of-life
and still hope to stay relevant. Maybe some more research is warranted
here, to see if there's been additional discussion about the timeline
for Python3 support beyond what's listed on the wiki.
- Ryan

I found it's been a topic on their last sprint:
https://www.mercurial-scm.org/wiki/4.2sprint#Python_3
There are some details about it in the notes:
https://www.mercurial-scm.org/wiki/4.2sprint/Notes
And there are recent Py3 patches on the mercurial-devel mailing list:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-June/thread.html

- Peter

[RjOllos]

Post by RjOllos

Post by Peter Suter

Post by RjOllos
I think it's worth considering to just do a switch to Python 3.5+ in
Trac 1.5.1 rather than supporting 2.7 and 3.5+.
* Python 2.7 is end-of-life in 2020 (PEP:0373)
* Optimistically, Trac 1.6 would be July 2018
* We could continue to support Trac 1.4.x through 2020
* Targeting fewer python versions can increase development velocity on
the trunk
* We can take advantage of the improvements in Python3 without concern
for a six compatibility layer
* Backward compatibility for old python versions will likely continue
to be less important with the adoptions of containers and other
isolated environments
I would like to look to the future, improve my proficiency in the
latest versions of Python focus and focus on adding features. It feels
like we've had an excessive focus on the past (e.g. active development
supporting Python 2.5 continues for Trac 1.0-stable) and I think it
hinders the project. I can think of some counterpoints, I just don't
think any of them are as important as the points I've listed. Django
is dropping support for Python2 in the next major release (1).
Are there any arguments for needing to continue to have the latest
stable release run on Python 2.7 in mid-to-late 2018? It would seem to
me that anyone wanting to stay with the latest Trac can spend the next
12-18 months on their migration plan for this tiny web app.
- Ryan

Sounds reasonable to me, personally. My impression has also been that
the project suffers from this "focus on the past". (I would include
"still using SVN" and "contribution model by patches" here.)

I have on my near-term todo list to writeup steps for contributing when
working from a GitHub fork. It's been discussed in a few tickets over the
past several years.
I have some experience working with SubGit and the SVN-Git mirroring works
pretty well. If we configured SubGit we could commit directly to Git or
SVN. I'd also be fine with setting Subversion read-only and working
primarily from Git. SubGit is useful for that case as well. There's some
discussion about this in Lynx #41.

Post by Peter Suter
[OT: I wonder if it would be possible to create a GitHub bot that posts
all GitHub issues, PR's and comments to Trac tickets, and a Trac plugin
that posts Trac replies back to GitHub.]

The Django project has some tooling that might be useful. So far we get
about 1 PR from GitHub per year.
I'm guessing the ability to accept pull-requests will get us more than
ticket synchronization. I know we can setup SVN-Git mirror with SubGit on
the Edgewall server. I'm unsure whether it would also be possible to mirror
between the Git on Edgewall and Git on GitHub with r/w to both.
However, just the ability to commit directly to a Git repository would be
a big step forward in that we could easily grab pull requests from GitHub
and commit them.
The switch to Git seems like biggest potential gain as it would save some
overhead in committing to SVN from a Git repository.
(Potentially Trac<->GitHub ticket synchronization could be a "killer
feature" also for other projects that use GitHub for community exposure,
but need some Trac features for coping with tickets. At least I've seen
such requests a few times in discussions of GitHub Issues. But it's just an
random idea probably not worth the huge effort, I don't have much use for
it myself. Personally, I prefer Mercurial and use hggit to interact with
Git repositories.)

Some work was started on the feature, but nothing recent:
https://github.com/trac-hacks/trac-github/issues/75

- Ryan

[h***@gmail.com]

It strikes me that both moving to Python3 and dropping Genshi in 1.5 makes
a whole lot of sense. No need to try to make all the Genshi things knocking
around work with Python 3 (presuming there's even an official Python3
compatible Genshi release by that time) . Anything with Genshi dependencies
has a hard ceiling of Trac 1.4. Makes things very clear. -JL

Post by RjOllos

Post by RjOllos

Post by Christian Boos
Hello,

Post by i***@iprcom.com
I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been
declared yet, but what is the state of the python3 support progress?

On this topic...
I've just seen the following from Python-announce, it's probably not the

Post by i***@iprcom.com
Python 3.4 is now in "security fixes only" mode. This is the final

stage of support for Python 3.4. Python 3.4 now only receives security
fixes, not bug fixes, and Python 3.4 releases are source code only--no
more official binary installers will be produced.
It's great that we can now focus on using only Python 2.7 for trunk, and
though I'd love to be able to continue to have only that version in
mind, I see that the interest for supporting Python 3.x is there, so I
won't stand in the way, and maybe even help out a bit...
But I don't want to have to take into account more quirks than necessary
by supporting already deprecated 3.x versions. So can we please forget
about 3.4 support, at the very least?
Supporting 3.5 and 3.6 will "only" triple the maintenance cost for
running tests and the risks of hitting bugs and quirks specific to this
or that Python version (we already were there). Personally I'll focus on
3.5, I think.
So here's my strong vote for supporting only Python 3.5 and 3.6 for Trac
1.3.2, let's forget about the earlier 3.x versions.
-- Christian
P.S: and Ian, it's Jinja2, not jinga2 (nor ginsha ;-) )

I fully agree with only supporting Python 3.5 and 3.6, along with Python
2.7.
My motivation for moving to Python 3.x is similar to your motivation for
not supporting Python 3.4 and earlier. Python 2.7 is in maintenance mode
and won't be supported beyond 2020. Eventually we'll need a plan for moving
off Python 2.7, and having a pathway to 3.x sooner rather than later will
be better for the project.
I've been working on rebasing Jun's python3 branch (#12130) for the past
week. The tests are passing on Python 2 and I have 6 more errors to fix on
Python 3.6. I'll make the branch public soon since I expect there is a lot
more work to do, including code review.
- Ryan

I think it's worth considering to just do a switch to Python 3.5+ in Trac
1.5.1 rather than supporting 2.7 and 3.5+.
* Python 2.7 is end-of-life in 2020 (PEP:0373)
* Optimistically, Trac 1.6 would be July 2018
* We could continue to support Trac 1.4.x through 2020
* Targeting fewer python versions can increase development velocity on
the trunk
* We can take advantage of the improvements in Python3 without concern
for a six compatibility layer
* Backward compatibility for old python versions will likely continue to
be less important with the adoptions of containers and other isolated
environments
I would like to look to the future, improve my proficiency in the latest
versions of Python focus and focus on adding features. It feels like we've
had an excessive focus on the past (e.g. active development supporting
Python 2.5 continues for Trac 1.0-stable) and I think it hinders the
project. I can think of some counterpoints, I just don't think any of them
are as important as the points I've listed. Django is dropping support for
Python2 in the next major release (1).
Are there any arguments for needing to continue to have the latest stable
release run on Python 2.7 in mid-to-late 2018? It would seem to me that
anyone wanting to stay with the latest Trac can spend the next 12-18 months
on their migration plan for this tiny web app.
- Ryan
(1) https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

Tim has pushed some patches to move us towards Python3, so I'm raising
this topic again for discussion. I still favor switching to Python3 in a
1.5.x release and supporting Trac 1.4-stable through 2020. The Python
foundation is no longer supporting Python 2.7 on Jan 1st, 2020.
Tim proposed using "six" to keep all the tests passing on a branch while
migrating to Python3. Presumably we would just discard those changesets to
drop Python 2.7 support, if we are to go with a branch supporting Python
3.5+.
It seems like there are options other than the six module. I've seen a
https://pypi.org/project/future/
I'm also hoping to do some work on git-svn mirroring this summer so that
we have the option of committing directly to Git, and perhaps directly to a
Git repository on GitHub. One or both of those changes make it easier to
push staged changes.
- Ryan