Re: Making the EmailField RFC-compliant: proposals here!

On Tue, Mar 27, 2012 at 7:13 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > There's also a very recent, relatively active thread discussing our > options with auth.User, which has a lot of overlap with this change. The > wiki discusses all the options, and makes specific mention of

Re: Making the EmailField RFC-compliant: proposals here!

On 27/03/2012, at 9:00 PM, Alex Ogier wrote: > > On Mar 27, 2012 8:45 AM, "Hanne Moa" wrote: > > > > Let's just do it. Let's not wait for a generic migration tool! I'd > > rather the energy was spent on the app-refactor *now*, and fixing the > > email-fields *now*, which

Re: Http404 and process_exception

Hi, this mailing list is for the development of django itself. Please direct user question to django-users. Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

Http404 and process_exception

Heretofore, I had always believed that Http404 did not cause Middleware process_exception() to be run. Am I right in this thinking? I have a get_object_or_404 that, when the object in question isn't found, is running process_exception. -- Justin Holmes Instigator, SlashRoot Collective

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On Tue, Mar 27, 2012 at 1:26 PM, gs412 wrote: > Less symbol is the tide, the future. for example: > coffeescript、sass、haml、slim and python, there are all less symbol, this > feature make developer fell well This is incorrect. If Python were all about "fewer symbols", then we

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On Tue, Mar 27, 2012 at 4:26 PM, gs412 wrote: > Less symbol is the tide, the future. for example: > coffeescript、sass、haml、slim and python, there are all less symbol, this > feature make developer fell well > > passing context variables for tag "url" is not a good idea, it make

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On Mar 27, 2012 3:26 PM, "gs412" wrote: > > Less symbol is the tide, the future. for example: coffeescript、sass、haml、slim and python, there are all less symbol, this feature make developer fell well > > passing context variables for tag "url" is not a good idea, it make the work

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On 27 March 2012 14:44, Łukasz Rekucki wrote: > On 27 March 2012 14:22, Shaggy wrote: >> >> and btw. is there repo for developing 1.5 with python3 support? >> > > AFAIK, not yet. There's a features/py3k branch, but I'm not sure if > it's up to date with

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On 27 mars 2012, at 10:22, gs412 wrote: > In Django1.5 > > {% url app_views.client %} > will change to > {% "url app_views.client" %} > > I think it is a stupid idea > Why so many people use django? becouse of 'DRY', but now django become more > and more 'dirty' Hello, django-developers

Re: Making the EmailField RFC-compliant: proposals here!

On Mar 27, 2012 8:45 AM, "Hanne Moa" wrote: > > Let's just do it. Let's not wait for a generic migration tool! I'd > rather the energy was spent on the app-refactor *now*, and fixing the > email-fields *now*, which would remove some of the pressure on fixing > the

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On 27 March 2012 14:22, Shaggy wrote: > from where U have that info? Docs and Django 1.3 release notes: https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi > > and btw. is there repo for developing 1.5 with python3 support? > AFAIK, not yet. There's a

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On Tue, Mar 27, 2012 at 5:22 AM, gs412 wrote: > In Django1.5 > >> {% url app_views.client %} > > will change to >> >> {% "url app_views.client" %} > > > I think it is a stupid idea > Why so many people use django? becouse of 'DRY', but now django become more > and more 'dirty'

Making the EmailField RFC-compliant: proposals here!

As for instance per bug #17870, email-addresses can be as long as 254 bytes. Today, the length of the EmailField is less than that. If django is to be RFC-compliant in this respect, we will need to come up with a way to migrate existing email-fields to the new length. 1. Migration in general No

Re: suggestion: Don't make the tag "url" dirty in Django1.5

That example is incorrect. {% url app_views.client %} will not change to {% "url app_views.client" %} it will change to {% url "app_views.client" %} which, as you can see, enables passing the view from something other than a literal string. On 27 March 2012 09:22, gs412

Re: suggestion: Don't make the tag "url" dirty in Django1.5

On 27 March 2012 10:22, gs412 wrote: > In Django1.5 > >> {% url app_views.client %} > > will change to >> >> {% "url app_views.client" %} > > > I think it is a stupid idea Did you read the rationale for this change? How do you want to enable passing context variables as view

Re: suggestion: Don't make the tag "url" dirty in Django1.5

from where U have that info? and btw. is there repo for developing 1.5 with python3 support? W dniu wtorek, 27 marca 2012, 10:22:18 UTC+2 użytkownik gs412 napisał: > > In Django1.5 > > {% url app_views.client %} > > will change to > >> {% "url app_views.client" %} > > > I think it is a stupid

Deserialization with get_by_natural_key

I'm having trouble loading external data for a model that uses a ContentType foreign key. I'm using a manager in the models, like the docs say. Unfortunately, although the docs talk about the importance of a get_by_natural_key method on a ContentType foreign key, it then launches into a different

suggestion: Don't make the tag "url" dirty in Django1.5

In Django1.5 {% url app_views.client %} will change to > {% "url app_views.client" %} I think it is a stupid idea Why so many people use django? becouse of 'DRY', but now django become more and more 'dirty' -- You received this message because you are subscribed to the Google Groups

Re: Tagging 1.4 django release in Subversion

Hi, On Tuesday, March 27, 2012 7:09:44 AM UTC+2, Łukasz Rekucki wrote: > > For a moment, I thought we could have some more of that magic and > amend the commits in git, so that "author" would be the patch > contributor and commit author would be the "committer". This should be > possible in most