Re: where do class modelAdmin and Model reside.

[Ion Scerbatiuc]

Hello,

Please post your questions about Django usage on the django-users mailing
list. This group is about Django development itself.

To your question: try opening django/contrib/admin/__init__.py and you'll
find that ModelAdmin is imported from the options module of the admin
package. The same approach can be applied in finding the Model class or any
other imported stuff.

Good luck,
Ion


On Sun, Mar 24, 2013 at 8:06 AM, ANKIT BAGARIA wrote:

>
> 
>
> 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.
>
>
>

-- 
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.

Kickstarter for Django Admin?

[Victor Hooi]

Hi,

I read recently about Andrew Goodwin's successful kickstarter project for 
better Django schema migrations:

http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django

Kudos to him for awesome work on South so far a swell =).

There doesn't seem to be much movement on the Admin front - 
https://groups.google.com/d/msg/django-developers/Vozu6U3gz84/vvbTqrWitxIJ

I'm wondering - is there any impetus for a similar kickstarter for the 
Django admin?

I for one would be willing to put my money where my mouth is and back it - 
and I'm sure other people/companies who use Django in their own projects 
would as well.

Thoughts?

Cheers,
Victor

-- 
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

[Omer Katz]

You are contradicting yourself. At first you said that it does make the
code clearer. Now you say it doesn't.
Ok, you guys are right. I'm adding a new feature.
If you think my new design isn't good enough do tell me why. I'll improve
it/change it completely.
It now doesn't violate SRP, it allows flexability for those who need it and
maintains backward competitability. What else is missing here?
I feel a bit like a broken record here because I did specify over and over
what's the purpose of this change.
I don't want to load settings from a class.* I'd like to provide
extensibiloty points in order to help implemet other workflows that people
use.*
The purpose of this patch is to:

   - Allow developers to implement different workflows for loading settings
   for different environments (class based settings, different modules,
   different packages).
   - Allow developers to load settings from other sources like
django-debian
does.
   - Allow developers to change settings as they are collected (for example
   django-harness  does
   multiple things like this).

There are usecases, some people actually implemented those outside of the
framework and I don't see a reason why they should. We're perfectionists
with deadlines right? There's no reason to write django-configurations if
in five minutes you can get the same result out of the box.
Do you see value in django-configurations, django-debian or django-harness?
Then you must see the value in this patch. You can implement all of those
in an hour tops including documentation and tests with it.
If you don't, just keep using the default behavior. No harm done.

What exactly is the maintainance burden here?
Instead of saying "Check the DJANGO_SETTINGS_MODULE" you now just need to
ask "Have you written a new collector or loader? No? Check the
DJANGO_SETTINGS_MODULE".

You want to change how settings are being loaded by default? How does that
contradict the use of my patch?
In fact it makes it much easier because now you can just rewrite the
collector and loader and you have a new default way of loading settings.

I know there were talks about changing how settings behave and that's why I
did something about it.

Am I clear enough now?



2013/3/24 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 r

Re: Changes to django's settings module

[Russell Keith-Magee]

On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz  wrote:

> You are contradicting yourself. At first you said that it does make the
> code clearer. Now you say it doesn't.
>

My apologies -- I've apparently used an English idiom that doesn't have an
obvious meaning.

When I said "I'd argue the point that it makes the code clearer", that
means "You said it was clearer, I disagree, and I'd be willing to defend my
position."

I do not believe that your proposed patch makes the code clearer.

Ok, you guys are right. I'm adding a new feature.
> If you think my new design isn't good enough do tell me why. I'll improve
> it/change it completely.
> It now doesn't violate SRP, it allows flexability for those who need it
> and maintains backward competitability. What else is missing here?
> I feel a bit like a broken record here because I did specify over and over
> what's the purpose of this change.
> I don't want to load settings from a class.* I'd like to provide
> extensibiloty points in order to help implemet other workflows that people
> use.*
>

And at this point, I'm also feeling like a broken record. The point that I,
and several other people have made repeatedly is that we fail to see how
these extensibility points would be used in practice. You haven't
demonstrated a use case where what you describe would be helpful.

Saying "It makes it easier to implement django-configurations" isn't a use
case. A use case here might be "it makes it easier to define the
development/production settings split".

