Missing import statements (e.g. unicode literals) in contrib.gis

[david.fischer.ch@…]

There are a lot of source files that does not start with :

from __future__ import unicode_literals

I am developing a website that uses the GeoDjango framework to display Google-based maps with french markers.
With the current release of the framework my website crashes with a bad stack trace.

I haven't a lot of time to contribute to this project. So I do not want to spend hours only to develop unit-tests that prove my small contribution make it work.

I already tried to contribute to this project, I spent few minutes to fix this issue and then hours to implement the unit-test that anyone can run before / after the modifications to see that this will fix the issue.

Please, follow your own guildelines !!

​https://docs.djangoproject.com/en/dev/ref/unicode/

... And add more accents to the strings in the unit-tests.

[Russell Keith-Magee]

"Use from __future__ import unicode_literals" is a suggested practice. It's a *good* suggested practice, a a helpful suggested practice for maintenance purposes, but It's entirely possible to write working code that doesn't use the unicode literals import. Django has a lot of legacy code that has been tested and works fine (as far as our tests reveal) without these imports existing.

"Just Add unicode_literals" isn't a magic bug fixing strategy - and even if it was, we'd need a test that demonstrates the problem that it solves.

If you're getting a stack trace, then there's either a bug in your code, or there's a bug in Django. Unfortunately, instead of showing us some sample code that causes a problem, or showing us the actual stack trace you've received, you've chosen to complain about absolute adherence to a suggested coding guideline (and I'll note that the link you provide is about using unicode in your own code, not Django's internal coding standards).

Closing as invalid because there's nothing actionable here.

If you want to provide sample code that crashes, or a specific test case where unicode_literals will fix the problem -- feel free to reopen.

[Aymeric Augustin]

I wouldn't call that bug "invalid". It's true that we I dropped the ball mid-way with regard to unicode_literals while porting to Python 3.

I stopped when I reached code that wasn't well tested, mostly in django.contrib.gis, because adding unicode_literals created actual bugs. Adding unicode_literals to every file isn't an option. It would trigger a slew of regressions.

That said, we should continue adding unicode_literals when we have the opportunity, which means, when we add tests.

Re-closing "needsinfo", please provide the stack trace for the problem you encountered and reopen.

[Tim Graham]

I believe this references ​this PR.

[david.fischer.ch@…]

Please find this new commit ​https://github.com/davidfischer-ch/django/commit/4f810ee43d2cfe0af9dc0076fb1b0c5754e9d65f.

I destroyed my previous fork to start from scratch.

[Claude Paroz <claude@…>]

In e7e3435b4d0d409aa98a66d2d7961f7541d19f9f:

Fixed #21934 -- Added unicode support in GoogleMap class