#6735 -- Class based generic views: call for comment

[Russell Keith-Magee]

Hi all,

I've just added a summary of the last thread on class-based views [1].
This summary isn't 100% complete -- any contributions from interested
parties are welcome. Try to keep opinions to a minimum; this page is
about documenting the strengths and weaknesses of various approaches,
not about expressing opinions. In the same way that CSRF [2] and
session-messages [3] have good wiki pages describing the design
considerations, we need to be able to explain to future generations
why class-based views are the way they are.

Based on the discussion on the most recent thread [4], plus in-person
discussions, I'm proposing that we move forward with Ben Firshman and
David Larlet's "__call__ + copy()" approach. Yes, the copy() is a bit
of a weird idiom, but it's not an idiom that users need to be
particularly concerned with; the code "just works" in an unsurprising
way. The other viable option is the __new__ based copy; however, this
approach is also idiomatically surprising (instantiation returns an
object of type other than the object being constructed), and it
doesn't allow for the use of arguments at time of instantiation.

I'd like to try and get this in for 1.3. It's a big feature, which
means it needs to be in by October 18. However, based on the state of
the patch that Ben has prepared, I think this is an achievable goal.

Three things are required to make this happen:

 * Documentation. It looks like David Larlet has made a start on this
already, but there's lots more required.
 * Conversion of the github project into a patch on trunk.
 * Feedback on the API, especially the generic view replacements.

If you have any feedback, drop it into this thread so that we can
integrate the changes. If you are interested in helping out on the
first two points, drop a line here too so that we can coordinate
activity.

I already have one specific piece of API feedback: the current
implementation requires that all view logic is contained in GET(),
POST() etc style views. This is fine, except for the fact that there
are occasions where GET and POST share a lot of common logic. It would
make sense to me to allow for a request() method that is the direct
analog of how we do views right now, wrapping lines 53-59 of base.py
into a request() method. This would allow users to define their own
dispatch mechanisms, or share logic between GET and POST (and any
other http method) as necessary.

[1] http://code.djangoproject.com/wiki/ClassBasedViews
[2] http://code.djangoproject.com/wiki/CsrfProtection
[3] http://code.djangoproject.com/wiki/SessionMessages
[4] 
http://groups.google.com/group/django-developers/browse_thread/thread/e23d9a5a58fe5891

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-develop...@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: rethinking raw_id_fields

[tyrion-mx]

I've tried implementing Autocomplete for the admin using jQuery (new)
Autocomplete,
here's the code: http://bitbucket.org/tyrion/django
and here's a live demo (without css for the autocomplete, so it looks
kinda ugly): http://djangoac.tyrion.mx/admin/ login with test/test.

Let me know what you think about it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: Final call for comments

[Kevin Howerton]

re: verbose logging configuration.

This bothered me as well initially, though after starting to use
logging extensively I realized that there isn't really a more concise
way to provide all of the features that the logging config brings to
the table.

We can however, create a very concise default setup that mimics the
current admin-email behavior and provide additional documentation on
having more complex setups on djangoproject.com

ie:
LOGGING = {
'handlers': {
 'mail_admins': { 'level': 'ERROR',  'class':
'django.utils.log.AdminEmailHandler' }
}
'loggers': {
'django': { 'handlers': ['mail_admins'], 'level':
'ERROR', 'propagate': True }
}
}

Regarding the 'version' setting.. .is that in the python 2.7
implementation?  I ended up removing it from the included
logging-config in lumberjack as it wasn't really doing much.

I'm really pretty excited about this making it into 1.3... Thanks
guys!  I haven't looked at the code extensively, but it looks really
good (a lot of improvements over what I had).  I will take it for a
test drive this weekend though.

-k


On Thu, Sep 30, 2010 at 8:41 PM, Russell Keith-Magee
 wrote:
