I think this ticket http://code.djangoproject.com/ticket/12386
identifies a change in the m2m code which breaks backwards
compatibility.
Consider the following three apps and models:
AppA/models.py:
class ModelA(models.Model):
name = models.CharField(max_length=1024, default='', blank=True)
Having survived the update of pywin32 to python 3, let me say that
both comments are correct:
1) you do NOT create a fork, you convert the existing code so that it
will run through 2to3
2) it takes a LOT of hand refactoring of older 2.x code to get ready
for 2to3.
and, may I add:
3) it's worth the
On Sun, Jan 10, 2010 at 4:45 AM, Ivan Sagalaev
wrote:
> Hello everyone!
>
> There was a discussion here some time ago about logging in Django that led
> to the ticket 12012 [1] where Simon has done most (all?) of the
> implementation.
>
> There is still a disagreement on the format of the configur
On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa wrote:
> 2010/1/13 Tobias McNulty :
> > I am by no means an expert on the matter, but I remember seeing a comment
> > awhile back suggesting that it generally makes more sense to fix the 2to3
> > script than to maintain two branches of the same library.
On Wed, Jan 13, 2010 at 5:21 PM, Hanne Moa wrote:
> 2010/1/13 Tobias McNulty :
>> I am by no means an expert on the matter, but I remember seeing a comment
>> awhile back suggesting that it generally makes more sense to fix the 2to3
>> script than to maintain two branches of the same library. Migh
2010/1/13 Tobias McNulty :
> I am by no means an expert on the matter, but I remember seeing a comment
> awhile back suggesting that it generally makes more sense to fix the 2to3
> script than to maintain two branches of the same library. Might that be the
> case here as well?
Py3K does not suppor
