Opened 4 years ago

Closed 4 years ago

#21934 closed Bug (fixed)

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

Reported by:… Owned by: nobody
Component: GIS Version: master
Severity: Normal Keywords: unicode, i18n
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


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 !!

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

Change History (5)

comment:1 Changed 4 years ago by Russell Keith-Magee

Resolution: invalid
Status: newclosed

"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.

comment:2 Changed 4 years ago by Aymeric Augustin

Resolution: invalidneedsinfo

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.

comment:3 Changed 4 years ago by Tim Graham

Component: UncategorizedGIS
Has patch: set
Patch needs improvement: set
Resolution: needsinfo
Status: closednew
Summary: Missing import statements (e.g. unicode literals)Missing import statements (e.g. unicode literals) in contrib.gis
Triage Stage: UnreviewedAccepted

I believe this references this PR.

comment:4 Changed 4 years ago by…

Please find this new commit

I destroyed my previous fork to start from scratch.

comment:5 Changed 4 years ago by Claude Paroz <claude@…>

Resolution: fixed
Status: newclosed

In e7e3435b4d0d409aa98a66d2d7961f7541d19f9f:

Fixed #21934 -- Added unicode support in GoogleMap class

Note: See TracTickets for help on using tickets.
Back to Top