Changes between Version 1 and Version 2 of Ticket #23982, comment 4


Ignore:
Timestamp:
Dec 11, 2014, 11:52:28 AM (10 years ago)
Author:
Carl Meyer

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #23982, comment 4

    v1 v2  
    33Migrations are correctly and consistently recording the `verbose_name` as a bytestring when it is a bytestring, and as a text (unicode) string when it is a text string, and noticing the difference when it changes. (Note that migration files always have `from __future__ import unicode_literals`, so an unmarked string is always a unicode string, on Python 2 or 3). That's the only sane behavior for migrations (and it was arrived at with a great deal of trial and error :-) ).
    44
    5 The app, per our [[https://docs.djangoproject.com/en/dev/topics/python3/#unicode-literals porting to Python 3 documentation]], should also be using `from __future__ import unicode_literals` so that the actual nature of the string does not change when moving between Python 2 and 3. (Or if they don't care to support 3.2, they could explicitly mark all strings with `b` or `u` if they prefer that for some reason.)
     5The app, per our [https://docs.djangoproject.com/en/dev/topics/python3/#unicode-literals porting to Python 3 documentation], should also be using `from __future__ import unicode_literals` so that the actual nature of the string does not change when moving between Python 2 and 3. (Or if they don't care to support 3.2, they could explicitly mark all strings with `b` or `u` if they prefer that for some reason.)
    66
    77It would be great if we could provide some kind of hint or warning when creating the migration in this situation, but I don't see how we possibly can. I don't think we can reliably tell, when a migration is generated, whether the string we are seeing was explicitly marked or not, or whether the module containing it had `from __future__ import unicode_literals`. And even if we could tell, we can't warn if not, because there's nothing wrong with unmarked strings and no `__future__` import if the migration is being generated in a project that only supports Python 2 (or only 3).
Back to Top