The purpose of this patch is to:
>
>- Allow developers to implement different workflows for loading
>settings for different environments (class based settings, different
>modules, different packages).
>- Allow developers to load settings from other sources like
>django-debian  does.
>- Allow developers to change settings as they are collected (for
>example django-harness does 
> multiple things like this).
>
> There are usecases, some people actually implemented those outside of the
> framework and I don't see a reason why they should. We're perfectionists
> with deadlines right? There's no reason to write django-configurations if
> in five minutes you can get the same result out of the box.
> Do you see value in django-configurations, django-debian or
> django-harness?
>

In short? No.

Adding an extensibility point is only beneficial if you actually want that
particular axis to be extensible. It's good that Django has an
extensibility point for database backends -- that allows someone outside
core to develop a backend for DB2 or MSSQL.

However, I don't see the benefit in having an extensible mechanism for
defining settings. Settings are settings. There should be *one* way to
define them, and that's it. There's *benefit* in there only being one way
to define settings, because that means that someone coming to a project for
doesn't need to discover, and then learn, about a whole other way of
defining the fundamental feature the settings for a Django project.

Are the problems with Django's settings framework? Yes. Are there areas
that would benefit from more documented "best practice" conventions?
Absolutely. Does any of this require a flexible framework for altering the
way Django loads settings? Not as far as I can make out.

Then you must see the value in this patch. You can implement all of those
> in an hour tops including documentation and tests with it.
> If you don't, just keep using the default behavior. No harm done.
>
> What exactly is the maintainance burden here?
>

There is code that can break. There is a publicly documented interface
that, once added, we must support into the future. If we ever want to make
a change to the way settings are handled (and we do, if you watch the video
I linked), we would also need to support this interface going forward. Once
a new feature is added, someone may ask for additional tweaks to that
feature. Someone may attempt to use that interface in an unconventional
way, forcing us to work out whether that usage is supported or not.

And on top of all of that, we're fracturing the community position on "how
do you define settings". Instead of being able to tell someone, "go look in
settings.py", we have to say "Go find out what settings loading mechanism
the project has, and then consult the documentation on that".

*That* is the maintenance burden.


> Instead of saying "Check the DJANGO_SETTINGS_MODULE" you now just need to
> ask "Have you written a new collector or loader? No? Check the
> DJANGO_SETTINGS_MODULE".
>
> You want to change how settings are being loaded by default? How does that
> contradict the use of my patch?
> In fact it makes it much easier because now you can just rewrite the
> collector and loader and you have a new default way of loading settings.
>
> I know there were talks about changing how settings behave and that's why
> I did something 

Re: Kickstarter for Django Admin?

[Russell Keith-Magee]

On Sun, Mar 24, 2013 at 6:20 PM, Victor Hooi  wrote:

> Hi,
>
> I read recently about Andrew Goodwin's successful kickstarter project for
> better Django schema migrations:
>
>
> http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django
>
> Kudos to him for awesome work on South so far a swell =).
>
> There doesn't seem to be much movement on the Admin front -
> https://groups.google.com/d/msg/django-developers/Vozu6U3gz84/vvbTqrWitxIJ
>
> I'm wondering - is there any impetus for a similar kickstarter for the
> Django admin?
>
> I for one would be willing to put my money where my mouth is and back it -
> and I'm sure other people/companies who use Django in their own projects
> would as well.
>

Good to hear :-)

There's one significant difference here. Andrew's project was to deliver
South-like functionality to trunk. South is a known quantity, and there
have been discussions and threads about exactly what merging South into
trunk would look like. And on top of all that, Andrew is the principle
author of South, so he's well positioned to do the work.

What's the feature set for a new Admin? What are the design goals? And most
importantly, who is going to do the work?

I'm not saying these questions can't be answered -- but the answers aren't
clear at the moment (at least, not to me). Once we've got a clear plan, and
someone who is available to deliver on that plan, then a Kickstarter might
be appropriate.

Yours,
Russ Magee %-)

-- 
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

