#23982: Migrations produced under Python 2 require fixing when run under Python
3
--------------------------------------+------------------------------------
Reporter: spookylukey | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by carljm):
* type: Uncategorized => Cleanup/optimization
* component: Migrations => Documentation
* stage: Unreviewed => Accepted
Comment:
Yes, charettes and bmispelon are right, this is a bug in the app, not a
bug in migrations.
Migrations 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`, 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 :-) ).
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.)
It 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).
I'm converting this to a Documentation issue, because the only thing I can
see that we could do is add a note about the issue to this section of the
docs: https://docs.djangoproject.com/en/dev/topics/migrations/#libraries-
third-party-apps
--
Ticket URL: <https://code.djangoproject.com/ticket/23982#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.9180f68432aa54826cd269f4542e86d0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
