id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 23982,Clarify how to properly support both Python 2 and 3 for third-party apps with migrations,Luke Plant,Carl Meyer,"The basic problem is that Python 2 produces migrations like this: {{{ #!python fields=[ ('name', models.CharField(max_length=255, verbose_name=b'First Name', blank=True)), ], }}} while Python 3 like this: {{{ #!python fields=[ ('name', models.CharField(max_length=255, verbose_name='First Name', blank=True)), ], }}} (i.e. notice the lack of `b` prefix) If you run 'makemigrations' under Python 3, with migrations made in the first way, it creates a new migration to fix the field. I've attached a script that shows the problem. I've tested it against master as well as Django 1.7.1 and the bug is still present. A nice unit test for this might not be possible. There are two things to consider: 1. Fixing the generator so that it doesn't produce this problem 2. Fixing the migration code so that it doesn't consider this a problem. Otherwise, going forward, all migrations created with 1.7 and 1.7.1 will produce confusion when people use Python 3, even if we fix 1. This bug manifests itself most obviously when running makemigrations with 3rd party apps. It looks like we were lucky when it came to the migrations bundled with Django - perhaps they were created by Python 3? ",Cleanup/optimization,closed,Documentation,1.7,Normal,fixed,,,Ready for checkin,1,0,0,0,0,0