[Albert O'Connor]

Hey Omar,

Though it may be clear now from this experience, I feel your expectations
about how code becomes a part of Django were incorrect, leading to
some frustration.

The onus is on the contributor not the core committers for nearly all
aspects of making a contribution, which is likely a difference versus a
smaller open source project. The onus is on the contributor to write the
patch, the tests and the documentation. Not having enough time isn't really
a reason not too, no one is paid to develop Django and no one has much
time. Just sharing code that might be useful is a nice gesture, but one
should not expect it to be picked up automatically.

The onus is also on the contributor to convince people that the change is
worth while. It isn't the job of the core team to argue why a change is not
worth making, though they often attempt to do so. The default reaction to
change is a conservative one, change must prove why it is useful, not the
other way around.

Like any open source project Django relies heavily on all the people who
contribute, but in order to make it stable and useful to the huge community
who uses, the process of getting change into it is intentionally somewhat
of an up hill battle where the onus is on the contributor at every stage,
not the project maintainers.

Albert O'Connor


On Sun, Mar 24, 2013 at 7:10 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz  wrote:
>
>> You are contradicting yourself. At first you said that it does make the
>> code clearer. Now you say it doesn't.
>>
>
> My apologies -- I've apparently used an English idiom that doesn't have an
> obvious meaning.
>
> When I said "I'd argue the point that it makes the code clearer", that
> means "You said it was clearer, I disagree, and I'd be willing to defend my
> position."
>
> I do not believe that your proposed patch makes the code clearer.
>
> Ok, you guys are right. I'm adding a new feature.
>> If you think my new design isn't good enough do tell me why. I'll improve
>> it/change it completely.
>> It now doesn't violate SRP, it allows flexability for those who need it
>> and maintains backward competitability. What else is missing here?
>> I feel a bit like a broken record here because I did specify over and
>> over what's the purpose of this change.
>> I don't want to load settings from a class.* I'd like to provide
>> extensibiloty points in order to help implemet other workflows that people
>> use.*
>>
>
> And at this point, I'm also feeling like a broken record. The point that
> I, and several other people have made repeatedly is that we fail to see how
> these extensibility points would be used in practice. You haven't
> demonstrated a use case where what you describe would be helpful.
>
> Saying "It makes it easier to implement django-configurations" isn't a use
> case. A use case here might be "it makes it easier to define the
> development/production settings split".
>
> The purpose of this patch is to:
>>
>>- Allow developers to implement different workflows for loading
>>settings for different environments (class based settings, different
>>modules, different packages).
>>- Allow developers to load settings from other sources like
>>django-debian  does.
>>- Allow developers to change settings as they are collected (for
>>example django-harness 
>> does multiple things like 
>> this).
>>
>> There are usecases, some people actually implemented those outside of the
>> framework and I don't see a reason why they should. We're perfectionists
>> with deadlines right? There's no reason to write django-configurations if
>> in five minutes you can get the same result out of the box.
>> Do you see value in django-configurations, django-debian or
>> django-harness?
>>
>
> In short? No.
>
> Adding an extensibility point is only beneficial if you actually want that
> particular axis to be extensible. It's good that Django has an
> extensibility point for database backends -- that allows someone outside
> core to develop a backend for DB2 or MSSQL.
>
> However, I don't see the benefit in having an extensible mechanism for
> defining settings. Settings are settings. There should be *one* way to
> define them, and that's it. There's *benefit* in there only being one way
> to define settings, because that means that someone coming to a project for
> doesn't need to discover, and then learn, about a whole other way of
> defining the fundamental feature the settings for a Django project.
>
> Are the problems with Django's settings framework? Yes. Are there areas
> that would benefit from more documented "best practice" conventions?
> Absolutely. Does any of this require a flexible framework for altering the
> way Django loads settings? Not as far as I can make out.
>
> Then you must see the value in this patch. You can implement all of those
>> in an hour top

Re: Changes to django's settings module

[Omer Katz]

2013/3/24 Russell Keith-Magee 

>
> On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz  wrote:
>
>> You are contradicting yourself. At first you said that it does make the
>> code clearer. Now you say it doesn't.
>>
>
> My apologies -- I've apparently used an English idiom that doesn't have an
> obvious meaning.
>
> When I said "I'd argue the point that it makes the code clearer", that
> means "You said it was clearer, I disagree, and I'd be willing to defend my
> position."
>
> I do not believe that your proposed patch makes the code clearer.
>
> Ok, you guys are right. I'm adding a new feature.
>> If you think my new design isn't good enough do tell me why. I'll improve
>> it/change it completely.
>> It now doesn't violate SRP, it allows flexability for those who need it
>> and maintains backward competitability. What else is missing here?
>>
>
You ignored this point completely. From the design perspective alone, is
there something wrong with this patch?


> I feel a bit like a broken record here because I did specify over and over
>> what's the purpose of this change.
>> I don't want to load settings from a class.* I'd like to provide
>> extensibiloty points in order to help implemet other workflows that people
>> use.*
>>
>
> And at this point, I'm also feeling like a broken record. The point that
> I, and several other people have made repeatedly is that we fail to see how
> these extensibility points would be used in practice. You haven't
> demonstrated a use case where what you describe would be helpful.
>
> Saying "It makes it easier to implement django-configurations" isn't a use
> case. A use case here might be "it makes it easier to define the
> development/production settings split".
>

If the purpose of django-configurations is (also) make it easier to define
the development/production settings split then you can easily deduct that
if anyone can implement it in 5 minutes it will also be easier to split
development/production settings.
django-configurations take the class based approach but you can just as
easily load settings from the development package or the production package.
If I want to package a django package for debian it is now very easy to add
a source that loads the database settings from dbconfig instead of hacking
your way around django.
If I want to get the database configuration from an environment variable or
parse it from a database url (like how
dj-database-configdoes)
it also make it much easier.
What kind of example do you want? django-configurations, django-debian &
django-harness are examples of what I'd like to be able to get almost out
of the box.
I want to be able to split development settings from production settings in
any way I feel that is contributing to my project.
I want to be able to package it for deb, rpm and other repositories.
I want to be able to load the installed apps from the apps folder by
packages and not only by specifying them.
These are just examples of things that people already implemented in a
hackish way.
What example do you want exactly?


> The purpose of this patch is to:
>>
>>- Allow developers to implement different workflows for loading
>>settings for different environments (class based settings, different
>>modules, different packages).
>>- Allow developers to load settings from other sources like
>>django-debian  does.
>>- Allow developers to change settings as they are collected (for
>>example django-harness 
>> does multiple things like 
>> this).
>>
>> There are usecases, some people actually implemented those outside of the
>> framework and I don't see a reason why they should. We're perfectionists
>> with deadlines right? There's no reason to write django-configurations if
>> in five minutes you can get the same result out of the box.
>> Do you see value in django-configurations, django-debian or
>> django-harness?
>>
>
> In short? No.
>

And now give me the long version. Why each of these examples are not valid
workflows that people want to use?


>
> Adding an extensibility point is only beneficial if you actually want that
> particular axis to be extensible. It's good that Django has an
> extensibility point for database backends -- that allows someone outside
> core to develop a backend for DB2 or MSSQL.
>
> However, I don't see the benefit in having an extensible mechanism for
> defining settings. Settings are settings. There should be *one* way to
> define them, and that's it. There's *benefit* in there only being one way
> to define settings, because that means that someone coming to a project for
> doesn't need to discover, and then learn, about a whole other way of
> defining the fundamental feature the settings for a Django project.
>

The default behavior is still there. Go ahead and use it.
But those who created these projects disagree with you. They want a
different 

Re: Changes to django's settings module

[Omer Katz]

My name is Om*e*r and got it. :)


