Re: model fields options

On May 7, 2:21 am, Alex Gaynor wrote: > Sounds like a bad idea to me.  unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields.  All the other options belond to specific fields. I agree in

Re: Extending templates dynamically

On Fri, May 6, 2011 at 12:25 PM, Christophe Pettus wrote: > Steal from the best! :)  One additional feature that they added was a dynamic > way of doing {{ extends }}.  Rather than specifying the tag in the template > source, the inheritance path can be specified directly in

Extending templates dynamically

Having had to do some PHP programming for the first time in a long time, I discovered that the Smarty template language has taken Django's template inheritance mechanism and adopted it wholesale in version 3: http://www.smarty.net/docs/en/advanced.features.template.inheritance.tpl

Re: model fields options

On Fri, May 6, 2011 at 12:22 PM, legutierr wrote: > Why is help_text part of the field > definition?  This is a ui-specific thing--what does it have to do with > the database?  All abstractions are leaky, sure, but this seems > inappropriate.  The same thing goes for

Re: model fields options

Hi Eduardo, On 05/06/2011 12:22 PM, legutierr wrote: > You're probably right about this, but (while we are on the subject) > aren't there some things that shouldn't be part of the model field > options that currently are? Why is help_text part of the field > definition? This is a ui-specific

Re: model fields options

Not exactly related, but this is how help_text (and other field options) can be moved out from the field definition without patching django: http://djangosnippets.org/snippets/2180/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: model fields options

> Sounds like a bad idea to me. unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields. All the other options belond to specific fields. > > Alex You're probably right about this, but (while we are on the

Re: model fields options

On Fri, May 6, 2011 at 12:08 PM, Mateusz Harasymczuk wrote: > I had an idea. > > To move model fields options, such as: > - blank=BOOL > - null=BOOL > - auto_add=BOOL > - auto_add_now=BOOL > - db_index=BOOL > > and others boolean options to Meta class of this model. > > It

model fields options

I had an idea. To move model fields options, such as: - blank=BOOL - null=BOOL - auto_add=BOOL - auto_add_now=BOOL - db_index=BOOL and others boolean options to Meta class of this model. It would make model fields more readable and human friendly. However I am not convinced, that it would be a

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

I think the alternative for python 2.5 may be not to use urllib2 and set socket timeouts directly, this is supported from python 2.3 (basic implementation: https://bitbucket.org/kmike/vkontakte/src/e89d4cb94902/vkontakte/http.py ). Feels like a hack though. -- You received this message

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

@Fabiant The code linked does not set global default socket timeout and so it shouldn't have concurrency issues; it sets socket timeout for HTTPConnection instance's socket. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

I think the alternative for python 2.5 may be not to use urllib2 and set socket timeouts directly, this is supported from python 2.3 (basic implementation: https://bitbucket.org/kmike/vkontakte/src/e89d4cb94902/vkontakte/http.py ). Feels like a hack though. > @Mikhail That has been discussed

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

On 06.05.2011, at 10:21, Russell Keith-Magee wrote: > On Fri, May 6, 2011 at 3:38 PM, fabian.topfstedt > wrote: >> Hi Eduardo, >> I will definitely write and attach proper tests, but I think there is one >> decision to make first: Are hanging URLFields problem enough

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

On Fri, May 6, 2011 at 3:38 PM, fabian.topfstedt wrote: > Hi Eduardo, > I will definitely write and attach proper tests, but I think there is one > decision to make first: Are hanging URLFields problem enough to make Django > behave differently on Python <=2.5 and

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

Hi Eduardo, I will definitely write and attach proper tests, but I think there is one decision to make first: Are hanging URLFields problem enough to make Django behave differently on Python <=2.5 and >=2.6 (even if the solution only changes the behavior for people that explicitly opt-in for

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

Hi Fabian, Are there tests that isolate this functionality? If there are, I can run them against 2.5 and 2.6 to give you some independent verification. If not, you should look into how to run the Django test suite, and write some targeted tests. Regards Eduardo On May 5, 3:07 am, Fabiant7t

Re: PatchHammer 40,000

On May 6, 8:25 am, Luke Plant wrote: > I do think this could be useful though. If someone submits a patch that > *immediately* doesn't apply to trunk, then it will be useful to know > that, and hooking this in to Trac at the point the patch is uploaded > would be useful.