> On Fri, Oct 1, 2010 at 1:53 AM, Andy McCurdy  wrote:
>> Russ,
>> This will be a welcomed addition to debugging Django apps. I have a question
>> about startup.py. I notice that startup runs after settings are loaded, but
>> before models. Does this mean that code within startup.py cannot safely
>> access the ORM? If the ORM is fully accessible in startup.py, it's safe to
>> ignore the rest of the mail.
>
> The startup.py proposal has been dropped from the RC version of this patch.
>
> I still believe that there is a strong need for a 'startup logic'
> entry point, but it isn't required for the purposes of logging, and
> there is a significant overlap with the concerns of the AppCache
> refactor that was the subject of a SoC project this year. Rather than
> introduce an interface that wasn't strictly needed and was potentially
> going to be deprecated in the next release, we have opted to leave out
> this piece of functionality.
>
> 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-develop...@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-develop...@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: rethinking raw_id_fields

[subs...@gmail.com]

And then it was so:

http://code.djangoproject.com/ticket/14370

On Sep 30, 3:54 pm, "subs...@gmail.com"  wrote:
> Yeah, I think your right. raw_id_fields is a neat idea if you really
> are reluctant to use AJAX. If introducing AJAX into admin is fine,
> dumping these fields altogether seems the best approach.
>
> As for the options given, I've only used ajax-selects. I think its
> implementation is rather cumbersome in situations where I didn't
> really care about what the resulting list looked like (if I just
> wanted a list of the objects represented by whatever is in their
> __unicode__).
>
> So a starting admin equivalent might look like: ajax_fields =
> {'person': ['first_name','last_name']}. The list in this case is the
> search_fields which kind of mirrors admin's current functionality. Or
> maybe I'm getting ahead of myself.
>
> -Steve
>
> On Sep 30, 2:21 pm, "burc...@gmail.com"  wrote:
>
>
>
> > On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com  
> > wrote:
> > > At that point its not really raw_id_fields, is it? =)
>
> > After all, what's the purpose of these fields?
>
> > --
> > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> > MSN: bu...@live.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-develop...@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: #12012 Logging: Final call for comments

[Russell Keith-Magee]

On Fri, Oct 1, 2010 at 1:53 AM, Andy McCurdy  wrote:
> Russ,
> This will be a welcomed addition to debugging Django apps. I have a question
> about startup.py. I notice that startup runs after settings are loaded, but
> before models. Does this mean that code within startup.py cannot safely
> access the ORM? If the ORM is fully accessible in startup.py, it's safe to
> ignore the rest of the mail.

The startup.py proposal has been dropped from the RC version of this patch.

I still believe that there is a strong need for a 'startup logic'
entry point, but it isn't required for the purposes of logging, and
there is a significant overlap with the concerns of the AppCache
refactor that was the subject of a SoC project this year. Rather than
introduce an interface that wasn't strictly needed and was potentially
going to be deprecated in the next release, we have opted to leave out
this piece of functionality.

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-develop...@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: be localflavor Belgium

[Russell Keith-Magee]

On Fri, Oct 1, 2010 at 6:15 AM, Laurent Luce  wrote:
> I updated the be localflavor patch to use unit tests instead of
> doctests as requested. Can you check if this is what you want. There
> was no unit tests in regressiontests/forms/localflavor/ so I am not
> 100% sure I did what is expected. I took a look at the ones in
> regressiontests/forms as models.

The patch looks good, so I've just bumped the ticket to ready for checkin.

Thanks for the contribution!

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-develop...@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: be localflavor Belgium

[Laurent Luce]

I updated the be localflavor patch to use unit tests instead of
doctests as requested. Can you check if this is what you want. There
was no unit tests in regressiontests/forms/localflavor/ so I am not
100% sure I did what is expected. I took a look at the ones in
regressiontests/forms as models.

On Sep 29, 1:09 pm, Laurent Luce  wrote:
> I added a new patch to the ticket with the following changes:
> add support for 0, 04 phone number format. Wrap long
> lines.
>
> Laurent
>
> On Sep 29, 11:23 am, Gert Van Gool  wrote:
>
> > IMHO I would allow a non-spaced version. My typing my phone number as
> > 0498725202 should also work.
> > Second thing, wrap the long lines :)
>
> > Relevant ticket is #14349 (http://code.djangoproject.com/ticket/14349)
>
> > -- Gert
>
> > Mobile: +32 498725202
> > Twitter: @gvangool 
> > Web:http://gert.selentic.net
>
> > On Wed, Sep 29, 2010 at 18:26, Laurent Luce  wrote:
> > > Hello,
>
> > > I created a patch to add support for Belgium to localflavor. I
> > > attached the patch to a ticket which is marked as accepted. The patch
> > > contains the forms fields, unit tests and the doc changes.
>
> > > What do I need to do next ? Wait for someone to review the patch and
> > > commit it ?
>
> > > Laurent
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Django developers" group.
> > > To post to this group, send email to django-develop...@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-develop...@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: rethinking raw_id_fields