2013/3/24 Albert O'Connor 

> Hey Omar,
>
> Though it may be clear now from this experience, I feel your expectations
> about how code becomes a part of Django were incorrect, leading to
> some frustration.
>
> The onus is on the contributor not the core committers for nearly all
> aspects of making a contribution, which is likely a difference versus a
> smaller open source project. The onus is on the contributor to write the
> patch, the tests and the documentation. Not having enough time isn't really
> a reason not too, no one is paid to develop Django and no one has much
> time. Just sharing code that might be useful is a nice gesture, but one
> should not expect it to be picked up automatically.
>
> The onus is also on the contributor to convince people that the change is
> worth while. It isn't the job of the core team to argue why a change is not
> worth making, though they often attempt to do so. The default reaction to
> change is a conservative one, change must prove why it is useful, not the
> other way around.
>
> Like any open source project Django relies heavily on all the people who
> contribute, but in order to make it stable and useful to the huge community
> who uses, the process of getting change into it is intentionally somewhat
> of an up hill battle where the onus is on the contributor at every stage,
> not the project maintainers.
>
> Albert O'Connor
>
>
> On Sun, Mar 24, 2013 at 7:10 AM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>>
>> On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz  wrote:
>>
>>> You are contradicting yourself. At first you said that it does make the
>>> code clearer. Now you say it doesn't.
>>>
>>
>> My apologies -- I've apparently used an English idiom that doesn't have
>> an obvious meaning.
>>
>> When I said "I'd argue the point that it makes the code clearer", that
>> means "You said it was clearer, I disagree, and I'd be willing to defend my
>> position."
>>
>>  I do not believe that your proposed patch makes the code clearer.
>>
>>  Ok, you guys are right. I'm adding a new feature.
>>> If you think my new design isn't good enough do tell me why. I'll
>>> improve it/change it completely.
>>> It now doesn't violate SRP, it allows flexability for those who need it
>>> and maintains backward competitability. What else is missing here?
>>> I feel a bit like a broken record here because I did specify over and
>>> over what's the purpose of this change.
>>> I don't want to load settings from a class.* I'd like to provide
>>> extensibiloty points in order to help implemet other workflows that people
>>> use.*
>>>
>>
>> And at this point, I'm also feeling like a broken record. The point that
>> I, and several other people have made repeatedly is that we fail to see how
>> these extensibility points would be used in practice. You haven't
>> demonstrated a use case where what you describe would be helpful.
>>
>> Saying "It makes it easier to implement django-configurations" isn't a
>> use case. A use case here might be "it makes it easier to define the
>> development/production settings split".
>>
>> The purpose of this patch is to:
>>>
>>>- Allow developers to implement different workflows for loading
>>>settings for different environments (class based settings, different
>>>modules, different packages).
>>>- Allow developers to load settings from other sources like
>>>django-debian  does.
>>>- Allow developers to change settings as they are collected (for
>>>example 
>>> django-harnessdoes multiple 
>>> things like this).
>>>
>>> There are usecases, some people actually implemented those outside of
>>> the framework and I don't see a reason why they should. We're
>>> perfectionists with deadlines right? There's no reason to write
>>> django-configurations if in five minutes you can get the same result out of
>>> the box.
>>> Do you see value in django-configurations, django-debian or
>>> django-harness?
>>>
>>
>> In short? No.
>>
>> Adding an extensibility point is only beneficial if you actually want
>> that particular axis to be extensible. It's good that Django has an
>> extensibility point for database backends -- that allows someone outside
>> core to develop a backend for DB2 or MSSQL.
>>
>> However, I don't see the benefit in having an extensible mechanism for
>> defining settings. Settings are settings. There should be *one* way to
>> define them, and that's it. There's *benefit* in there only being one way
>> to define settings, because that means that someone coming to a project for
>> doesn't need to discover, and then learn, about a whole other way of
>> defining the fundamental feature the settings for a Django project.
>>
>> Are the problems with Django's settings framework? Yes. Are there areas
>> that would benefit from more documented "best practice" conventions?
>> Absolutely. Does any of this re

