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

On Oct 1, 10:00 pm, Russell Keith-Magee wrote: > Now, I'm sure the counterargument is going to be that copy() will be > just as error prone and FAQ inducing. My argument to this is: Yes. >   * when it fails, it will fail during development, not just in production > >  

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

On Sat, Oct 2, 2010 at 11:37 AM, David P. Novakovic wrote: > By this reasoning, when you add extra helper methods to your class, > which is the reason for OO views, you need to add/use the data those > methods will modify to the request object? That just doesn't make >

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

On Sat, Oct 2, 2010 at 12:26 PM, Ian Lewis wrote: > On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote: >> Not really.  The big win from a class-based view is not being able to >> store state, you can do that with local variables, it's being able to >>

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

On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote: > Not really.  The big win from a class-based view is not being able to > store state, you can do that with local variables, it's being able to > override parts of the behavior without needing to rewrite the entire > view,

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

On Saturday, October 2, 2010, Vinay Sajip wrote: > > On Oct 1, 4:16 pm, Russell Keith-Magee > wrote: > >> "Don't use instance variables on a class" isn't advice you're going to >> see printed very often. Yet that would be the advice that would be

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

Yeah, I actually read your modification of the trac page after posting this :\ I guess what I'm getting at is the more general issue of maintaining the same interface... is it really that important? If people acknowledge that they are using a different system, then they can adjust their

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

On Saturday, October 2, 2010, David P. Novakovic wrote: > My problem with all of this is that it feels like a hell of a lot of > hoopjumping to deal with something that could be solved in the > Resolver. > > I may be missing something obvious here, so please tell me if I

Re: #12012 Logging: Final call for comments

Definitely agree. Caught the missing nullhandler behavior when logging is off too... though didn't make the connection that this was likely intended to handle that case. It might make more sense to put this logic in conf/__init__.py following the calls to configure the logger. Though that

Re: #12012 Logging: Final call for comments

On Oct 1, 7:06 am, Russell Keith-Magee wrote: > > These are fairly minor modifications, so I'm still intending to commit > early next week, barring major objections. > As per my answer to Kevin - I think a NullHandler addition to the 'django' logger needs to happen

Re: Potential very minor security issue

On Fri, 2010-10-01 at 10:59 -0700, Yo-Yo Ma wrote: > Form wizard docs mention that MD5 hashes are made using > settings.SECRET_KEY - > http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#django.contrib.formtools.wizard.FormWizard.security_hash > > If you give me a value, I

Re: #12012 Logging: Final call for comments

On Oct 1, 10:28 pm, Kevin Howerton wrote: > # Ensure the creation of the Django logger > logger = logging.getLogger('django') > I think the comment is misleading. I agree, there'd be no need to create the logger there as it doesn't seem to be used there. Two points:

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

Sorry in my previous email you could simply pass the uninstantiated class in the url pattern. url(r'...',MyOOView,...) On Sat, Oct 2, 2010 at 8:57 AM, David P. Novakovic wrote: > My problem with all of this is that it feels like a hell of a lot of > hoopjumping to deal

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

My problem with all of this is that it feels like a hell of a lot of hoopjumping to deal with something that could be solved in the Resolver. I may be missing something obvious here, so please tell me if I am.. but couldn't the resolver just check that quacks like something OOViewish has been

Re: Refactoring and file-like interface for HttpRequest

On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev wrote: > During a sprint before 1.2 I was proposing to commit my ticket [9886] that > deals with adding a .read() method to HttpRequest. Adrian suggested that it > was too late then and it's better to bring it up during 1.3

Refactoring and file-like interface for HttpRequest

Hello everyone! During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's better to bring it up during 1.3 cycle. So here it is. Basic summary of changes is in the first

Re: #12012 Logging: Final call for comments

Hey... Discussed with Russell on IRC ... line 21 of log.py... # Ensure the creation of the Django logger logger = logging.getLogger('django') I guess it's trying to check if the logger exists? The getLogger method will actually never fail (as far as I'm aware), as nothing actually happens

contrib.auth tests depending on contrib.admin

Hi All! After installing django and creating a project runing "django-admin.py startproject", if I setup a sqlite3 database and try to run the tests (python manage.py test) it will fail. Seems that contrib.auth tests are missing 2 template files, making it dependent of contrib.admin templates,