[subs...@gmail.com]

Yeah, I think your right. raw_id_fields is a neat idea if you really
are reluctant to use AJAX. If introducing AJAX into admin is fine,
dumping these fields altogether seems the best approach.

As for the options given, I've only used ajax-selects. I think its
implementation is rather cumbersome in situations where I didn't
really care about what the resulting list looked like (if I just
wanted a list of the objects represented by whatever is in their
__unicode__).

So a starting admin equivalent might look like: ajax_fields =
{'person': ['first_name','last_name']}. The list in this case is the
search_fields which kind of mirrors admin's current functionality. Or
maybe I'm getting ahead of myself.

-Steve

On Sep 30, 2:21 pm, "burc...@gmail.com"  wrote:
> On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com  wrote:
> > At that point its not really raw_id_fields, is it? =)
>
> After all, what's the purpose of these fields?
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.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-develop...@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: Proposal: Combine aggregation docs

[Jacob Kaplan-Moss]

On Thu, Sep 30, 2010 at 11:34 AM, Yo-Yo Ma  wrote:
>  I would
> propose putting an aggregation function list on that page, rather than
> letting the user eventually find the list at the bottom of the
> QuerySet page. Or, put a prominent link near the top that suggests
> visiting QuerySet docs for a full list of aggregation features. I
> think this will get people going on aggregation more quickly.

Sounds like a great idea -- go for it!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Need opinion for an object permission rule backend

[Miguel Araujo]

Thanks Cesar Canassa. I didn't know this project, I have had a look at the
code.

The only problem I see with this backend, as the one explained by Apolloner,
is the fact, that I don't think it can scale very well. There are so many
combinations of object.ids and user.ids to handle, that my approach was
trying to create something like rules or roles. Michael Hall at django-users
have pointed me out to look at
Django-extauth,
which I've found very close to what I was proposing, but better :)
http://bitbucket.org/mhall119/django-extauth/overview

Thanks, best regards
Miguel Araujo

2010/9/30 Cesar Canassa 

> Take a look in the django-guardian project
>
> http://github.com/lukaszb/django-guardian
>
> Regards,
> Cesar
>
> 2010/9/30 Miguel Araujo 
>
>>  Since you are not suggesting something for inclusion in Django itself,
>>> this is not the right mailing list for this kind of post. You don't need
>>> the opinion of the core Django developers for this - the publicly
>>> documented APIs and normal Python/programming practices give you
>>> everything you need.  Please ask on django-users.
>>>
>>
>> Well, as the Object Permission system is very new and I haven't found a
>> solid permission backend, just examples. I first thought developers could
>> decide if the approach was right. On the other hand, I might have to patch
>> some django code to make my permission system work.
>>
>> In any case, I will send my question to django-users, sorry for
>> the confusion.
>>
>> Best regards,
>> Miguel
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@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-develop...@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-develop...@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: rethinking raw_id_fields

[burc...@gmail.com]

On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com  wrote:
> At that point its not really raw_id_fields, is it? =)

After all, what's the purpose of these fields?

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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-develop...@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: #12012 Logging: Final call for comments

[Andy McCurdy]

Russ,

This will be a welcomed addition to debugging Django apps. I have a question
about startup.py. I notice that startup runs after settings are loaded, but
before models. Does this mean that code within startup.py cannot safely
access the ORM? If the ORM is fully accessible in startup.py, it's safe to
ignore the rest of the mail.

If I cannot access models from startup.py, I have two concerns:

1. It seems fairly limiting. We currently have a hacked together startup
system for several ORM-related tasks. I'd love to replace this with yours,
assuming I don't lose functionality. Most notable, we have configuration
stored in the DB that is used to determine application behavior. Another use
case is using the startup system to add some of our template tags libraries
to builtins. Some of these template tag libs import models. Would this end
up causing circular reference issues?