Re: Changes to django's settings module

[Jacob Kaplan-Moss]

Hi Omer -

OK, I think it's time for you to drop this. Thanks for your
suggestions, but we're not going to be adding this to Django.

Jacob

On Sun, Mar 24, 2013 at 9:32 AM, Omer Katz  wrote:
> 2013/3/24 Russell Keith-Magee 
>>
>>
>> On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz  wrote:
>>>
>>> You are contradicting yourself. At first you said that it does make the
>>> code clearer. Now you say it doesn't.
>>
>>
>> My apologies -- I've apparently used an English idiom that doesn't have an
>> obvious meaning.
>>
>> When I said "I'd argue the point that it makes the code clearer", that
>> means "You said it was clearer, I disagree, and I'd be willing to defend my
>> position."
>>
>> I do not believe that your proposed patch makes the code clearer.
>>
>>> Ok, you guys are right. I'm adding a new feature.
>>> If you think my new design isn't good enough do tell me why. I'll improve
>>> it/change it completely.
>>> It now doesn't violate SRP, it allows flexability for those who need it
>>> and maintains backward competitability. What else is missing here?
>
>
> You ignored this point completely. From the design perspective alone, is
> there something wrong with this patch?
>
>>>
>>> I feel a bit like a broken record here because I did specify over and
>>> over what's the purpose of this change.
>>> I don't want to load settings from a class. I'd like to provide
>>> extensibiloty points in order to help implemet other workflows that people
>>> use.
>>
>>
>> And at this point, I'm also feeling like a broken record. The point that
>> I, and several other people have made repeatedly is that we fail to see how
>> these extensibility points would be used in practice. You haven't
>> demonstrated a use case where what you describe would be helpful.
>>
>> Saying "It makes it easier to implement django-configurations" isn't a use
>> case. A use case here might be "it makes it easier to define the
>> development/production settings split".
>
>
> If the purpose of django-configurations is (also) make it easier to define
> the development/production settings split then you can easily deduct that if
> anyone can implement it in 5 minutes it will also be easier to split
> development/production settings.
> django-configurations take the class based approach but you can just as
> easily load settings from the development package or the production package.
> If I want to package a django package for debian it is now very easy to add
> a source that loads the database settings from dbconfig instead of hacking
> your way around django.
> If I want to get the database configuration from an environment variable or
> parse it from a database url (like how dj-database-config does) it also make
> it much easier.
> What kind of example do you want? django-configurations, django-debian &
> django-harness are examples of what I'd like to be able to get almost out of
> the box.
> I want to be able to split development settings from production settings in
> any way I feel that is contributing to my project.
> I want to be able to package it for deb, rpm and other repositories.
> I want to be able to load the installed apps from the apps folder by
> packages and not only by specifying them.
> These are just examples of things that people already implemented in a
> hackish way.
> What example do you want exactly?
>
>>
>>> The purpose of this patch is to:
>>>
>>> Allow developers to implement different workflows for loading settings
>>> for different environments (class based settings, different modules,
>>> different packages).
>>> Allow developers to load settings from other sources like django-debian
>>> does.
>>> Allow developers to change settings as they are collected (for example
>>> django-harness does multiple things like this).
>>>
>>> There are usecases, some people actually implemented those outside of the
>>> framework and I don't see a reason why they should. We're perfectionists
>>> with deadlines right? There's no reason to write django-configurations if in
>>> five minutes you can get the same result out of the box.
>>> Do you see value in django-configurations, django-debian or
>>> django-harness?
>>
>>
>> In short? No.
>
>
> And now give me the long version. Why each of these examples are not valid
> workflows that people want to use?
>
>>
>>
>> Adding an extensibility point is only beneficial if you actually want that
>> particular axis to be extensible. It's good that Django has an extensibility
>> point for database backends -- that allows someone outside core to develop a
>> backend for DB2 or MSSQL.
>>
>> However, I don't see the benefit in having an extensible mechanism for
>> defining settings. Settings are settings. There should be *one* way to
>> define them, and that's it. There's *benefit* in there only being one way to
>> define settings, because that means that someone coming to a project for
>> doesn't need to discover, and then learn, about a whole other way of
>> defining the fundamental feature the settings fo

