Re: model fields options

[Julien Phalip]

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 principle, however I've recently come across a use case
where being able to *override* an individual field's options (in my
case 'unique') with a simple API from the Model's Meta options would
have been nice: http://code.djangoproject.com/ticket/15953

I don't know enough about the ORM to predict if that sort of things
could have bad side effects. What do you think?

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Extending templates dynamically

[Marty Alchin]

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 the 
> render-equivalent call.  This has proven to be quite useful for those times 
> that an inner template is used in multiple wrapper contexts.  Is this 
> something that might be worth investigating in Django?  Looking at the Django 
> source, the implementation seems quite straight-forward.

Does the current behavior of {% extends %} not do what you want?

http://docs.djangoproject.com/en/1.2/ref/templates/builtins/#extends

In particular, note that you can supply any template variable as the
argument to {% extends %} in order to dynamically inherit from
whatever template your view decides is appropriate. That said, if you
have questions about using {% extends %} in this way, it's probably
best to take it to django-users instead.

-Marty

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Extending templates dynamically

[Christophe Pettus]

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

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 the render-equivalent 
call.  This has proven to be quite useful for those times that an inner 
template is used in multiple wrapper contexts.  Is this something that might be 
worth investigating in Django?  Looking at the Django source, the 
implementation seems quite straight-forward.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Javier Guerra Giraldez]

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 editable, error_messages:
> these options are not part of the ORM, they are parts of the forms
> subsystem that have somehow ended up in the ORM.  Why should the ORM
> know anything about forms, or any other part of Django for that
> matter?

they're UI things, but forms aren't the only UI imaginable.

and, they're UI things that belong to the field.  not the database
field, but the model field.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Carl Meyer]

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 thing--what does it have to do with
> the database?  All abstractions are leaky, sure, but this seems
> inappropriate.  The same thing goes for editable, error_messages:
> these options are not part of the ORM, they are parts of the forms
> subsystem that have somehow ended up in the ORM.  Why should the ORM
> know anything about forms, or any other part of Django for that
> matter?

I think error_messages may actually belong in the ORM now, since
model-validation. Totally agreed that editable and help_text don't
belong there - I think the fact that they're still there is just a
matter of historical inertia, and that nobody's been sufficiently
motivated to deal with the backwards-compatibility difficulties to
change it.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Mikhail Korobov]

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 to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[legutierr]

> 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 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 thing--what does it have to do with
the database?  All abstractions are leaky, sure, but this seems
inappropriate.  The same thing goes for editable, error_messages:
these options are not part of the ORM, they are parts of the forms
subsystem that have somehow ended up in the ORM.  Why should the ORM
know anything about forms, or any other part of Django for that
matter?

Eduardo

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Alex Gaynor]

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 would make model fields more readable and human friendly.
> However I am not convinced, that it would be a good idea, thou.
>
> I am just giving an discussion topic.
>
> it works for unique_together
> why not to add:
>
> unique = ('name', 'login', 'ssn')
> db_index = ('name', 'login')
> auto_add = ('signup_date', )
> auto_add_now = ('last_mod', )
> null = ('comment', 'first_name')
>
> ... and so on ...
>
> What do you think?
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

model fields options

[Mateusz Harasymczuk]

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 good idea, thou.

I am just giving an discussion topic.

it works for unique_together
why not to add:

unique = ('name', 'login', 'ssn')
db_index = ('name', 'login')
auto_add = ('signup_date', )
auto_add_now = ('last_mod', )
null = ('comment', 'first_name')

... and so on ...

What do you think?


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Mikhail Korobov]

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 because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Mikhail Korobov]

@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 this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[fabian.topfstedt]

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 in the ticket's comments and patches setting the 
default socket timeout have not made it so far (because of concurrency issues 
and the potential of breaking unrelated (not necessarily django-) code).

@Russell @Jannis
Thanks for the responses! So I'll keep up with the timeout argument and write 
the tests. If we find a great solution for <=2.5, we can stop raising warnings. 
But the design is clear then :)