We used to have these kinds of tasks load on the first request Django
processed using the request_started signal. However, this was limiting
because management commands and celery tasks never received the signal. We
need a system where no matter how our Django is loaded, startup happens.

2. What kind of error message am I going to receive if I do access models?
Debugging circular references is quite painful. At the very least, we should
consider a user trying to import models (or something else that imports
models) a common error and attempt to present a concise error message.

-andy

On Thu, Sep 30, 2010 at 6:56 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Hi all,
>
> A final call for comment before I commit #12012 to trunk. Barring
> objection, my intention is to commit this early next week.
>
> I've integrated the suggestions that have arisen since the first draft:
>
>  * This patch has docs :-) There aren't any tests though, and I think
> it's going to have to stay that way; this is one of those areas where
> it's almost impossible to test because it's very difficult to mock out
> early stages of app configuration. The good news is that the complex
> logic is all contained inside Python's logging library itself, and the
> logging calls that have been introduced are all exercised as part of a
> normal test run.
>
>  * I've modified the interpretation of LOGGING_CONFIG such that a
> value of None means "don't configure logging"
>
>  * I've modified the global-settings and project template logging
> settings. They are now at parity.
>
>  * I've modified the logging information that is provided in the 4XX
> loggers so that a status code is provided as logging context. 4XX
> messages are all still logged as warnings, but if you want to change
> this, you now have enough detail in the log record to use a log filter
> for that purpose.
>
> If you have any objections, now is the time to raise them.
>
> 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-develop...@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-develop...@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.

Proposal: Combine aggregation docs

[Yo-Yo Ma]

Django's aggregation is a great tool. That said; if I'm a new user who
knows it exists but not how it works, I'll likely pull up the page
about Aggregation (http://docs.djangoproject.com/en/dev/topics/db/
aggregation/). This page gives an excellent overview, but leaves me
feeling like there is something missing (such as Sum(), etc). I would
propose putting an aggregation function list on that page, rather than
letting the user eventually find the list at the bottom of the
QuerySet page. Or, put a prominent link near the top that suggests
visiting QuerySet docs for a full list of aggregation features. I
think this will get people going on aggregation more quickly.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: rethinking raw_id_fields

[subs...@gmail.com]

At that point its not really raw_id_fields, is it? =)

-Steve

On Sep 30, 3:07 am, "burc...@gmail.com"  wrote:
> Hi Subsume,
>
> why not just replace them with some proper implementation of ajax completion ?
>
> http://djangopackages.com/grids/g/auto-complete/
>
> On Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com  wrote:
> > Hello all,
>
> > I was browsing the tickets and saw a few of them nagging about some
> > restrictions to raw_id_fields. That they are limited to other objects
> > registered in admin, that they are limited arbitrarily (relative to a
> > regular FK) by the permissions of the user, etc. Personally, I find
> > the little changelist window that pops up a bit awkward and hackish-
> > looking.
>
> > Might a better approach be to have a django-admin view which uses
> > content-types to generate a list of the objects in question? If
> > someone can give me a simple yes, no, etc, I'd be willing to do the
> > necessary ticket-work and come up with a patch for review.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.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-develop...@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: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote:

So, let me be clear on what you're proposing: you acknowledge that the
triage process is backlogged. Your proposal is to put extra workload
onto the core team - the one group that is already a bottleneck in the
process.


Pretty much. I just don't put it the way you do.

Triage process is backlogged not because of some strange reason. People 
need motivation to do daunting work and I can't imagine what could 
motivate enough volunteers to triage other people bugs regularly. And no 
amount documentation will fix this. A committer on the other hand is not 
just a volunteer. Being a committer of a high-profile open-source is a 
nice ego boost and committers receive more moral compensation than 
casual contributors. They are higher in an implicit project hierarchy 
and it matters to people.


As for bottleneck, I propose this only in light of Jacob's decision to 
increase the number of committers. This is certainly a prerequisite. 
It's not a question that committers are overloaded and this why this 
conversation has started.


To put it *really* short: I'm not trying to find extra work for 
committers, I'm bluntly saying that no one else would ever do it. So we 
have to find ways to do it. And having more committers and a simpler 
decision process does help here.



