I agree with Heith. I also like the idea and want Allura to move towards python 3, but also read the article and there can be some subtle issues with “global flag day” approach...
I guess we can test how `h.really_unicode` will behave, but there are still can exist hard to predict issues with standard library or something. Perhaps, we can spent a couple of hours to try this approach and see how much will break by running tests and testing by hand. If a lot of things breaks, maybe we need more incremental approach On Fri, Apr 24, 2015 at 12:47 AM, heith seewald <[email protected]> wrote: > I had the same basic question yesterday while working on a unicode related > issue. I read this article: > http://python-future.org/imports.html#unicode-literals -- which broke > down > the pros/cons of using unicode_literals. > > My main concern was the number of modules being called from templates and > ran through the 'h.really_unicode' helper function. But that may not even > be an issue. > > That said, I like the idea in theory. In addition to reducing the number > of unicode related errors now, it would be one of the larger steps towards > becoming python3 compatible (which may be useful in the distant future). > > On Thu, Apr 23, 2015 at 4:27 PM, Dave Brondsema <[email protected]> > wrote: > > > Fairly often we have accidental unicode issues that are a result of our > > code > > using '...' instead of u'...'. And then we come along with a simple fix > > like > > > > > https://forge-allura.apache.org/p/allura/git/ci/db076001f36e41d432f03c08da6fe7af785251fe/ > > > > If we had `from __future__ import unicode_literals` at the top of the > > file, then > > '...' would be unicode by default, instead of str and we wouldn't have > > these > > accidental bugs. I'm interested in maybe putting that in all our > files. I > > wonder if anything would break? > > > > If we wanted to be even more forward-looking, we could do `from > __future__ > > import absolute_import, division, print_function, unicode_literals` > > > > Thoughts? > > > > -- > > Dave Brondsema : [email protected] > > http://www.brondsema.net : personal > > http://www.splike.com : programming > > <>< > > >