Best,
Fabian




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Jannis Leidel]

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 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 that and
>> explicitly the timeout argument of the URLField)?
>> Even if my answer to this particular case is positive, I think there are
>> contrary opinions and I am asking you for yours.
> 
> For my money, this is a situation where Python 2.6+ gives us an
> opportunity to fix the problem in a way that Python <= 2.5 doesn't
> allow. If there isn't a reasonable workaround for Python 2.5, and the
> Python 2.6 solution can't be easily backported into a compatibility
> layer, I'd be comfortable with a solution that works for Python 2.6+,
> and degrades cleanly into "no solution" under Python <= 2.5.

Agreed. I looked at urllib2 yesterday and found it to be a rather intrusive 
feature addition so doubt there is a nice workaround.

> If you want to be really nice about it, you could even raise a warning
> if you try to use a timeout argument under Python 2.5.

+1

Jannis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Russell Keith-Magee]

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 >=2.6 (even if the solution only
> changes the behavior for people that explicitly opt-in for that and
> explicitly the timeout argument of the URLField)?
> Even if my answer to this particular case is positive, I think there are
> contrary opinions and I am asking you for yours.

For my money, this is a situation where Python 2.6+ gives us an
opportunity to fix the problem in a way that Python <= 2.5 doesn't
allow. If there isn't a reasonable workaround for Python 2.5, and the
Python 2.6 solution can't be easily backported into a compatibility
layer, I'd be comfortable with a solution that works for Python 2.6+,
and degrades cleanly into "no solution" under Python <= 2.5.

If you want to be really nice about it, you could even raise a warning
if you try to use a timeout argument under Python 2.5.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[fabian.topfstedt]

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 that and explicitly the 
timeout argument of the URLField)?

Even if my answer to this particular case is positive, I think there are 
contrary opinions and I am asking you for yours.

Best,
Fabian


On Friday, May 6, 2011 at 9:18 AM, legutierr wrote: 
> 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  wrote:
> > Hi everyone,
> > 
> > verifying unresponsive URLs still hangs. There is ticket #9857, raised
> > two
> > years ago, which propagates using a timeout argument on an URLField
> > level.
> > 
> > Unfortunately, urllib2.urlopen (which is used by URLValidator to
> > verify the
> > URL) introduced a timeout support in Python 2.6 and Django requires
> > 2.4+.
> > 
> > For us, having the admin hang if an external ressource is unresponsive
> > is a
> > blocker and I would love to introduce an explicit timeout argument on
> > URLFields that Python 2.6+ respects and Python 2.4-2.5 ignores. I
> > wrote a
> > patch and attached it to the 
> > ticket:http://code.djangoproject.com/ticket/9857
> > 
> > Any thoughts?
> > 
> > Best,
> > Fabian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[legutierr]

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  wrote:
> Hi everyone,
>
> verifying unresponsive URLs still hangs. There is ticket #9857, raised
> two
> years ago, which propagates using a timeout argument on an URLField
> level.
>
> Unfortunately, urllib2.urlopen (which is used by URLValidator to
> verify the
> URL) introduced a timeout support in Python 2.6 and Django requires
> 2.4+.
>
> For us, having the admin hang if an external ressource is unresponsive
> is a
> blocker and I would love to introduce an explicit timeout argument on
> URLFields that Python 2.6+ respects and Python 2.4-2.5 ignores. I
> wrote a
> patch and attached it to the ticket:http://code.djangoproject.com/ticket/9857
>
> Any thoughts?
>
> Best,
> Fabian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: PatchHammer 40,000

[Julien Phalip]

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.

On a related note, it would be great to focus on reviewing the most
recent patches, as those are the ones which are more likely to still
apply to trunk and to reflect a more up-to-date discussion, and
therefore are the ones that are standing a better chance for inclusion
in core.

This is the query to get them:
http://code.djangoproject.com/query?status=assigned=new=reopened_better_patch=0_tests=0_docs=0_patch=1=Accepted=1=changetime

This is the same query as the one in the Reports page ("Patches that
need review" in http://code.djangoproject.com/wiki/Reports) except
ordered by descending "modified" date. If you think it's useful, could
someone with write access edit the Reports page with that query?

Cheers!

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.