Re: Changes to django's settings module

[Omer Katz]

So is my example good enough? Have you tried using it?

בתאריך יום שישי, 15 במרץ 2013 13:17:11 UTC+3, מאת Aymeric Augustin:
>
> On 15 mars 2013, at 09:22, Omer Katz > 
> wrote: 
>
> > Doesn't the fact that the patch makes the code clearer is a reason 
> enough for a merge (providing that there will be tests attached to it and 
> documentation)? 
>
>
> Hi Omer, 
>
> This patch isn't only a refactoring; it adds a new feature. Otherwise you 
> wouldn't be talking about documentation. 
>
> Each feature added to Django creates a burden: 
> - for users of Django, who must learn to use it; 
> - for the core team, who must maintain it for the foreseeable future. 
>
> To be accepted, a new feature must: 
> (a) provide benefits that clearly outweigh these costs 
> (b) not get in the way of future improvements — as much as can be 
> foreseen. 
>
> Unfortunately (a) the benefits of your PR still aren't clear and (b) 
> judging by the discussion, your abstraction doesn't match very well the 
> needs of most users, and I suspect it could hinder further efforts to make 
> per-environment settings (the actual problem) easier to define. 
>
> -- 
> Aymeric. 
>
>

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

Is casting Field.help_text to string in Field.__init__ necessary?

[Evgeny]

Hi.

Is it necessary to cast help_text to string in Field.__init__ there 
https://github.com/django/django/blob/master/django/forms/fields.py#L92 ? I 
will be eventually displayed as string in template, and will be casted 
there. I think it would be better design - cast string type only in last 
moment in presentation template.
 
I am asking because i try to display in template two help texts one to the 
right from the field and one to the bottom, and to do that i tried to pass 
in help_text tuple of two strings but failed because of that cast.

Thanks.

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

runserver fails on non-fatal model validation errors

[Brendan Jurd]

Hello folks,

I reported an issue with runserver on the django trac [1], and aaugustin 
asked that I seek feedback here on the list.

In short, the problem I am having is that exceptions thrown during model 
validation will cause runserver to abort.  This might seem like a 
reasonable outcome, but as I discovered, there exist conditions that will 
raise an exception from model validation that are not actually fatal to the 
application.

In my particular example, I am using a custom Manager on my object to 
produce an "extra" field, and then using that field in my "ordering" list.  
Model validation is complaining because this field isn't a declared Model 
field.  This is a good thing for model validation to complain about, and I 
do want that message to be shown when I start up runserver.  But I don't 
want runserver to abort, because I happen to know that the model works 
exactly as intended with that configuration (and I don't know of any better 
alternative for making django ORDER BY an expression).

I'm just a django user, not a developer, so I may be on the wrong track 
here, but I think runserver ought to catch validation exceptions, report 
them to the console, and then continue with its attempt to run the server.  
I included a patch for same in my original trac ticket report.  In the 
worst case, it will end up running a server with models that don't work 
properly ... in which case the user has ignored the model validation errors 
at their own peril.  Since runserver is not even intended for production 
use, I don't see much of a downside.

Thanks for reading, and I look forward to your comments.

Cheers,
BJ

[1] https://code.djangoproject.com/ticket/19126

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

Re: Is casting Field.help_text to string in Field.__init__ necessary?

[Claude Paroz]

Le samedi 23 mars 2013 12:16:15 UTC+1, Evgeny a écrit :
>
> Hi.
>
> Is it necessary to cast help_text to string in Field.__init__ there 
> https://github.com/django/django/blob/master/django/forms/fields.py#L92 ? 
> I will be eventually displayed as string in template, and will be casted 
> there. I think it would be better design - cast string type only in last 
> moment in presentation template.
>  
> I am asking because i try to display in template two help texts one to the 
> right from the field and one to the bottom, and to do that i tried to pass 
> in help_text tuple of two strings but failed because of that cast.
>

It seems to me that it is an "historic" remainder. I suggest you remove the 
offending lines, run the entire test suite, and if you don't get any 
errors, open a ticket suggesting the removal.

Claude

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

Re: Changes to django's settings module

[Russell Keith-Magee]

Hi Omer,

I've looked at your code, and while you continue to call it a
"refactoring", it's a refactoring with a specific purpose in mind -- to add
a new feature.

I disagree that your new code is "clearer" and more "understandable" than
the existing code. For starters, it's got more moving parts (pluggable
Collector and Loader interfaces, for example), and while it's not too hard
to work out how the parts fit together, it isn't intuitively obvious (which
is what would be needed to genuinely have a simplification here).

On top of all that, what you still haven't done is express is *why* this
new feature is required. You clearly want the ability to load settings from
a class in some way. It isn't obvious to met at all why this is beneficial
or helpful.

Lastly, the settings module is one of the warts of Django that most of the
core team would like to fix. In this case, "Fixing" it doesn't mean adding
more complexity and/or flexibility. It means altering altogether the way
settings are handled in Django. There hasn't really been any work in this
area beyond some high level talks at DjangoCon etc [1], but adding
additional complexity to Django's already complex settings system isn't
something we're racing to do without a *really* good reason.

[1] http://www.youtube.com/watch?v=0FD510Oz2e4

Yours,
Russ Magee %-)

On Sat, Mar 23, 2013 at 3:47 PM, Omer Katz  wrote:

> So is my example good enough? Have you tried using it?
>
> בתאריך יום שישי, 15 במרץ 2013 13:17:11 UTC+3, מאת Aymeric Augustin:
>
>> On 15 mars 2013, at 09:22, Omer Katz  wrote:
>>
>> > Doesn't the fact that the patch makes the code clearer is a reason
>> enough for a merge (providing that there will be tests attached to it and
>> documentation)?
>>
>>
>> Hi Omer,
>>
>> This patch isn't only a refactoring; it adds a new feature. Otherwise you
>> wouldn't be talking about documentation.
>>
>> Each feature added to Django creates a burden:
>> - for users of Django, who must learn to use it;
>> - for the core team, who must maintain it for the foreseeable future.
>>
>> To be accepted, a new feature must:
>> (a) provide benefits that clearly outweigh these costs
>> (b) not get in the way of future improvements — as much as can be
>> foreseen.
>>
>> Unfortunately (a) the benefits of your PR still aren't clear and (b)
>> judging by the discussion, your abstraction doesn't match very well the
>> needs of most users, and I suspect it could hinder further efforts to make
>> per-environment settings (the actual problem) easier to define.
>>
>> --
>> Aymeric.
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

where do class modelAdmin and Model reside.

[ANKIT BAGARIA]

the above class AuthorAdmin is inherited from ModelAdmin. Please help in 
finding where does the class ModelAdmin reside.

 I am going into django/contrib/admin but cannot find any class named 
modelAdmin.



same for this one. I am going into django/db//models but cannot find any 
class named Model in it. Please help in locating it.

 

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