Re: Explicit relative imports

Tom, there's another way to remove confusion/decision making about import ordering: https://pypi.python.org/pypi/isort For Django it could be mentioned on the contrib docs and `isort --check-only` run with flake8. On Thursday, 13 November 2014 14:57:15 UTC+1, Tom Christie wrote: > > Contrary v

DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hi all, At the Django under the hood sprint I picked up #23577 which says, in the general case: 1. For any database object when django creates an associated index 2. If you rename that object 3. Then re-create another with the original's n

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

So one option as you suggest Carl, is to pass a hard coded string into the Operation when it's instantiated in the user's migration file. I've taken a similar approach, starting one level lower, injecting the migration name into database_forwards methods. https://github.com/tomviner/django/comp

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Thanks for pointing out the index improvement DEP Shai, I hadn't seen that yet. It's important to note that right now, index names are not re-creatable in retrospect. They rely on the names of models and fields, that are free to be renamed. So a complete rethink will be needed if introspection

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Thanks for clarifying that Mark. I've updated the ticket mentioning that we'll leave the resolution of the index name collision issue to your DEP. On Monday, 1 December 2014 22:35:49 UTC, Marc Tamlyn wrote: > > I intend the new indexes to have customisable names, and to deconstruct > their name

Re: [ANNOUNCE] Django security releases issued (1.4.21, 1.7.9, and 1.8.3)

Out of interest what's wrong with casting to int and checking for exceptions? This is the removed code: try: int(value) except (ValueError, TypeError): raise ValidationError(_('Enter a valid integer.'), code='invalid') Does this match different strings than the new regex

Better error message for django.core.urlresolvers.reverse

Hi, This is the current error message when a url name or argument doesn't exist: >>> reverse('core:non_existant') NoReverseMatch: Reverse for 'non_existant' with arguments '()' and keyword arguments '{}' not found. Is there support for adding the namespace into the error message? Tom -- You r

Re: Better error message for django.core.urlresolvers.reverse

s might be a usefull addition to the error message. > > I would suggest adding a ticket to django's bugtracker [1] for this. > Ideally write a patch for this issue and attach it to the ticket. > > [1]https://code.djangoproject.com/ > > -- > Servus, > Gregor Müllegger >