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 Site/RequestSite as well. - Gabriel On Sep 30, 11:48 pm, 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 contrib.sites is installed, or a RequestSite > object if not. All four tickets use the same bit of code, the argument > really only lies in where to put it. > > #10235 adds it as a utility function in contrib.sites.models, #13814 > as a separate method on SiteManager, and #8960 and #10608 basically > just copy and paste where needed. I'm of the opinion it should have > its own home in contrib.sites, but where, and under what name? > > If we can agree on where this bit of code should live, I'd be happy to > get all of these tickets fixed in one fell swoop. For reference, #8960 > which has been bumped out of several releases now and is prime 1.3 > material. > > Suggestions? > > All the best, > > - Gabriel -- 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
Hi Tyrion, Multicomplete have no add item button with popup. This is usually the hardest thing to implement with such control, because it's rendered *after* the control. Was it that hard to subclass widgets as Admin*AutocompleteWidget and add required css media from jquery.ui to them? Lots of other features are missing, that can be found in mature implementations: add new item with permission checking ( http://code.google.com/p/django-ajax-selects/ ), field dependencies (http://github.com/digi604/django-smart-selects is the best here), custom querysets & concept of autocomplete channels ( http://code.google.com/p/django-ajax-selects/ or mine http://github.com/buriy/django-extrafields/tree/master/extrafields/autocomplete/ ) , queryset caching & setting autocomplete properties ( http://code.google.com/p/django-autocomplete ). On Fri, Oct 1, 2010 at 5:45 AM, tyrion-mx wrote: > 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. -- 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: Sites Framework: RequestSite and get_current
Hi Gabriel, everyone, I'd also like if such function can support option "developer provides function that knows the current site based on the request". That means, "get my site" function ultimately needs a backend connector! I think this might be fixed in the way we did with urlconf: http://docs.djangoproject.com/en/dev/topics/http/urls/ So it will be taken from request: request.site with default implementation to LazySite, with default implementation of Site.objects.get_current() if sites_installed() or RequestSite(request). That implementation would be overriden with middleware What do you think? On Fri, Oct 1, 2010 at 1:48 PM, 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 contrib.sites is installed, or a RequestSite > object if not. All four tickets use the same bit of code, the argument > really only lies in where to put it. > > #10235 adds it as a utility function in contrib.sites.models, #13814 > as a separate method on SiteManager, and #8960 and #10608 basically > just copy and paste where needed. I'm of the opinion it should have > its own home in contrib.sites, but where, and under what name? > > If we can agree on where this bit of code should live, I'd be happy to > get all of these tickets fixed in one fell swoop. For reference, #8960 > which has been bumped out of several releases now and is prime 1.3 > material. > > Suggestions? > > All the best, > > - Gabriel > > -- > 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. > > -- 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: #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 where GET and POST share a lot of common logic. This! is! Python! Any shared logic can be in another method, or function for that matter, and need not be canonicalized in an API. All that would be needed is an example in the docs: class TheView(views.ClassView): def _common(self, bla): # set up models, forms, other preprocessing here # return models/forms or set them on class # could be run from __init__ or __new__ or whatever we wind up with def GET(self, bla): self._common(bla) def POST(self, bla): self._common(bla) (Indent-dots to make surer that gmail doesn't meddle with the text.) Surely class-based views shouldn't disallow methods not named nor given meaning in an API? Since you needed to explicitly wish for a specific method, that's how it can be interpreted. HM -- 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: #6735 -- Class based generic views: call for comment
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 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. > > This! is! Python! Any shared logic can be in another method, or > function for that matter, and need not be canonicalized in an API. All > that would be needed is an example in the docs: > > class TheView(views.ClassView): > > def _common(self, bla): > # set up models, forms, other preprocessing here > # return models/forms or set them on class > # could be run from __init__ or __new__ or whatever we wind up with > > def GET(self, bla): > self._common(bla) > > def POST(self, bla): > self._common(bla) 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 one method: def GET(self, *args, **kwargs): return self._common(*args, **kwargs) def POST(self, *args, **kwargs): return self._common(*args, **kwargs) This is just 4 lines of annoying boilerplate to undo the dispatching that was 'helpfully' done for you. I would definitely support a 'request' method (perhaps call it 'dispatch'?) that allows us to avoid that logic. I suspect that every view I've created that used a form would be hampered by having dispatch based on HTTP verb done first. 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.
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 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. Thanks for taking that time. 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. I think too but it needs a lot of feedback from the community. 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. Yes, only a start but I'm working on it, any help is really appreciated. * 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? * Feedback on the API, especially the generic view replacements. A first feedback from a fork [1], I think it can be interesting to move the paginate view too. 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. What do you think of [2], is that what you have in mind? I chose dispatch, as Luke suggested, because request can be confusing. Best, David [1] http://github.com/josesoa/django-class-based-views/commit/5f24e25e83f63b44b7049a746713bec0cb16e34a [2] http://github.com/bfirsh/django-class-based-views/commit/20b63340bbf2b6152f88b5ee47865689d9fae3a6 -- 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: #6735 -- Class based generic views: call for comment
Hi Russell,
Few more questions I haven't seen answers yet.
How should urls() work for such views? Should they?
How can self.redirect_to() get current app, namespace and function
name to work if one should use reverse() ?
How should request should be passed for self.render()? Implicitly or explicitly?
You've taken GET/POST dispatch as an example of the new approach, but
I suggest you to use this example (sorry for low-quality draft):
class UserView(View):
templates_prefix = ''
users = User.objects.all()
app_instance = 'users'
list_template = '%slist.html'
edit_template = '%sedit.html'
def template_for(page):
return getattr(self, 'list_' % self.templates_prefix)
@property # as we now have >= python 2.4
def urls(self):
return patterns('',
url(r'^$',
self.list,
name='%s:list'),
url(r'^(.+)/$',
self.edit,
name='%s:edit'),
)
def redirect_to(self, request, page):
#how to get full path to the page from attribute page???
return HttpResponseRedirect(request.build_absolute_uri(request)
+ reverse(self, urlconf=request.urlconf) + reverse(page,
urlconf=self.urls))
def list(self, request):
return self.render(self.template_for('list'), {'users': self.users})
def edit(self, request, id):
if not self.users.filter(id=id).exists():
return self.redirect_to(self.list)
return self.render(self.template_for('edit'), {'user':
self.users.get(id=id)})
class CustomersView(View):
list_template = 'generic_list.html'
edit_template = 'my_edit.html'
users = Users.objects.filter(is_staff=False)
url(r'^detail/users/', CustomersView(), name="users", app_name="users"),
On Fri, Oct 1, 2010 at 12:26 PM, Russell Keith-Magee
wrote:
> 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
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 contrib.sites is installed, or a RequestSite > object if not. All four tickets use the same bit of code, the argument > really only lies in where to put it. > > #10235 adds it as a utility function in contrib.sites.models, #13814 > as a separate method on SiteManager, and #8960 and #10608 basically > just copy and paste where needed. I'm of the opinion it should have > its own home in contrib.sites, but where, and under what name? I think a stand-alone function in contrib.sites.models is fine, called `get_current_site` (or some other sensible colour of your choosing). Since both Site and RequestSite already live there, it seems a good place. Thanks for your work on this, 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.
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 one method: def GET(self, *args, **kwargs): return self._common(*args, **kwargs) def POST(self, *args, **kwargs): return self._common(*args, **kwargs) This is just 4 lines of annoying boilerplate to undo the dispatching that was 'helpfully' done for you. I would definitely support a 'request' method (perhaps call it 'dispatch'?) that allows us to avoid that logic. I suspect that every view I've created that used a form would be hampered by having dispatch based on HTTP verb done first There's nothing stopping Django shipping a base view which just calls a request method, and then another base view which inherits from that and does method-based dispatch - we shouldn't add too many classes, else it'll be a documentation nightmare, but that seems a sensible split. Andrew -- 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
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. Actually, it seems there is still no consensus in the django community of what ideal admin interface should look like. It's very controversial question! I remember django core devs repeatedly said that django.contrib.admin should be simple, and they intends it should be useful only for few use-cases like observing your data, adding at most few initial model instances, editing users and permissions, and being example of how to (not) create reusable django application with UI, and how to create poll application with no use of db explorer like phpmyadmin. Different people tried to say many times that admin instead should be extensible and have all sort of features to be really useful. How do you see django admin in 5 years? This is the question to be asked first of all. Personally, I see django admin completely outside of django project in 5 years, like django debug toolbar and the rest, and I'd say, django core team time should use their time to review and apply patches, fix bugs and add new features to django itself, so admin development should be stopped, admin docs must contain: "admin app is not much useful -- we just don't have enough time to add features into it, and we don't think we should do this -- but it can be used as an example for django beginners of how (not) to do reusable django applications". On Fri, Oct 1, 2010 at 5:45 AM, tyrion-mx wrote: > 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. > > -- 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: #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 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. 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 instead of the view, you wouldn't need new instances per request. You could also pass around state explicitly - which admittedly gets messy quickly. So is this purely about preventing users from shooting themselves in the foot? (hyperbole: Will there be protection from globals in django 1.4?) > 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. I disagree. If you define a class-based view, create an instance (a singleton) and put it in your urlconf, you wouldn't (or shouldn't) expect it to magically reinstantiate itself everytime it's called. So at least the docs will have to point out the magic prominently. Regardless of my resentments, thanks for finally creating an official foundation for class based views. __ Johannes -- 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: #6735 -- Class based generic views: call for comment
I don't think we should worry about documentation nightmares - we could leave most of it undocumented and just expose the bits which look like the current generic views (and a few base views) as the public API. I have added a "how to help" section to the wiki page: http://code.djangoproject.com/wiki/ClassBasedViews Ben On 1 Oct 2010, at 12:25, Andrew Godwin wrote: > 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 one method: >> >> def GET(self, *args, **kwargs): >> return self._common(*args, **kwargs) >> >> def POST(self, *args, **kwargs): >> return self._common(*args, **kwargs) >> >> This is just 4 lines of annoying boilerplate to undo the dispatching >> that was 'helpfully' done for you. >> >> I would definitely support a 'request' method (perhaps call it >> 'dispatch'?) that allows us to avoid that logic. I suspect that every >> view I've created that used a form would be hampered by having dispatch >> based on HTTP verb done first > > There's nothing stopping Django shipping a base view which just calls a > request method, and then another base view which inherits from that and does > method-based dispatch - we shouldn't add too many classes, else it'll be a > documentation nightmare, but that seems a sensible split. > > Andrew > > -- > 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
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 schema changes in future Python versions without breaking backwards compatibility. It's best to leave it in, it's just an extra line after all. Regards, Vinay Sajip -- 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: 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 get closer at least one step towards NoSQL > in Django. NoSQL != cloud, so I changed the name, slug, and description for http://www.djangopackages.com/grids/g/cloud/ It is now: http://www.djangopackages.com/grids/g/nosql/ Perhaps it should even be nosql-backends? Daniel Greenfeld -- 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: #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 instead of the view, you wouldn't need new > instances per request. You could also pass around state explicitly - which > admittedly gets messy quickly. > So is this purely about preventing users from shooting themselves in the > foot? (hyperbole: Will there be protection from globals in django 1.4?) I think Johannes has a point. The copy-on-call may seem useful at first sight, but as it's a shallow copy, it may perhaps engender a false sense of security. So view_instance.attr = x will not result in threads stepping on each other's toes, but view_instance.container_attr.attr = x surely will? It seems better to stress thread-safety dos and don'ts in the documentation. Regards, Vinay Sajip -- 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: #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 argument alone does not suffice: if all _request_ state >> would be stored on request instead of the view, you wouldn't need new >> instances per request. You could also pass around state explicitly - which >> admittedly gets messy quickly. >> So is this purely about preventing users from shooting themselves in the >> foot? (hyperbole: Will there be protection from globals in django 1.4?) > > I think Johannes has a point. The copy-on-call may seem useful at > first sight, but as it's a shallow copy, it may perhaps engender a > false sense of security. So > > view_instance.attr = x > > will not result in threads stepping on each other's toes, but > > view_instance.container_attr.attr = x > > surely will? > > It seems better to stress thread-safety dos and don'ts in the > documentation. > > Regards, > > Vinay Sajip > > -- > 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. > > Without wanting to beat a dead horse, I concur. Fundamentally we need to have a little faith in your users, the admin has the exact same pattern of a single instance, and we haven't done anything special there. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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: 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 be very nice to be able to
allow people to save instances without all the required fields being
filled in IF the article or whathaveyou is not published yet.
My suggestion was to allow the "required" field on the form field to
take a callable instead of a boolean.
In this callable we could check whether some other fields are filled
out or whatever we want.
This would be a very handy feature for a very common problem.
best,
Hejsan
On Sep 27, 7:34 am, Yo-Yo Ma wrote:
> Thanks, David. I've read some about the "Custom validation error on
> unique_together" ticket. I imagine that if people want customization
> there, required_together would need the same. The only idea I have
> that seems to work for both situations is:
>
> required_together = (('weight', 'height', 'You must provide a weight
> and height, if you intend to use either.'),)
>
> unique_together = (('account', 'sku', 'This sku is already in use by
> your company.'),)
>
> On Sep 27, 1:22 am, "David P. Novakovic"
> wrote:
>
>
>
>
>
>
>
> > Is it? I read this as different to anything in the ORM.
>
> > This is about conditionally requiring a second field if one is filled
> > out. Normally it would be done at the JS level.
>
> > I think it's a good idea, assuming I haven't missed something that
> > already does this.
>
> > I can't help thinking this is part of a much larger problem though.
> > That problem is multifield validation. I think we'd have to address
> > that issue first before working on this specific case that is probably
> > the simplest.
>
> > Maybe this has been considered before, but was dropped because the
> > idea is too hard to encapsulate in a simple Meta style option?
>
> > David
>
> > On Mon, Sep 27, 2010 at 5:18 PM, Florian Apolloner
>
> > wrote:
> > > Please post usage questions to the users list. This is already doable
> > > with model validation.
>
> > > Florian
>
> > > --
> > > 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
> > > athttp://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: #6735 -- Class based generic views: call for comment
On Fri, Oct 1, 2010 at 6:46 PM, burc...@gmail.com wrote:
> Hi Russell,
>
> Few more questions I haven't seen answers yet.
>
> How should urls() work for such views? Should they?
Erm... no. A view doesn't have a collection of URLs. A view is a view.
What we're debating here is a way to construct generic views as a
class, rather than as a method with a hideously long argument list.
> How can self.redirect_to() get current app, namespace and function
> name to work if one should use reverse() ?
> How should request should be passed for self.render()? Implicitly or
> explicitly?
>
> You've taken GET/POST dispatch as an example of the new approach, but
> I suggest you to use this example (sorry for low-quality draft):
>
> class UserView(View):
> templates_prefix = ''
> users = User.objects.all()
> app_instance = 'users'
>
> list_template = '%slist.html'
> edit_template = '%sedit.html'
>
> def template_for(page):
> return getattr(self, 'list_' % self.templates_prefix)
>
> �...@property # as we now have >= python 2.4
> def urls(self):
> return patterns('',
> url(r'^$',
> self.list,
> name='%s:list'),
> url(r'^(.+)/$',
> self.edit,
> name='%s:edit'),
> )
>
> def redirect_to(self, request, page):
> #how to get full path to the page from attribute page???
> return HttpResponseRedirect(request.build_absolute_uri(request)
> + reverse(self, urlconf=request.urlconf) + reverse(page,
> urlconf=self.urls))
>
> def list(self, request):
> return self.render(self.template_for('list'), {'users': self.users})
>
> def edit(self, request, id):
> if not self.users.filter(id=id).exists():
> return self.redirect_to(self.list)
> return self.render(self.template_for('edit'), {'user':
> self.users.get(id=id)})
>
> class CustomersView(View):
> list_template = 'generic_list.html'
> edit_template = 'my_edit.html'
> users = Users.objects.filter(is_staff=False)
>
> url(r'^detail/users/', CustomersView(), name="users", app_name="users"),
This isn't a class based view. It's a collection of views, wrapped in
a class. You might be able to call it an app. #6735 isn't about apps -
it's about single views.
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: #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 proposing to maintain backwards compatibility with the old APIs, we can't just remove the old ones. This essentially means an old/new arrangement of some kind is required. I'm not especially hung up on the name, as long as it's simple and memorable. >> * Feedback on the API, especially the generic view replacements. > > A first feedback from a fork [1], I think it can be interesting to move the > paginate view too. Sounds like an interesting idea. >> 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. > > What do you think of [2], is that what you have in mind? I chose dispatch, > as Luke suggested, because request can be confusing. As I said in my response to Luke -- it's not only confusing; it's impossible due tot he clash with self.request. Beyond that, it's a bit of a bikeshed. dispatch(), handle(), or anything else simple and memorable will be fine. 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: #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 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. >> >> This! is! Python! Any shared logic can be in another method, or >> function for that matter, and need not be canonicalized in an API. All >> that would be needed is an example in the docs: >> >> class TheView(views.ClassView): >> >> def _common(self, bla): >> # set up models, forms, other preprocessing here >> # return models/forms or set them on class >> # could be run from __init__ or __new__ or whatever we wind up with >> >> def GET(self, bla): >> self._common(bla) >> >> def POST(self, bla): >> self._common(bla) > > 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 one method: > > def GET(self, *args, **kwargs): > return self._common(*args, **kwargs) > > def POST(self, *args, **kwargs): > return self._common(*args, **kwargs) > > This is just 4 lines of annoying boilerplate to undo the dispatching > that was 'helpfully' done for you. > > I would definitely support a 'request' method (perhaps call it > 'dispatch'?) that allows us to avoid that logic. I suspect that every > view I've created that used a form would be hampered by having dispatch > based on HTTP verb done first. It's been pointed out to me that we can't really call it request() anyway, because it would clash with self.request. dispatch() is as good a name as any; handle() would be my only other suggestion. However, this really is bikeshedding at this point. Whoever paints it gets to pick the name. 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: #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. Fundamentally we need > to have a little faith in your users, the admin has the exact same > pattern of a single instance, and we haven't done anything special > there. > +1 The thread safety issues certainly aren't insignificant, but I think they can be solved by a big fat warning in the documentation. I do prefer this to the potentially false sense of security that copying the object may involve. Tobias -- Tobias McNulty, Managing Partner Caktus Consulting Group, LLC http://www.caktusgroup.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: #6735 -- Class based generic views: call for comment
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 [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. > > 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 instead of the view, you wouldn't need new > instances per request. You could also pass around state explicitly - which > admittedly gets messy quickly. The thread-safety argument is more than enough for me. *If* all requests state was stored on the request, you're correct - there wouldn't be a need for a class-based view to be instantiated per request. However, at that point, you're not really using a class -- you're using a collection of methods that share a sub-module namespace. > So is this purely about preventing users from shooting themselves in the > foot? (hyperbole: Will there be protection from globals in django 1.4?) "Don't use global variables" is advice that is contained in any first-year CS textbook. "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 describe. Objects have state. I don't think it's at all unreasonable to suggest that a instances of a class based view should be able to have state. And even if we documented the fact that they can't have state, I'm willing to *guarantee* that people will *try* to make them stateful. So - we can: * spend a bunch of time writing infrastructure to prevent people from putting stateful variables onto their class-based views * spend a bunch of time answering the same question over and over again on django-users * pick an infrastructure that lets people use classes the way they expect. >> 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. > > I disagree. If you define a class-based view, create an instance (a > singleton) and put it in your urlconf, you wouldn't (or shouldn't) expect it > to magically reinstantiate itself everytime it's called. So at least the docs > will have to point out the magic prominently. You say "magic", I say an unusual, but otherwise elegant solution for hiding an annoying implementation detail. As an end user, you don't have to care about the fact that it's "magically" instantiated every time it is used. It just behaves like a class instance, and is thread safe without you having to think about it. 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
I know I'm not a core dev but I do have two cents. I'm not really in favor of overthinking this too much--I think a satisfactory replacement for raw_id_fields is good enough (adequately encompasses all the features). I know there are a lot of mature projects out there when it comes to AjaxFields and I don't think its up to django.contrib.admin to compete with them--they are there to use and can easily be integrated into admin for those who require advanced features. As for the big picture of admin in 5 years, its certainly a good question but I'm not sure that its 'the question to be asked first of all'. Overthinking like this stalls tickets, sometimes indefinitely. Please don't think I'm trying to hinder discussion. I just don't think making an absolute answer to that discussion a contingency of this called-for feature. -Steve On Oct 1, 3:42 am, "burc...@gmail.com" wrote: > 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. > > Actually, it seems there is still no consensus in the django community > of what ideal admin interface should look like. > It's very controversial question! > I remember django core devs repeatedly said that django.contrib.admin > should be simple, and they intends it should be useful only for few > use-cases like observing your data, adding at most few initial model > instances, editing users and permissions, and being example of how to > (not) create reusable django application with UI, and how to create > poll application with no use of db explorer like phpmyadmin. > > Different people tried to say many times that admin instead should be > extensible and have all sort of features to be really useful. > > How do you see django admin in 5 years? This is the question to be > asked first of all. > > Personally, I see django admin completely outside of django project in > 5 years, like django debug toolbar and the rest, and I'd say, django > core team time should use their time to review and apply patches, fix > bugs and add new features to django itself, so admin development > should be stopped, admin docs must contain: "admin app is not much > useful -- we just don't have enough time to add features into it, and > we don't think we should do this -- but it can be used as an example > for django beginners of how (not) to do reusable django applications". > > > > > > On Fri, Oct 1, 2010 at 5:45 AM, tyrion-mx wrote: > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. > > -- > 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: #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 [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. >> >> 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 instead of the view, you wouldn't need new >> instances per request. You could also pass around state explicitly - which >> admittedly gets messy quickly. > > The thread-safety argument is more than enough for me. > > *If* all requests state was stored on the request, you're correct - > there wouldn't be a need for a class-based view to be instantiated per > request. However, at that point, you're not really using a class -- > you're using a collection of methods that share a sub-module > namespace. > 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. >> So is this purely about preventing users from shooting themselves in the >> foot? (hyperbole: Will there be protection from globals in django 1.4?) > > "Don't use global variables" is advice that is contained in any > first-year CS textbook. > > "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 > describe. > > Objects have state. I don't think it's at all unreasonable to suggest > that a instances of a class based view should be able to have state. > And even if we documented the fact that they can't have state, I'm > willing to *guarantee* that people will *try* to make them stateful. > > So - we can: > * spend a bunch of time writing infrastructure to prevent people from > putting stateful variables onto their class-based views > * spend a bunch of time answering the same question over and over > again on django-users > * pick an infrastructure that lets people use classes the way they expect. > We don't have that documentation for the admin. Either we need it, or our users are a little bit smarter than we're giving them credit. >>> 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. >> >> I disagree. If you define a class-based view, create an instance (a >> singleton) and put it in your urlconf, you wouldn't (or shouldn't) expect it >> to magically reinstantiate itself everytime it's called. So at least the >> docs will have to point out the magic prominently. > > You say "magic", I say an unusual, but otherwise elegant solution for > hiding an annoying implementation detail. > > As an end user, you don't have to care about the fact that it's > "magically" instantiated every time it is used. It just behaves like a > class instance, and is thread safe without you having to think about > it. > > 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. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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
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 > making an absolute answer to that discussion a contingency of this > called-for feature. -- 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: #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 you're storing state with local variables, though, don't you end up having to pass 101 parameters around to your methods? -Brandon -- 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: #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 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 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. >>> >>> 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 instead of the view, you wouldn't need new >>> instances per request. You could also pass around state explicitly - which >>> admittedly gets messy quickly. >> >> The thread-safety argument is more than enough for me. >> >> *If* all requests state was stored on the request, you're correct - >> there wouldn't be a need for a class-based view to be instantiated per >> request. However, at that point, you're not really using a class -- >> you're using a collection of methods that share a sub-module >> namespace. >> > > 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. I'm in agreement that this is the gain from class-based views. However, as soon as you show someone an instance of a class, they're going to look for the instance attributes -- that's just how classes work everywhere else in the world. Unless you can propose a mechanism for physically preventing people from assigning instance attributes to the class, I simply don't buy that documentation saying "don't do that" will be sufficient to avoid confusion. >>> So is this purely about preventing users from shooting themselves in the >>> foot? (hyperbole: Will there be protection from globals in django 1.4?) >> >> "Don't use global variables" is advice that is contained in any >> first-year CS textbook. >> >> "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 >> describe. >> >> Objects have state. I don't think it's at all unreasonable to suggest >> that a instances of a class based view should be able to have state. >> And even if we documented the fact that they can't have state, I'm >> willing to *guarantee* that people will *try* to make them stateful. >> >> So - we can: >> * spend a bunch of time writing infrastructure to prevent people from >> putting stateful variables onto their class-based views >> * spend a bunch of time answering the same question over and over >> again on django-users >> * pick an infrastructure that lets people use classes the way they expect. >> > > We don't have that documentation for the admin. Either we need it, or > our users are a little bit smarter than we're giving them credit. Or a third option -- the use case for the admin is different. ModelAdmin is a pret-a-porter interface to a high level piece of functionality with a couple of clearly documented extension points. The API that ModelAdmin exposes doesn't provide any encouragement to store state on the ModelAdmin instance itself. The fact that ModelAdmin isn't thread safe in that way isn't documented, because it's simply never been an issue -- the interface it provides doesn't encourage you to do things that would cause the thread non-safety to be exposed. This contrasts directly with Class-based views: a low-level view construction kit. Although the interface for the generic class-based views will be well defined in the same way as the admin, the base View class isn't. Best practice may well be to avoid state variables, but I don't think any amount of documentation will stop people from using 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: #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 entire view, or add 101 parameters. If you're storing state with local variables, though, don't you end up having to pass 101 parameters around to your methods? -Brandon This is a very good point - one of the reasons it's nice to have self.request is so you don't end up with ridiculous method signatures. It's also a lot easier to write inflexible methods if you don't have state on self - if I'm in, say, get_form(), and I want to change the form I have based on the arguments in the URL (or anything elsewhere in the class), I can't do that unless someone thought to pass those variables in initially in the method signature. Andrew -- 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
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, and (3) tickets that have been sitting on DDN for a while be > put to a vote. This is completely right-on; I agree entirely. Some work has already been done in these areas: For (1) check out http://code.djangoproject.com/wiki/Reports (it's linked in the nav). If there's anything missing there, please feel free to add it -- it's a wiki page. Let me know if you need help figuring out the linked query syntax. Work on (2) began at some point over at http://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough still, but once it gets better I'd love to link sections from the ticket page and/or move it into the docs directly. Ideally, I'd like each ticket page to have a "what's next?" box on it indicating where the ticket is and how to move it along. Technically this isn't hard -- we've got plenty of folks in our community who could write a Trac plugin -- but getting the language right is important. If we get that worked out to some extent I'll figure out what the next steps are technically. For (3), well, feel free to bring things up here or on IRC, I s'pose. I'd really appreciate it if we didn't get 'em all brought up at once, of course. But yes, if there are tickets marked DDN that you feel are critical, please feel free to ask for a yay/nay. Hope this gives you and/or others who want to help improve process a place to channel that desire! 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: 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 handler in an external app going forward... I will likely add something of this nature to one of lumberjack's backends (aggregation of some-sort). -k On Thu, Sep 30, 2010 at 6:47 AM, Andrew Wilkinson wrote: > 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. > > -- 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: #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 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. > > 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 instead of the view, you wouldn't > need new instances per request. You could also pass around state > explicitly - which admittedly gets messy quickly. > So is this purely about preventing users from shooting themselves in > the foot? (hyperbole: Will there be protection from globals in django > 1.4?) It's not just about stopping users from shooting themselves in the foot, it's about helping them to do the right thing easily. Without this kind of protection, it will be harder for *anyone*, including experienced developers who are aware of the problem, to do things correctly. It's like the autoescaping in templates - I *know* that I should use the 'escape' filter, but without autoescaping it is hard for anyone to do it right all the time. One alternative that has been suggested is to pass state around explicitly, which is definitely best practice, but in many cases might not be possible (e.g. if you are working with someone else's base class, and in one overridden method you want to set up some objects which ought to be available to other methods). You could also attach stateful data to the request object, but attaching random bits of data to the request is surely just as ugly a solution as the self.copy() call, especially if you need to avoid names clashes with all the other attributes attached to request. With regards to doing a shallow copy, it should be noted that at the point the copy is made, the only data attached to the object is data that has been attached in the constructor. It is of course possible that methods within the view might mutate such data, but it seems more likely that it will be used as immutable configuration data. However, I have already seen some example code that might fall foul of this problem - someone gave the example of storing a queryset on the object in the __init__. This will get implicitly mutated (the cache is filled) when it is used the first time. This could lead to frustrating problems that wouldn't be found in testing, and doing copy() on the instance won't help. So, in light of the fact that developers *will* need to be aware of this issue, I'd like to tentatively suggest an explicit solution which is nonetheless easy to use and get right. We could have an explicit 'state' object that is thrown away for every new request, something like this: class State(object): pass class View(object): def __call__(self, request, *args, **kwargs): """ Main entry point for a request-response process. """ self.state = State() self.request = request self.args = args self.kwargs = kwargs resp = self.dispatch(request, *args, **kwargs) # let any state get GC'd immediately: del self.state del self.request del self.args del self.kwargs return resp 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__ and it gets mutated, but we have made it easy to do the right thing - doing 'self.state.x' is only slightly harder than 'self.x' Thoughts? 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.
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__ > and it gets mutated, but we have made it easy to do the right thing - > doing 'self.state.x' is only slightly harder than 'self.x' > > Thoughts? I'm not very convinced about this but I'll just throw it out there, how about keeping the same state object in each request instance (assigned at the base __call__ implementation) and overriding getattr and setattr to work with the state object in request (getattr would fallback to regular attributes set during the constructor when no request was present)? Although this would require using threadlocals to access the right request object from getattr and setattr. -- 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: #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 state!
return resp
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()', but breaking __init__() like that is fairly evil. I'm not sure
if this is a serious suggestion or not...
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.
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()', but breaking __init__() like that is fairly evil. I'm not sure > if this is a serious suggestion or not... if you remove the ability to set state in the constructor and rely only in subclassing use __new__ instead of copy and all the thread safety problems are solved. Perhaps we could do something like that and provide a @classmethod in View that easily subclasses a View with some default state, for example: views.py MyView(View): ... urls.py -- url(r'^myview$', myapp.views.MyView, name='myview'), url(r'^myview$', myapp.views.MyView.with_defaults(somevar=somevalue), name='myview'), -- 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.
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&status=assigned&status=reopened&milestone=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 http://code.djangoproject.com/ticket/7028 Go back to old change_list view after hitting save http://code.djangoproject.com/ticket/6903 At each new django release it's a pita to adapt these patches. How can I help to make these two tickets in the 1.3 milestone? Ciao. Marco. -- 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: #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 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. >> >> 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 instead of the view, you wouldn't >> need new instances per request. You could also pass around state >> explicitly - which admittedly gets messy quickly. >> So is this purely about preventing users from shooting themselves in >> the foot? (hyperbole: Will there be protection from globals in django >> 1.4?) > > It's not just about stopping users from shooting themselves in the foot, > it's about helping them to do the right thing easily. Without this kind > of protection, it will be harder for *anyone*, including experienced > developers who are aware of the problem, to do things correctly. It's > like the autoescaping in templates - I *know* that I should use the > 'escape' filter, but without autoescaping it is hard for anyone to do it > right all the time. > > One alternative that has been suggested is to pass state around > explicitly, which is definitely best practice, but in many cases might > not be possible (e.g. if you are working with someone else's base class, > and in one overridden method you want to set up some objects which ought > to be available to other methods). You could also attach stateful data > to the request object, but attaching random bits of data to the request > is surely just as ugly a solution as the self.copy() call, especially if > you need to avoid names clashes with all the other attributes attached > to request. > > With regards to doing a shallow copy, it should be noted that at the > point the copy is made, the only data attached to the object is data > that has been attached in the constructor. It is of course possible that > methods within the view might mutate such data, but it seems more likely > that it will be used as immutable configuration data. > > However, I have already seen some example code that might fall foul of > this problem - someone gave the example of storing a queryset on the > object in the __init__. This will get implicitly mutated (the cache is > filled) when it is used the first time. This could lead to frustrating > problems that wouldn't be found in testing, and doing copy() on the > instance won't help. > > So, in light of the fact that developers *will* need to be aware of this > issue, I'd like to tentatively suggest an explicit solution which is > nonetheless easy to use and get right. We could have an explicit 'state' > object that is thrown away for every new request, something like this: > > class State(object): >pass > > class View(object): >def __call__(self, request, *args, **kwargs): >""" >Main entry point for a request-response process. >""" >self.state = State() >self.request = request >self.args = args >self.kwargs = kwargs >resp = self.dispatch(request, *args, **kwargs) ># let any state get GC'd immediately: >del self.state >del self.request >del self.args >del self.kwargs >return resp > > 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__ > and it gets mutated, but we have made it easy to do the right thing - > doing 'self.state.x' is only slightly harder than 'self.x' > > Thoughts? If you are willing to limit view state to a dedicated container, you might as well put in on request (e.g. request.view, request.state, request.context, ...) - and store args/kwargs in it as well. There would be no need to copy or clear self. It could be added automatically for all views (even those that are plain functions). However, I am -0 on the self.copy() proposal. While I believe it's the wrong design decision, I'd be happy with any decision at this point. __ Johannes -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to
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 (think BitBucket which everyone knows is using Django), couldn't I use those values to learn your secret key. I understand this would be difficult and time consuming to try to accomplish, and I apologize if I'm raising unwarranted alarms, but I thought it was worth mentioning. Also, why MD5? I thought Django was switching to SHA1 for security reasons. -- 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: #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 > describe. > > Objects have state. I don't think it's at all unreasonable to suggest > that a instances of a class based view should be able to have state. > And even if we documented the fact that they can't have state, I'm > willing to *guarantee* that people will *try* to make them stateful. > To perhaps complicate the issue a little further, I think there's a distinction between read-only state and mutable state. It seems reasonable to let view class instances have read-only state (this might be part and parcel of increased [re]usability) such as template names, output mimetype configuration etc. This would be quite safe, ISTM. For mutable state during request processing, I'd vote for sticking it all in the request. Then your method signatures need only include the request - not unreasonable - and if for some reason you couldn't do that, there's always thread locals for the requests (duck ;-)) Regards, Vinay Sajip -- 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: 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 the core devs to use their new procedural rules.
Basically, you'd be best served by starting a thread particularly for
that ticket here, or hopping on IRC, and politely gathering a
consensus for a particular solution.
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 certain it meets all the criteria at that point you could
even mark it as RFC.
Once a ticket is RFC, a core committer will eventually look at it.
Especially since both of those are old tickets I'd imagine they'll get
attention for 1.3 and won't get bumped again as long as there are good
patches.
Hope that helps,
- Gabriel
On Oct 1, 10:28 am, Marcob wrote:
> I see a huge list of tickets that shoud be in 1.3
> release:http://code.djangoproject.com/query?status=new&status=assigned&status...
>
> 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
> branchttp://code.djangoproject.com/ticket/7028
>
> Go back to old change_list view after hitting
> savehttp://code.djangoproject.com/ticket/6903
>
> At each new django release it's a pita to adapt these patches.
>
> How can I help to make these two tickets in the 1.3 milestone?
>
> Ciao.
> Marco.
--
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: 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 certain it meets all the criteria at that point you could > even mark it as RFC. All correct, except that it's bad form for a person that writes a patch to mark that patch RFC. Get someone else to review it and mark RFC. Even frequent committers generally have others review their work and mark RFC. -- 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: 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 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 certain it meets all the criteria at that point you could > > even mark it as RFC. > > All correct, except that it's bad form for a person that writes a > patch to mark that patch RFC. Get someone else to review it and mark > RFC. Even frequent committers generally have others review their work > and mark RFC. -- 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: 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 over implementing a different feature... just my two cents, - Gabriel On Oct 1, 1:13 am, "burc...@gmail.com" wrote: > Hi Gabriel, everyone, > > I'd also like if such function can support option "developer provides > function that knows the current site based on the request". > That means, "get my site" function ultimately needs a backend connector! > > I think this might be fixed in the way we did with > urlconf:http://docs.djangoproject.com/en/dev/topics/http/urls/ > > So it will be taken from request: > request.site with default implementation to LazySite, with default > implementation of Site.objects.get_current() if sites_installed() or > RequestSite(request). > > That implementation would be overriden with middleware > > What do you think? > > > > > > On Fri, Oct 1, 2010 at 1:48 PM, 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 contrib.sites is installed, or a RequestSite > > object if not. All four tickets use the same bit of code, the argument > > really only lies in where to put it. > > > #10235 adds it as a utility function in contrib.sites.models, #13814 > > as a separate method on SiteManager, and #8960 and #10608 basically > > just copy and paste where needed. I'm of the opinion it should have > > its own home in contrib.sites, but where, and under what name? > > > If we can agree on where this bit of code should live, I'd be happy to > > get all of these tickets fixed in one fell swoop. For reference, #8960 > > which has been bumped out of several releases now and is prime 1.3 > > material. > > > Suggestions? > > > All the best, > > > - Gabriel > > > -- > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. > > -- > 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.
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, however, the admin app isn't installed by default on the generated settings.py. If I uncomment the contrib.admin line on the generated settings the tests will work properly. It happens on both v1.2.3 and trunk. I solved it simply creating the missing template files inside contrib.auth tests. The patch is available at http://code.djangoproject.com/ticket/14374 Even it being a simple error, I feel it's an important issue to solve, so new django users won't get wrong feedback when starting a new project. All the best, -- Henrique Bastos henri...@bastos.net http://henriquebastos.net Skype: henriquebastos.net +55 21 9618-6180 -- 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
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 until you try to push a message to the handler(s) of
that logger... and at that point you will get a warning if the logger
doesn't have handlers associated with it.
I came up with this to check if a logger exists and has been setup,
you can test for the existence of handlers... ie:
logger = logging.getLogger('adsf')
if not logger.handlers:
dictConfig(settings.LOGGING)
I feel like that check is unnecessary anyhow... but I guess that's how
you'd do it if it is necessary.
-k
On Fri, Oct 1, 2010 at 8:54 AM, Vinay Sajip wrote:
> 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 schema changes in future
> Python versions without breaking backwards compatibility. It's best to
> leave it in, it's just an extra line after all.
>
> Regards,
>
> Vinay Sajip
>
> --
> 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.
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 comment[1]. The patch is just updated to current trunk. Thanks for your attention! [9886]: http://code.djangoproject.com/ticket/9886 [1]: http://code.djangoproject.com/ticket/9886#comment:1 -- 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: 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 cycle. So here > it is. Looks good to me - I moved it along. Thanks! 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: #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 passed in and simply branch and init the class before calling the view in the same way it normally would? pseudo code follows: obj = None func = None if hasattr(view,something_an_ooview_has): #general ooview instance checking obj = view() func = view.dispatch else: func = view response = func(...) return response D On Sat, Oct 2, 2010 at 4:14 AM, 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 >> *required* in order to use stateless class-based views in the way you >> describe. >> >> Objects have state. I don't think it's at all unreasonable to suggest >> that a instances of a class based view should be able to have state. >> And even if we documented the fact that they can't have state, I'm >> willing to *guarantee* that people will *try* to make them stateful. >> > > To perhaps complicate the issue a little further, I think there's a > distinction between read-only state and mutable state. It seems > reasonable to let view class instances have read-only state (this > might be part and parcel of increased [re]usability) such as template > names, output mimetype configuration etc. This would be quite safe, > ISTM. > > For mutable state during request processing, I'd vote for sticking it > all in the request. Then your method signatures need only include the > request - not unreasonable - and if for some reason you couldn't do > that, there's always thread locals for the requests (duck ;-)) > > Regards, > > Vinay Sajip > > -- > 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: #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 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 passed in and simply branch and init the class > before calling the view in the same way it normally would? > > pseudo code follows: > > obj = None > func = None > if hasattr(view,something_an_ooview_has): #general ooview instance checking > obj = view() > func = view.dispatch > else: > func = view > > response = func(...) > return response > > > D > > On Sat, Oct 2, 2010 at 4:14 AM, 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 >>> *required* in order to use stateless class-based views in the way you >>> describe. >>> >>> Objects have state. I don't think it's at all unreasonable to suggest >>> that a instances of a class based view should be able to have state. >>> And even if we documented the fact that they can't have state, I'm >>> willing to *guarantee* that people will *try* to make them stateful. >>> >> >> To perhaps complicate the issue a little further, I think there's a >> distinction between read-only state and mutable state. It seems >> reasonable to let view class instances have read-only state (this >> might be part and parcel of increased [re]usability) such as template >> names, output mimetype configuration etc. This would be quite safe, >> ISTM. >> >> For mutable state during request processing, I'd vote for sticking it >> all in the request. Then your method signatures need only include the >> request - not unreasonable - and if for some reason you couldn't do >> that, there's always thread locals for the requests (duck ;-)) >> >> Regards, >> >> Vinay Sajip >> >> -- >> 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: Sites Framework: RequestSite and get_current
On Fri, 2010-10-01 at 12:08 -0700, Gabriel Hurley wrote: > 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 over implementing a different feature... Absolutely right, go ahead with your patch. If someone really cares about the other feature (which seems a bit obscure to me), then they will do the normal things required. Thanks, Luke -- "DO NOT DISTURB. I'm disturbed enough already." 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.
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:
1. Library code should add a NullHandler instance to the top-level
logger so that in the absence of any other configuration, you don't
get spurious "No handlers found ..." message. This should be just
after the logger = logging.getLogger('django') line:
logger.addHandler(NullHandler())
This line should always be there, and the NullHandler should be
omitted from the example configurations. Essentially, it's implicitly
there in addition to the handlers configured in settings.py. If this
is not done and the user turns off configuration via LOGGING_CONFIG =
None but omits to add any other configuration, you would get that "No
handlers found ..." message.
2. Library code should generally never add handlers (other than
NullHandler) unless it's under the application (site) developer's
control. That's happening in this case because of the convention with
LOGGING_CONFIG: the site developer is effectively telling Django to
add those handlers, albeit in a declarative way.
Hope that's clear!
Regards,
Vinay Sajip
--
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: 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 give you a hash back, and you're aware that > I'm using Django (think BitBucket which everyone knows is using > Django), couldn't I use those values to learn your secret key. I > understand this would be difficult and time consuming to try to > accomplish, and I apologize if I'm raising unwarranted alarms, but I > thought it was worth mentioning. Um, in theory, yes, *all* cryptographic measures can be broken given some information and enough time. You somehow missed the part where you explained what kind of attack you would do, and showed roughly how long it would take to do this brute force attack, given the typical secret keys that a Django 'startproject' command generates, and why we should therefore be worried. (BTW, if you actually do this, and you discover there is a problem, the right place to report it is secur...@djangoproject.com, not here). > Also, why MD5? I thought Django was switching to SHA1 for security > reasons. If we switch we will break compatibility with existing hashes. We'd like to switch to HMAC-SHA1 (it's on my TODO list actually), but only if we can do so without causing lots of breakage. Luke -- "DO NOT DISTURB. I'm disturbed enough already." 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.
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 internally (not under a site developer's control) and the 'null' handler should be removed from the examples (as it won't be needed any more). That should make the configuration dictionary even simpler :-) Regards, Vinay Sajip -- 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
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 doesn't
really matter as the handler could only be added once anyhow.
ie:
logger = logging.getLogger('django')
if not logger.handlers:
logger.addHandler(NullHandler())
Also didn't realize that adding a nullhandler to just the root logger
would remove those warnings (pretty cool)... ended up writing a bit
that adds a nullhandler to any logger without handlers for my
implementation in lumberjack... woops.
-k
On Fri, Oct 1, 2010 at 8:35 PM, Vinay Sajip wrote:
>
>
> 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 internally (not under a site
> developer's control) and the 'null' handler should be removed from the
> examples (as it won't be needed any more). That should make the
> configuration dictionary even simpler :-)
>
> Regards,
>
> Vinay Sajip
>
> --
> 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: #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 am.. > but couldn't the resolver just check that quacks like something > OOViewish has been passed in and simply branch and init the class > before calling the view in the same way it normally would? > > pseudo code follows: > > obj = None > func = None > if hasattr(view,something_an_ooview_has): #general ooview instance checking > obj = view() > func = view.dispatch > else: > func = view > > response = func(...) > return response > Sure. Now decorate the view. Decorating views in the urlconf is a very common and useful pattern, but it's a pattern that is pretty much impossible using the approach you describe. 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: #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 expectations accordingly. For example, this specific case of a decorator could be changed slightly so that the decorator is passed as a parameter to the url conf, or something like that. If the goal here is to be completely unsurprising and fit something into the existing system then I'll let the thread get back on topic :) I was just considering the possibility of actually providing another option which is a bit more of a radical change, but also doesn't involve some quicky ... tweaks.. On Sat, Oct 2, 2010 at 11:14 AM, Russell Keith-Magee wrote: > 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 am.. >> but couldn't the resolver just check that quacks like something >> OOViewish has been passed in and simply branch and init the class >> before calling the view in the same way it normally would? >> >> pseudo code follows: >> >> obj = None >> func = None >> if hasattr(view,something_an_ooview_has): #general ooview instance checking >> obj = view() >> func = view.dispatch >> else: >> func = view >> >> response = func(...) >> return response >> > > Sure. Now decorate the view. > > Decorating views in the urlconf is a very common and useful pattern, > but it's a pattern that is pretty much impossible using the approach > you describe. > > 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: #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 >> *required* in order to use stateless class-based views in the way you >> describe. >> >> Objects have state. I don't think it's at all unreasonable to suggest >> that a instances of a class based view should be able to have state. >> And even if we documented the fact that they can't have state, I'm >> willing to *guarantee* that people will *try* to make them stateful. >> > > To perhaps complicate the issue a little further, I think there's a > distinction between read-only state and mutable state. It seems > reasonable to let view class instances have read-only state (this > might be part and parcel of increased [re]usability) such as template > names, output mimetype configuration etc. This would be quite safe, > ISTM. Sure. Now try and explain what constitutes "mutable state" in a way that makes sense to new Python converts. I don't see how you can get into that sort of discussion without getting into deep copying, object referencing, etc. > For mutable state during request processing, I'd vote for sticking it > all in the request. Then your method signatures need only include the > request - not unreasonable - and if for some reason you couldn't do > that, there's always thread locals for the requests (duck ;-)) We need to make the distinction here between "ideas that see almost certainly good ideas/potential best practice" and "things that people will do because they will expect to be able to do them". I cant deny that assigning state to the request is one way to avoid these problems, but it doesn't change the fact that when presented with a class, people will expect that self.foo will work. To make matters worse, self.foo *will* work... in the single threaded devserver. Then you go to production, and everything starts breaking unpredictably because you have a multithreaded environment. To make it perfectly clear - any solution that proposes to avoid this issue purelt with documentation is a non-starter IMHO. I don't care how well written the description is; not being able to assign to self is a fundamental change from the expectation of how a class behaves in every other Python context, and it doesn't take much of a crystal ball to predict that it will rapidly become a FAQ on django-users. When we can reasonably predict that something is going to become a support nightmare, that's the first sign that we need to run the other way. 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: * when it fails, it will fail during development, not just in production * the cases where it will fail isn't the default usage case; it's only going to be an issue when you have a deep data structure that you are using in a mutable way. * the cases where it is even *potentially* a problem are an edge case of common usage. This is only an issue with the arguments passed to the constuctor of the class-based view. One of the reasons for moving to class based views is to get away from the monster list of arguments required by method based generic views in favor of subclassing. By virtue of the technique we're introducing, we're limiting the number of people that will be affected by this issue. I'm a lot more comfortable with the idea of documenting "don't use complex data structures as class arguments" than I am about documenting "don't use self on a class". If nothing else, the reasoning of "a copy is involved, so make __init__ arguments cheap to copy" will give some protection. 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: #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, or add 101 parameters. Agreed. There is already an object to store state per request. It's the request object. It's there for a reason. Adding data to the class instance would be like adding data to the view function (like view_function.data = "spam"). No one would agree that's a good idea. > We don't have that documentation for the admin. Either we need it, or > our users are a little bit smarter than we're giving them credit. Playing devil's advocate, the admin may not be accessed as much as the main site, so bugs involving concurrent access may not crop up as much or be prioritized lower depending on the organization creating the website. -- Ian http://www.ianlewis.org/ -- 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: #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 >> override parts of the behavior without needing to rewrite the entire >> view, or add 101 parameters. > > Agreed. There is already an object to store state per request. It's > the request object. It's there for a reason. Adding data to the > class instance would be like adding data to the view function (like > view_function.data = "spam"). No one would agree that's a good idea. > 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 sense to me at all. It reminds me of the "Feature Envy" code smell.. D -- 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: #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 > sense to me at all. It reminds me of the "Feature Envy" code smell.. I'm not sure I understand your comment. Are you complaining about having to pass the request object around? I think having a helper view add or modify data on the request object is more than reasonable. Please also explain to me what you are meaning by "Feature Envy". class ViewClass(...): ... def helper_method(self, request): request.somedata = "data" ... I think there might be a nicer way to do this like adding a state dictionary to the request so that there was a place to put request state that's not directly on the request, but that feels like bikeshedding at this point, if I used the term correctly. As Alex has said earlier, this is the way the Admin has always worked and it works ok IMHO so it makes sense to do something similar with non-admin class based views. -- Ian http://www.ianlewis.org/ -- 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: #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 > > * the cases where it will fail isn't the default usage case; it's > only going to be an issue when you have a deep data structure that you > are using in a mutable way. > > * the cases where it is even *potentially* a problem are an edge > case of common usage. None of these points seem accurate to me. The common failure mode for copy-on-call is someone setting self.foo to anything mutable (a list, dict, or object instance) in their __init__ method, and then later mutating it during the course of the view. Initializing state in __init__ to be modified by other methods is not an edge case, it's a common pattern of class usage in Python, almost as common as instance state itself. Likewise, mutable data structures (lists, dicts, objects) are not an edge case, but common Python idiom. And this failure will not fail quickly in development. It will work just fine in development, but will not be thread-safe, and will fail only under threaded concurrent load. > I'm a lot more comfortable with the idea of documenting "don't use > complex data structures as class arguments" than I am about > documenting "don't use self on a class". If nothing else, the > reasoning of "a copy is involved, so make __init__ arguments cheap to > copy" will give some protection. > Sure. Now try and explain what constitutes "mutable state" in a way > that makes sense to new Python converts. I don't see how you can get > into that sort of discussion without getting into deep copying, object > referencing, etc. I don't understand how these two paragraphs are internally consistent. I agree that explaining the intricacies of mutable vs immutable objects to beginners is impractical. So how then is it reasonable to document "you can set instance attributes in __init__ as long as they are immutable," which is what would have to be documented in the copy- on-call case? ISTM that of the thus-far proposed options for "preventing" un-thread- safe use of class-based views without changing the view contract, the only one that will fail fast in development is the proposal to make setting state on self raise an error or warning. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