Re: Sites Framework: RequestSite and get_current

I can see why you might want control at the middleware level, but I'm not sure that's the only/best way to accomplish that goal, and it seems like the subject of a totally separate ticket to me. I'd rather see this set of redundant problems solved in a simple fashion rather than get into a debate

Re: How to "lobby" for a ticket to be in 1.3?

Sorry, that was phrased badly on my part. I meant to imply that if someone else wrote a patch, he could help by reviewing it... - Gabriel On Oct 1, 11:47 am, Jeremy Dunck wrote: > On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley wrote: > > ... > > > In

Re: How to "lobby" for a ticket to be in 1.3?

On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley wrote: ... > In both cases, once that's done you can either write/help write a > patch that has the desired effect, make sure it has docs and tests, > test it on your own systems/projects, give feedback on the ticket... > if you're

Re: How to "lobby" for a ticket to be in 1.3?

Well, looking at those two tickets, #7028 is currently related to the debate happening on this list ("rethinking raw_id_fields"), so the best thing to do for that ticket is to actively participate in that discussion. For #6903 the ticket is in DDN, which means this is a perfect opportunity for

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

On Oct 1, 4:16 pm, Russell Keith-Magee wrote: > "Don't use instance variables on a class" isn't advice you're going to > see printed very often. Yet that would be the advice that would be > *required* in order to use stateless class-based views in the way you >

Potential very minor security issue

Form wizard docs mention that MD5 hashes are made using settings.SECRET_KEY - http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#django.contrib.formtools.wizard.FormWizard.security_hash If you give me a value, I give you a hash back, and you're aware that I'm using Django

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

Am 01.10.2010 um 18:07 schrieb Luke Plant: > On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote: >> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: >>> I've just added a summary of the last thread on class-based views >> [1]. >>> This summary isn't 100% complete -- any contributions

How to "lobby" for a ticket to be in 1.3?

I see a huge list of tickets that shoud be in 1.3 release: http://code.djangoproject.com/query?status=new=assigned=reopened=1.3 Within them I didn't found some that are, imho, a must for every Django installation I did in the last two years: Better raw_id_fields feedback in newform-admins branc

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

> This would kill the ability to use __init__ to store anything on the > instance, since it would only work for the first request, and so would > enforce subclassing as the only means of customising behaviour. It would > be more effective at dealing with thread safety concerns than a > 'copy()',

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

Or, more drastically, we could just do this: class View(object): def __call__(self, request, *args, **kwargs): self.request = request self.args = args self.kwargs = kwargs resp = self.dispatch(request, *args, **kwargs) self.__dict__ = {} # goodbye

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

> > We document the issue, warn people not to store state on the instance > itself, but tell them that if they must have stateful data, it should be > attached to self.state instead of self, and they will be OK. They might > still be bitten if they put mutable configuration data into the __init__

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

On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote: > Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: > > 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

Re: Error email flooding on high traffic production sites

I feel like something like this would be better suited to be in an external application... since it will fail without a cache-backend. Also, the implementation will have to change as Russell is about to commit a logging patch with ticket #12012. This would be best suited though for a custom

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

On Fri, Oct 1, 2010 at 1:44 AM, Tai Lee wrote: > I'd like to suggest (1) easy to find and use pre-defined searches to > find tickets at each stage of triage, (2) a clearer indication of the > next steps and the person responsible for it whenever a ticket is > reviewed,

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

On 01/10/10 16:25, Brandon Konkle wrote: On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote: Not really. The big win from a class-based view is not being able to store state, you can do that with local variables, it's being able to override parts of the behavior without needing to rewrite the

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

On Fri, Oct 1, 2010 at 11:20 PM, Alex Gaynor wrote: > On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee > wrote: >> On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger >> wrote: >>> Am 01.10.2010 um 07:26 schrieb Russell

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

On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote: > Not really. The big win from a class-based view is not being able to > store state, you can do that with local variables, it's being able to > override parts of the behavior without needing to rewrite the entire > view, or add 101 parameters. If

Re: rethinking raw_id_fields