Re: memory leak in django 1.5

[Craig de Stigter]

Just confirming that this fixed the memory leak problem for us. Thanks 
again :)

On Friday, March 22, 2013 3:07:02 PM UTC+13, Craig de Stigter wrote:
>
> Karen Tracey saves the day!
>
> Thanks so much, seems likely that's it :)
>
> Craig de Stigter
>
> On Friday, March 22, 2013 2:25:04 PM UTC+13, Karen Tracey wrote:
>>
>> On Thu, Mar 21, 2013 at 9:00 PM, Craig de Stigter wrote:
>>
>>> Hi everyone
>>>
>>> (cross-posted because this seems relevant to both django-users and 
>>> developers, and both might have experienced this problem)
>>>
>>> We've noticed a gradual increase in memory usage for our apache 
>>> processes since upgrading to django 1.5.
>>>
>>> Here is a graph  showing memory usage 
>>> before and after we upgraded to django 1.5 on our web server. (the upgrade 
>>> occurs at 12:30 on the graph).
>>>
>>> I'm hoping someone else has noticed a similar thing and is able to 
>>> provide some insight.
>>>
>>
>> https://code.djangoproject.com/ticket/19895#comment:6
>>
>> notes a memory leak due to a fix that went into 1.5. 
>>
>> The fix was reverted on the 1.5.x branch about two days ago, so one thing 
>> to try would be to run current 1.5.x branch level rather than released 1.5.
>>
>> Karen
>>
>

-- 
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?

[Gavin Wahl]

+1. This has been a problem for me too.

On Saturday, March 23, 2013 5:16:15 AM UTC-6, Evgeny wrote:
>
> 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.