If you estimate that it takes an hour to close a ticket


This is BTW another, purely technical, problem. It shouldn't take an 
hour to close a ticket if it has proper tests. I was testing patches 
during various sprints and one big thing that I learned is that our 
whole test suit needs a deep refactoring to be simpler and faster. But 
this is another story...


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: Need opinion for an object permission rule backend

[Cesar Canassa]

Take a look in the django-guardian project

http://github.com/lukaszb/django-guardian

Regards,
Cesar

2010/9/30 Miguel Araujo 

> Since you are not suggesting something for inclusion in Django itself,
>> this is not the right mailing list for this kind of post. You don't need
>> the opinion of the core Django developers for this - the publicly
>> documented APIs and normal Python/programming practices give you
>> everything you need.  Please ask on django-users.
>>
>
> Well, as the Object Permission system is very new and I haven't found a
> solid permission backend, just examples. I first thought developers could
> decide if the approach was right. On the other hand, I might have to patch
> some django code to make my permission system work.
>
> In any case, I will send my question to django-users, sorry for
> the confusion.
>
> Best regards,
> Miguel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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: #12012 Logging: Final call for comments

[Russell Keith-Magee]

On Thu, Sep 30, 2010 at 10:03 PM, Jacob Kaplan-Moss  wrote:
> On Thu, Sep 30, 2010 at 8:56 AM, Russell Keith-Magee
>  wrote:
>> If you have any objections, now is the time to raise them.
>
> This isn't an objection, per se -- don't let it stop you committing --
> but I'm somewhat concerned with the verbosity of the LOGGING setting.
> We're adding 40 lines of configuration to a file only about 100 lines
> long, which to my mind means we've increased the cognitive load of
> groking settings.py by about 40%. When I look at the new LOGGING
> setting, I don't have a firm idea what it's doing.
>
> Now, I know the format's coming straight from the new logging work in
> Python 2.7, and I clearly don't want to come up with our own format.
> I'm just hoping someone'll have a bright idea how to cut down on "oh
> god WTF do those lines mean!?" nature of the new crud at the bottom of
> settings.py

For posterity -- Jacob and I talked about this on IRC; we came to two
conclusions:

 * I'll have a fiddle to see if I can make the default configuration
more concise. Given that the only logger we actually need to do
something is the AdminEmailHandler, there's probably some room to
leave out a couple of handlers and loggers, or at the very least give
some brief inline documentation of what is there.

 * I'll include a comment in the project template that provides a
direct link to Django's logging documentation. If we're going to
introduce a big block of configuration, the least we can do is point
people at the instructions for how to use it.

One other thing that I forgot to mention in my original email: This
patch drops the startup.py proposal. It looks like Arthur Koziel's app
refactor will cover this use case, and we don't want to introduce an
interface that we deprecate in the next release.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12012 Logging: Final call for comments

[Jacob Kaplan-Moss]

On Thu, Sep 30, 2010 at 8:56 AM, Russell Keith-Magee
 wrote:
> If you have any objections, now is the time to raise them.

This isn't an objection, per se -- don't let it stop you committing --
but I'm somewhat concerned with the verbosity of the LOGGING setting.
We're adding 40 lines of configuration to a file only about 100 lines
long, which to my mind means we've increased the cognitive load of
groking settings.py by about 40%. When I look at the new LOGGING
setting, I don't have a firm idea what it's doing.

Now, I know the format's coming straight from the new logging work in
Python 2.7, and I clearly don't want to come up with our own format.
I'm just hoping someone'll have a bright idea how to cut down on "oh
god WTF do those lines mean!?" nature of the new crud at the bottom of
settings.py

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

#12012 Logging: Final call for comments

[Russell Keith-Magee]

Hi all,

A final call for comment before I commit #12012 to trunk. Barring
objection, my intention is to commit this early next week.

I've integrated the suggestions that have arisen since the first draft:

 * This patch has docs :-) There aren't any tests though, and I think
it's going to have to stay that way; this is one of those areas where
it's almost impossible to test because it's very difficult to mock out
early stages of app configuration. The good news is that the complex
logic is all contained inside Python's logging library itself, and the
logging calls that have been introduced are all exercised as part of a
normal test run.

 * I've modified the interpretation of LOGGING_CONFIG such that a