Edit. Edit. "I just don't think making an absolute answer to that discussion a contingency to this called-for feature /is a good idea/". There we go. On Oct 1, 11:19 am, "subs...@gmail.com" wrote: > Please don't think I'm trying to hinder discussion. I just don't think >

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

On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee wrote: > On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger > wrote: >> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: >>> I've just added a summary of the last thread on class-based views

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

On Fri, Oct 1, 2010 at 9:55 AM, Alex Gaynor wrote: > On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip > wrote: > > It seems better to stress thread-safety dos and don'ts in the > > documentation. > > Without wanting to beat a dead horse, I concur.

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

On Fri, Oct 1, 2010 at 6:17 PM, Luke Plant wrote: > On Fri, 2010-10-01 at 11:12 +0200, Hanne Moa wrote: >> On 1 October 2010 07:26, Russell Keith-Magee wrote: >> > I already have one specific piece of API feedback: the current >> > implementation

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

On Fri, Oct 1, 2010 at 6:42 PM, David Larlet wrote: > > Russell Keith-Magee a écrit : > >>  * Conversion of the github project into a patch on trunk. > > Do you see that as a total replacement of actual views.generic or should we > go for a old/new dance? Unless you're

Re: Proposal: Meta.required_together

Hi. I just filed a feature request on the same or similar issue, and this thread was brought to my attention: http://code.djangoproject.com/ticket/14347 Basically the usecase is this: Very often we have a "Published" field on our models (or "Published date" or "Published status" etc..) It would

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

On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote: > On Oct 1, 11:16 am, Johannes Dollinger > wrote: >> Could you (or anyone knowledgable) add a section, that explains why each >> request should have its own view instance? >> The thread-safety

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

On Oct 1, 11:16 am, Johannes Dollinger wrote: > Could you (or anyone knowledgable) add a section, that explains why each > request should have its own view instance? > The thread-safety argument alone does not suffice: if all _request_ state > would be stored on request

Re: four NoSQL backends you want? :)

On Sep 28, 3:07 am, Thomas Wanschik wrote: > On 28 Sep., 02:45, Russell Keith-Magee > wrote: > We've started a supported/unsupported feature list on > djangopackages:http://www.djangopackages.com/grids/g/cloud/ > > So please help in order to

Re: #12012 Logging: Final call for comments

On Oct 1, 3:45 am, Kevin Howerton wrote: > 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. Yes, it's required so that we can introduce

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

Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: > 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

Re: rethinking raw_id_fields

Hi everyone, Anyway, I'd like to see notes from core devs regarding adding such feature to Admin interface (so please don't say -1 if you think it's just not mature enough!). Or maybe all interested parties should work on some kind of django-admin-extensions instead of improving admin itself.

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

On 01/10/10 11:17, Luke Plant wrote: Passing things around between '_common' and GET and POST makes a simple view much more complex than it needs to be, especially when you have various local variables that you now have to assign in some way. In the end you will end up just routing it all to the

Re: Sites Framework: RequestSite and get_current

On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote: > I went to triage a few tickets tonight, and noticed that #8960, > #10235, #10608 and #13814 have all arrived at essentially the same > conclusion: there needs to be a single idiomatic way to get either the > current Site object if

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

Russell Keith-Magee a écrit : 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

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

On 1 October 2010 07:26, Russell Keith-Magee wrote: > 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

Re: Sites Framework: RequestSite and get_current

I should add that #10909 is another ticket that ultimately revolves around getting a Site/RequestSite object to have access to the current domain. Easily fixed once this function/method exists. While I'm at it, #10944 would be moved one step closer by having a consistent way to get the current

Sites Framework: RequestSite and get_current

I went to triage a few tickets tonight, and noticed that #8960, #10235, #10608 and #13814 have all arrived at essentially the same conclusion: there needs to be a single idiomatic way to get either the current Site object if contrib.sites is installed, or a RequestSite object if not. All four

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

On Sep 30, 7:22 pm, Russell Keith-Magee wrote: > 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. I'd like to suggest (1)

Re: #12012 Logging: Final call for comments

Hi all, Following feedback from Jacob and others in IRC, I've just uploaded an RC2 patch. This patch: * Dramatically simplifies the logging configuration, removing everything that isn't absolutely required. * Adds a note in the project template settings.py telling the user what the default

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

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