#21934 closed Bug (fixed)

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

Reported by: david.fischer.ch@… 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

Description

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.

Change History (5)

comment:1 Changed 18 months ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

"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 18 months ago by aaugustin

  • Resolution changed from invalid to needsinfo

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 18 months ago by timo

  • Component changed from Uncategorized to GIS
  • Has patch set
  • Patch needs improvement set
  • Resolution needsinfo deleted
  • Status changed from closed to new
  • Summary changed from Missing import statements (e.g. unicode literals) to Missing import statements (e.g. unicode literals) in contrib.gis
  • Triage Stage changed from Unreviewed to Accepted

I believe this references this PR.

comment:4 Changed 18 months ago by 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.

comment:5 Changed 18 months ago by Claude Paroz <claude@…>

  • Resolution set to fixed
  • Status changed from new to closed

In e7e3435b4d0d409aa98a66d2d7961f7541d19f9f:

Fixed #21934 -- Added unicode support in GoogleMap class

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