value of None means "don't configure logging"

 * I've modified the global-settings and project template logging
settings. They are now at parity.

 * I've modified the logging information that is provided in the 4XX
loggers so that a status code is provided as logging context. 4XX
messages are all still logged as warnings, but if you want to change
this, you now have enough detail in the log record to use a log filter
for that purpose.

If you have any objections, now is the time to raise them.

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-develop...@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: Need opinion for an object permission rule backend

[Miguel Araujo]

>
> Since you are not suggesting something for inclusion in Django itself,
> this is not the right mailing list for this kind of post. You don't need
> the opinion of the core Django developers for this - the publicly
> documented APIs and normal Python/programming practices give you
> everything you need.  Please ask on django-users.
>

Well, as the Object Permission system is very new and I haven't found a
solid permission backend, just examples. I first thought developers could
decide if the approach was right. On the other hand, I might have to patch
some django code to make my permission system work.

In any case, I will send my question to django-users, sorry for
the confusion.

Best regards,
Miguel

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Need opinion for an object permission rule backend

[Luke Plant]

On Thu, 2010-09-30 at 13:29 +0200, Miguel Araujo wrote:
> Hi everyone,
> 
> 
> I have been recently thinking about an object permission system. After
> reviewing Florian Apolloner (apollo13) patch for ticket #11010 and
> reading his article at Django Advent. I though about creating an
> Object Permission Rule Backend. The purpose of this message is explain
> you my idea, so I can receive feedback from Django developers with
> better understanding of the internals of the Framework. This way I
> would like to discern if it's worth coding it or if it's a good
> approach to a reusable solution.

Since you are not suggesting something for inclusion in Django itself,
this is not the right mailing list for this kind of post. You don't need
the opinion of the core Django developers for this - the publicly
documented APIs and normal Python/programming practices give you
everything you need.  Please ask on django-users.

Thanks,

Luke

-- 
"Despair: It's always darkest just before it goes pitch black." 
(despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Need opinion for an object permission rule backend

[Miguel Araujo]

Hi everyone,

I have been recently thinking about an object permission system. After
reviewing Florian Apolloner (apollo13) patch for ticket
#11010 and
reading his article at Django
Advent.
I though about creating an Object Permission Rule Backend. The purpose of
this message is explain you my idea, so I can receive feedback from Django
developers with better understanding of the internals of the Framework. This
way I would like to discern if it's worth coding it or if it's a good
approach to a reusable solution.

I will reuse apollo's code to elaborate my idea.

class ObjectPermBackend(object):
supports_object_permissions = True
supports_anonymous_user = True

def authenticate(self, username, password):
return None

def has_perm(self, user_obj, perm, obj=None):
if not user_obj.is_authenticated():
user_obj = User.objects.get(pk=settings.ANONYMOUS_USER_ID)

if obj is None:
return False

ct = ContentType.objects.get_for_model(obj)

try:
perm = perm.split('.')[-1].split('_')[0]
except IndexError:
return False

# Simplified rule system
# Of course objects should extend an interface
if (perm == "ownage")
 return obj.is_owned_by(user_obj)

elif (perm == "edit")
 return obj.can_be_edited_by(user_obj)

# Here be Dragons

As I love decorators, I would like to create a permission_required decorator
that accepted more than a parameter, so:

@permission_required('app.code_name') would
become @permission_required('app.code_name', FLAG)

If the FLAG is set the decorator searches in the model associated to the
content type of the permission, for the name of the field for the PK. For
the example imagine idArticle. Now it instantiates an object of that model
with Model.objects.get(pk=request.idArticle). So it would be necessary to
match request parameters to model fileds (This is the best idea I've come up
with). Once it has the right object, it passes it to the backend for
permission checks.

I know I could do a decorator like @own_article but I'm looking for a more
reusable solution, that I would make open source and release at Github.

What do you think? Is it feasible and well laid out?

Thanks, best regards
Miguel Araujo

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: No caching if request.GET not empty

[Thomas Guettler]

I updated the patch
  
http://code.djangoproject.com/attachment/ticket/4992/cache_by_request_full_path_v2.diff

I think it is ready for commit. The patch has docs and tests.

Can someone please test it on different plattforms?

I used: Python 2.5.1 on linux.

  Thomas

Mikhail Korobov wrote:
> Hi Thomas,
> 
> there is a ticket for that:
> 
> http://code.djangoproject.com/ticket/4992

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Error email flooding on high traffic production sites

[Andrew Wilkinson]

Hi,

Sorry the digging up an old thread, I'm a bit behind on my reading of
django-dev.

I have a patch in the bug tracker that fixes this exact problem -
http://code.djangoproject.com/ticket/11565. The patch is just over a
year old now so it might not apply that cleanly to the current trunk.

The patch works by caching an MD5 of the traceback for each error with
a timeout of settings.ERROR_EMAIL_RATE_LIMIT minutes. This prevents
the same error being sent more than once in the time. It's not perfect
because a single error might cause multiple tracebacks and you'd get
one email for each distinct one. It's definitely better than the
current situation though. It also relies on you having a cache backend
set up.

Unfortunately I never did get time to write unittests for it, and
unittesting something like this is quite hard because of the timeout
involved.

Hope this is useful,
Andrew

On Thu, Sep 9, 2010 at 4:26 AM, Simon Litchfield  wrote:
> Hi all
>
> Default behaviour of sending an email on 500 error is great.
>
> Problem is on high traffic sites, and you might just be making a quick
> update- literally within seconds you can bring your mail server down-
> crash your mail client- or render your gmail account useless.
>
> With "batteries included" and "production ready" ethos in mind, I
> reckon this needs fixing.
>
> 1) Max emails per minute setting
>
> 2) Include alternative error handler middleware in core
>
> I haven't tried it yet, but this looks interesting (note web2py
> includes this) --
> http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home
>
> Thoughts? I know I'm not the only one who has run into this (Russ?)
>
> Cheers
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Thursday, September 30, 2010, Ivan Sagalaev
 wrote:
> On 09/30/2010 03:46 AM, Russell Keith-Magee wrote:
>
> Accepted tickets can be:
>
>   * Purely accepted, indicating that someone has verified that the
> problem exists, but not how to solve it
>
>   * Accepted with a patch that is wrong in some way (e.g., fixing the
> symptom, not the problem)
>
>   * Accepted with a patch that is missing documentation or tests
>
>   * Accepted with a valid patch, just awaiting review by someone else.
>
> A ticket in the first three conditions patently isn't ready for
> checkin. A ticket in the last condition *may* be ready for checkin; we
> ask for independent verification before it gets moved to RFC.
>
> So - IMHO "Accepted" plays a very important role in our triage system.
>
>
> To me this shows exactly the opposite: a status that has so many meanings 
> doesn't really mean anything useful :-). I'm not new in Django development 
> yet as you see I managed to misunderstand its meaning in my previous mail.

Accepted means exactly one thing - the issue has been verified as a
real problem (or acknowledged as a reasonable feature request), but
isn't yet ready for inclusion in trunk.

If viewed in combination with the other flags on a ticket, you can
work out why a ticket isn't ready for inclusion in trunk - it needs
documentation, it needs tests, it needs a patch, or the patch that
exists needs improvement.

As Waylan noted, this probably indicates that our documentation needs
to be improved.

> Anyway, what I'm saying is that we have this huge gap between someone writing 
> a good patch (with docs & tests) and the moment it gets into trunk. Current 
> mechanism of volunteer triagers who are supposed to move such tickets from 
> 'accepted' into 'ready for checkin' doesn't seem to work.

The officially documented practice is that the "triage team" moves
tickets to RFC. However, this hasn't been actual practice for some
time. The effective practice is that anyone other than the submitted
of a patch can m ove a ticket to RFC if they feel confident that it is
ready.

This is certainly an area where the documentation needs to be
improved, in order to reflect common practice.

What is also needed is a whole lot more people volunteering. Any
suggestions on how to get more people doing the entirely unglamorous,
but completely necessary work will be gratefully accepted.

> So let me mend my suggestion to better fit reality. Instead of removing 
> 'accepted' altogether (though I still think it's a good idea) I think each 
> committer has to do this routinely. I know that every programmer would rather 
> code instead of applying patches and running tests but the development 
> process simply won't scale otherwise.

So, let me be clear on what you're proposing: you acknowledge that the
triage process is backlogged. Your proposal is to put extra workload
onto the core team - the one group that is already a bottleneck in the
process.

During the 1.2 release cycle, I had to spend almost 2 weeks checking
tickets in the unreviewed state in order to check that no release
blocking bugs had been reported. This amounts to something like 50
hours of development effort - 50 hours that I didn't spend closing
bugs. If you estimate that it takes an hour to close a ticket, that
means 1.2 has 50 more bugs in it than it would have had if someone not
on the core team had performed the triage task.

As I write this, there are 215 tickets in the unreviewed state. There
is plenty of triage work to do, and absolutely no reason that the core
team has to be the group to do it.

> BTW, Bazaar guys use the approach with a "champion of the week". Every week a 
> person from core committers volunteers to actively do triaging and committing 
> new and old tickets in the tracker. May be such explicit approach would work 
> for Django too. Especially since we're about to have more committers than we 
> do now.

The core team volunteers the time that they have available. Some weeks
that means a lot of time; some weeks it means no time. Sometimes time
is spent closing tickets, and sometimes - when it's clear that there
is a backlog of unreviewed tickets blocking a release, for example -
the core team will do triage.

The core team isn't wanting for things to do. There a plenty of
tickets in RFC; there is lots of mailing list traffic that needs
attention; there are new features that need to be designed, built and
reviewed; and yes, there is triage. Forcing core developers to do
triage exclusively simply takes energy away from other, equally
important tasks that form part of the development process.

On top of that, I can't speak for anyone else in the core team, but I
fail to see see how a formal "this week is my week" arrangement will
increase the time I have available to volunteer to the project. If
anything, I see it decreasing the quantity of volunteered time,
because if I don't think I will be able to dedicate an entire week, I

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote:

Accepted tickets can be:

  * Purely accepted, indicating that someone has verified that the
problem exists, but not how to solve it

  * Accepted with a patch that is wrong in some way (e.g., fixing the
symptom, not the problem)

  * Accepted with a patch that is missing documentation or tests

  * Accepted with a valid patch, just awaiting review by someone else.

A ticket in the first three conditions patently isn't ready for
checkin. A ticket in the last condition *may* be ready for checkin; we
ask for independent verification before it gets moved to RFC.

So - IMHO "Accepted" plays a very important role in our triage system.


To me this shows exactly the opposite: a status that has so many 
meanings doesn't really mean anything useful :-). I'm not new in Django 
development yet as you see I managed to misunderstand its meaning in my 
previous mail.


Anyway, what I'm saying is that we have this huge gap between someone 
writing a good patch (with docs & tests) and the moment it gets into 
trunk. Current mechanism of volunteer triagers who are supposed to move 
such tickets from 'accepted' into 'ready for checkin' doesn't seem to work.


So let me mend my suggestion to better fit reality. Instead of removing 
'accepted' altogether (though I still think it's a good idea) I think 
each committer has to do this routinely. I know that every programmer 
would rather code instead of applying patches and running tests but the 
development process simply won't scale otherwise.


BTW, Bazaar guys use the approach with a "champion of the week". Every 
week a person from core committers volunteers to actively do triaging 
and committing new and old tickets in the tracker. May be such explicit 
approach would work for Django too. Especially since we're about to have 
more committers than we do now.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: rethinking raw_id_fields

[burc...@gmail.com]

Hi Subsume,

why not just replace them with some proper implementation of ajax completion ?

http://djangopackages.com/grids/g/auto-complete/

On Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com  wrote:
> Hello all,
>
> I was browsing the tickets and saw a few of them nagging about some
> restrictions to raw_id_fields. That they are limited to other objects
> registered in admin, that they are limited arbitrarily (relative to a
> regular FK) by the permissions of the user, etc. Personally, I find
> the little changelist window that pops up a bit awkward and hackish-
> looking.
>
> Might a better approach be to have a django-admin view which uses
> content-types to generate a list of the objects in question? If
> someone can give me a simple yes, no, etc, I'd be willing to do the
> necessary ticket-work and come up with a patch for review.

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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-develop...@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.