Re: Overhaul extra_requires to include more optional dependencies
Op 11-12-17 om 11:26 schreef jr...@leukeleu.nl: Django has a number of optional features that require the installation of additional Python packages. > > ... snip ... I've created a pull request adding the optional dependencies found in the test requirements: https://github.com/django/django/pull/9440 / https://code.djangoproject.com/ticket/28905 So end users can do things like: $ pip install Django[mysql,sqlparse,images,memcached] $ pip install Django[postgresql,gis] $ pip install Django[selenium,test-parallel] Good idea! I have two comments: First, in the ticket, I see psycopg2 as requirement for the "postgresql" extra. Fine. That's totally required. For the "gis" extra it is numpy and geoip2. Numpy isn't strictly required: according to the readme it is 'highly recommended'. => What is the meaning of such an 'extra'? Does it contain 'highly recommended' and higher? Or also optional packages? You *do* mention 'optional' in the ticket. So if I do 'Django[gis]' I ought to get every package that's mentioned as "hey, that's handy" in the documentation, right? Second, I wonder whether the one-item extras are really needed. If you want to use numpy, you'll install numpy yourself. You don't really need 'Django[numpy]' to tell you to install numpy. admindocs->docutils: yes, that's handy numpy->numpy: seems less useful gis->numpy and geoip2: yes, useful Reinout -- Reinout van Rees http://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity" -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/p25ncd%24pj2%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: change commit message format to present tense?
Op 26-06-16 om 05:31 schreef Kevin Christopher Henry: If anyone's put off by the hectoring tone of the imperative mood, it might be better to think of it as the indicative mood. That is: (This will) "add password validation to prevent the usage of...". rather than (You must) "add password validation to prevent the usage of..."! "It might be better to think of it as...": it is exactly this extra thinkwork that everyone reading the messages has to do. We write it once and read it many times: what should we optimize for? In our source code, the answer is clearly that you should optimize for readability. Why is it suddenly different for commit messages? Git will probably be replaced by an even better tool in 5 years' time (just like svn before that and cvs before): will we go back to the original proper English then? In English they're usually expressed the same way, but not so in other languages. Anecdotally, I saw someone comment that in Portuguese the two are different and that the indicative, but not the imperative, would make sense for a commit message. Reinout, I'm curious if that distinction would make a difference in your native language? In Dutch, the imperative and indicative are different. But that would be better solved by using the indicative also in English, right? - "Adds password validation to prevent..." The changelog will now look just like installation instructions: - Install django using `pip install django`. - Add a database. - Run `python manage.py ` Reinout -- Reinout van Rees http://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity" -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/nkqsr9%24oh2%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: change commit message format to present tense?
Op 24-06-16 om 19:48 schreef Carl Meyer: To be clear, the recommended git style is not present tense, it is imperative mood. So it should _not_ be "Fixes #12345 -- Regulates the frobnicator", it should be "Fix #12345 -- Regulate the frobnicator." Everybody seems to be in favour. I'll allow myself a small question mark anyway. Why? Well, django is well-known for its excellent documentation. Take for instance the release notes. Here's a snippet: "Django now offers password validation to help prevent the usage of weak passwords by users." That is how we communicate with our users. Now back to commit messages and code. Code should be written for humans reading it, not for computers executing it, right? Readability counts. Now if I read the history of a file I'd expect to read something that's pretty readable to me as a developer. I expect to read what happened: "Added password validation to help prevent the usage of..." Instead I'll now see commit messages like this: "Add password validation to prevent the usage of..." Linguistically, I'm getting an imperative order to do something. And I have to translate it to a sentence that actually makes sense. Every django programmer has to make that mental switch/translation. Is that a cost we want to pay? Does it fit in with our tradition of providing good documentation? Are we taking linguistic advise from the people who brought us git's user interface instead of from our English teachers? We don't have to order git to do something, we have to communicate what we've done to fellow programmers. I'm not a native English speaker, so I might be missing some nuances. Perhaps it is less weird if you're a native speaker. Reinout -- Reinout van Rees http://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity" -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/nkm456%24qhb%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Two proposals for the Django Code of Conduct.
On 08-09-14 09:16, Benjamin Scherrey wrote: So lets see... anyone who has done any of the following completely outside the context of the Django community or forums is now not welcome to participate: You mention a number of things you aren't allowed to ever have done somewhere else in your life. "He who's innocent is allowed to throw the first stone", you might say. What is the intention of the change-in-wording? My guess is as follows. I remember reading some harrasment blog post two years ago. In which someone blatantly misbehaved in a bar during a conference. Nothing was done from the conference's side because it was after conference hours in a non-at-the-conference bar and not at a conference-sponsored event. To my eyes, the change of wording in the pull request only *intends* to put a stop to the it-was-in-a-random-bar-and-not-at-the-official-django-conference excuses. Reading the entire thread, it doesn't seem like the intention is to start a full-out thought police. In your opinion, wouldn't this mailinglist thread be enough of a safeguard against unwanted use of the pull request? Reinout -- Reinout van Rees http://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/lunt3a%24ipf%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Time to drop support for Oracle < 11?
On 14-06-14 02:52, Tim Graham wrote: 11.1 - Aug 2007 - Aug 2012 - Aug 2015 10.2 - Jul 2005 - Jul 2010 - Jul 2013 To provide an additional data point: I checked with a colleague. We do a lot of business with governmental organizations in the Netherlands (mainly water boards). Most of them are on 11. With one or two still migrating from 10... :-) Reinout -- Reinout van Rees http://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/lnmlbk%24qam%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Add an extra parameter to 'static' tag
On 01-06-14 16:36, Renato Oliveira wrote: {% static 'path/to/my/angular.js' http://googlecdn/angular.js %} {% static 'path/to/bootstrap.css' http://bootstrapcdn/bootstrap.css %} It seems to me that the core use case of the staticfiles app is to manage *local* css files well. This includes the scenario where the local files are copied off to a CDN. That CDN's base URL can then be used in production. What you are proposing sounds to be a different problem: - You want to use a CDN in production. - You want to use local files as a fallback for when you're on a train without an internet connection to the CDN. So... I don't think this change should go into staticfiles. But... the basic use case is sound. Perhaps you could change your code into a template tag that looks like {% cdn http://googlecdn/whatever.js %} ? With a management command that would download all the relevant files to a local directory? (Assuming you can list the templates). Or that would do it on the fly when an internet connection is available when you use the template? It works the other way around from your current approach, but that looks to me to be the right way around :-) Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/lmg7nt%24og3%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Epydoc failed to generate documentation for Django 1.5
On 04-04-13 05:19, Kevin Veroneau wrote: | Import failed (but source code parsing was successful). | Error: ImproperlyConfigured: Requested setting DATABASES, but settings are not configured. |You must either define the environment variable DJANGO_SETTINGS_MODULE or call |settings.configure() before accessing settings. (line 1) Is this Epydoc error related to Epydoc or something that Django shouldn't have done in it's source code? I first thought "isn't this just the common problem of needing to set DJANGO_SETTINGS_MODULE?". I have to do it all the time in my own sphinx documentation. A quick os.environ call from sphinx' conf.py fixes that. Looking at the code of the management command that epydoc crashes on, it seems that epydoc simply executes too much. This might be one of the cases where there's no handy way of supporting such an introspective tool. Can you ignore files in epydoc? Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: DjangoCon Europe tickets on sale today!
On 27-02-13 21:21, Andre Terra wrote: I wonder if these will ever be made available online for a fee, even if months after the conference. For a hobbyist developer like me, coughing up a few thousand dollars for the tickets, registration and hotel is just impossible, but I would be glad to pay to have access to the knowledge being shared there. For most Python (and thus Django) conferences, the talks are assumed to be available online after a couple of weeks or months. The best site to look at is pyvideo: http://pyvideo.org/ http://pyvideo.org/search?models=videos.video=djangocon Hm. I notice that the djangocon.eu videos aren't there. 2011's are here: http://blip.tv/djangocon-europe-2011 2012's can be downloaded. You probably can google around for the rest. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)
On 19-02-13 23:32, Nick Phillips wrote: I don't recall looking at the ALLOWED_HOSTS setting before. Should there be a note in the 1.4 docs that the default ['*'] value is a temporary default value? That from 1.5 onwards it will be an empty list? https://docs.djangoproject.com/en/1.4/ref/settings/#allowed-hosts Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: use SQLAlchemy Core for query generation
On 30-06-12 16:22, Luke Plant wrote: Also, in Django to date we've eschewed external dependencies. That has been partly due to the poor and confusing state of Python packaging, which is hopefully improving. [snip] Our current recommended installation method is via pip [2], and we would be doing our users a disservice to recommend otherwise. Slight warning: everyone recommends pip, but watch out with windows. Pip doesn't support binary eggs (which easy_install does), so all those python database drivers will need to be compiled. And virtualenv/pip defaults to a nicely isolated virtualenv, so the clicky-clicky-install python database drivers (and other binary eggs) won't get used. So: pip sounds great right until you need binaries on windows. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Django's CVB - Roadmap?
On 01-06-12 16:54, Jacob Kaplan-Moss wrote: I think as a whole we're divided. Luke's opinions differ from mine, and it's entirely unclear to me who's "right" or even if there's a "right" to be had. And that's just the two of us! I think this might be a situation where we need some more feedback from the community and some more time to decide what the right move here is. So... what do *you* think? Class based views as such are wonderful. The possibility to use them is great, if your usecase warrants them. My company has two base CBV classes that are used in *all* our projects. Nice for our productivity. But... - Hey, looky! Somebody looked at Zope's 2003 codebase and thought that mixin classes were great! You know that Zope basically started its zope.interface adapter machinery because those mixin classes became too complex? - All those generic views muck up the PR a lot. A CBV seems intended for a generic view. But it is (more) useful outside those. Summary: I love CBVs. The PR for them sucks because generic views turn it into a veritable feast of mixins. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Tagging 1.4 django release in Subversion
On 27-03-12 02:47, James Bennett wrote: On Mon, Mar 26, 2012 at 7:44 PM, Reinout van Rees<rein...@vanrees.org> wrote: > Having a release before the tag? Sounds weird to me. Making a tag is > integral to the actual release, right? Curious:-) The tag and the release package are both just the same revision from trunk, so there is no requirement for the tag to exist in order to release. In this case we were holding off a bit to see if we could pull off the GitHub migration quickly after the release, in which case it'd be one less thing to migrate (easy enough to just tag the release once we get it over there). But since that didn't happen, it's now been tagged in SVN. Good reason. I'm looking forward to seeing how github plays out for Django. It'll be anything from a fun sociological experiment to a possible boost for participation. Really positively curious how it will play out. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Tagging 1.4 django release in Subversion
On 26-03-12 18:13, Florian Apolloner wrote: I'm also intrigued how you have a release tarball before you have tagged the release! It's magic :ş Well, it is the kind of magic that gets you burned at the stake for witchcraft :-) Having a release before the tag? Sounds weird to me. Making a tag is integral to the actual release, right? Curious :-) Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Django 1.4 beta 1 released
On 17-02-12 00:06, Carl Meyer wrote: On 02/16/2012 03:35 PM, Reinout van Rees wrote: > Partially related question: several tickets have a pull request on > github instead of an svn patch. Is that enough? I assume a real svn > patch is better? A link on the ticket to a github branch or pull request is fine in lieu of an uploaded patch. I don't know that this is formally documented anywhere, but it's been the actual practice for a year or more now. I haven't seen it documented anywhere. But I guess the github move will happen after the 1.4 release dust settles, so there's no real need to document it right now, I'd say. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Django 1.4 beta 1 released
On 16-02-12 22:54, Aymeric Augustin wrote: > Related, a suggestion for the next release cycle: send an email to the mailinglist that there's a beta coming up and that you ought to hurry up to get new features in. I sort of did, just after the alpha: https://groups.google.com/group/django-developers/browse_thread/thread/74eff3def6ef47af?pli=1 I remember that one. Upon re-reading it, it is clear enough so I should have started cracking the next day :-) So... tickets with patches. I'm waiting patiently. I obviously shouldn't have done that, I guess :-) But I also didn't know when the beta would be out. And I also didn't want to bug the mailinglist unnecessary. So I guess I should not have assumed such a small patch would get in no problem. Question is, how can I know next time? Some keyword on the ticket that I can look for? Am I allowed to bug the mailinglist? Both tickets currently are in the list of tickets that need a review. Since you aren't the author of the patches, you're welcome to review them. If you think they match all the criteria for inclusion in Django, mark the tickets as ready for checkin. (See item 3 in the email I linked to above for more.) Someone else pointed me at https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#triage-workflow I didn't realize that I could mark it "ready for check-in" myself. (But there are 35 tickets ready for check-in, so I guess I still need to bug people to get it to be actually checked in). Partially related question: several tickets have a pull request on github instead of an svn patch. Is that enough? I assume a real svn patch is better? Finally, you can join the #django-dev IRC channel on FreeNode if you have questions and don't want to bug the mailing-list. I've fallen off the open-irc-in-the-morning habit since I don't work in a company with remote workers anymore. I'll keep it in mind. Thanks for the tips! Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Moving to ... Github vs Bitbucket
On 16-02-12 16:42, Łukasz Rekucki wrote: 1) I can't argue about popularity, because I have no data, but most Django applications I use come from github, so it's also quite popular. Last year's djangocon.eu was instructive for me. We were debating github/bitbucket at the office at the time. But when every single source code link in a presentation (except for the talk by bitbucket itself) points at github, it is very difficult to argue for anything else than github. (So I stopped arguing for bitbucket at the office and we're using github now). Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Django 1.4 beta 1 released
On 16-02-12 05:27, James Bennett wrote: Hot off the presses, it's the first Django 1.4 beta! Blog post with more information is here: https://www.djangoproject.com/weblog/2012/feb/15/14-beta-1/ I'm pretty sure that "beta" means "nope, you won't get any changes that aren't bug fixes in", but I cannot find the page that says that. I assume I'm right? Related, a suggestion for the next release cycle: send an email to the mailinglist that there's a beta coming up and that you ought to hurry up to get new features in. Perhaps it is just me and perhaps I didn't put enough effort in it, but how am I to know what gets included in a new release? And what not? I kinda need ticket https://code.djangoproject.com/ticket/16744 as I'm writing a book about Django and class based views just look *silly* without that feature. They're hard to sell unless I stick them in some advanced chapter. And I really want them right up front in my book. The ticket seems OK including a patch. But someone said it had to wait on some other ticket, also with a patch. Both ready. So... tickets with patches. I'm waiting patiently. I obviously shouldn't have done that, I guess :-) But I also didn't know when the beta would be out. And I also didn't want to bug the mailinglist unnecessary. So I guess I should not have assumed such a small patch would get in no problem. Question is, how can I know next time? Some keyword on the ticket that I can look for? Am I allowed to bug the mailinglist? Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: AJAX generic views
On 03-02-12 09:43, gert wrote: I've been using the class based views from day one and loving it! It would be great if there was a generic view to bring some consistency to the way everybody implements AJAX. Or if not a view then maybe a mixin or two (JSONResponseMixin used in the documentation comes to mind). Any thoughts on this? Yes: http://django-rest-framework.org/ We're using that REST framework now exactly because it uses class based views :-) And see http://rest.ep.io/ for the build-in admin-like browseable API it generates for your REST interface. Major selling point. Reinout -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RFC: "universal" view decorators
On 16-09-11 18:08, Javier Guerra Giraldez wrote: I guess that when you know by heart exactly what does each one do, they become a pleasure to use. They *are* a pleasure to use. A colleague switched an app over to class based views last week and he got rid of 30% of the code. And it was more elegant and readable. Just mentioning that as I'm real happy with class based views :-) Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RFC: "universal" view decorators
On 15-09-11 23:27, Donald Stufft wrote: tl;dr; Using Mixins to add in functionality to a CBV makes way more sense then using a decorator which is essentially going to be doing the same thing as a mixing would, it just makes finding what is going on harder, makes customizing the decorator harder and/or uglier, and goes against the way functionality is currently added to a CBV. Watch out, in general, with adding more and more mixins. I explained just the most basic template CBV to a colleague: there are just two mixins and a base class there, but his eyes already started to glaze over because I had to jump from class to class to class to explain how it all hung together. Throw in a LoginRequiredMixin and SomeOtherMixin and you have the risk that it turns into a big pile of un-debuggable code. Too many places to look. Your mind's main working memory has a stack size between 6 and 8: you just cannot juggle 3 base classes, 4 mixins and 2 method names at the same time. => A mixin isn't necessarily clearer than a decorator. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: class based views: object instead of dictionary as context?
On 13-09-11 20:33, Tobias McNulty wrote: I love it when problems solve themselves :-) That's a good point. Are there *any* methods in the CBVs that don't take arguments, that also modify data? The only one that I found in the list I'd initially proposed that can be called without arguments is as_view(), and I'm not sure that really even needs protection. Maybe there's no need to protect anything with alters_data / proxying? There's not really anything useful you can do with as_view in your template, should you attempt it. I also don't think you can do anything destructive with it. So it sounds like we don't need the proxy. Good that you added it anyway as it helps us dig deeper into the problem :-) Luckily it seems we don't have to dig very deep. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: class based views: object instead of dictionary as context?
On 12-09-11 18:25, Florian Apolloner wrote: On Monday, September 12, 2011 5:39:03 PM UTC+2, Reinout van Rees wrote: Addition: disallow attributes/methods starting with an underscore? That's a handy way to stow away dangerous methods should you have them in your view. That's already the case for resolving variables in templates, I don't think we need any specialcasing here. > The only way I can see yourself shooting in the foot is when you have a > form view that reacts to get() and post(). Upon "get()", the template > *could* call data-modifying methods on the class. Not easily, since the templates can only call methods which don't require extra params, get/post do take request at least. I love it when problems solve themselves :-) Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: class based views: object instead of dictionary as context?
On 10-09-11 00:15, Tobias wrote: This is probably an overly simplistic implementation, but would something like this work, more broadly covering Jacob's concerns in the ticket about template authors being able to shoot themselves in the foot? It seems less effective to mark all required methods with alters_data, as this method also wouldn't prevent get(), post(), etc. from being called in subclassed views (which could potentially generate recursive loops). https://github.com/tobiasmcnulty/django/compare/master...ticket-16744 It is already more elaborate than what I'm using locally now :-) I don't have a proxy object in my own views. Seems like a good idea, though. Addition: disallow attributes/methods starting with an underscore? That's a handy way to stow away dangerous methods should you have them in your view. The only way I can see yourself shooting in the foot is when you have a form view that reacts to get() and post(). Upon "get()", the template *could* call data-modifying methods on the class. Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: class based views: object instead of dictionary as context?
On 04-09-11 21:28, Reinout van Rees wrote: On the other hand, from an object oriented viewpoint, the class based views seem to be pretty powerless and non-object-oriented. To me, it almost seems like they're artificially "castrated" to make function views look good :-) That's probably not the intention, but... Ehm, the current classes based views are pretty good, apart from the view-not-in-context problem that I see. That's the one point on which I find those CBV's to be somewhat powerless. Upon re-reading it sounded a bit like I think the whole of class based views is powerless and bad, but that was *totally* not my intention :-) I love 'em :-) Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: class based views: object instead of dictionary as context?
On 03-09-11 16:05, Luke Plant wrote: The history of CBVs in Django is that they are simply a way of using OOP and inheritance to reduce duplication between view functions and allow better re-use. They are supposed to be drop in replacements for function based views in terms of the end result, rather than produce any change in what a template will contain. Ok, when you want to keep the function and class based views more or less the same, the current implementation makes sense. On the other hand, from an object oriented viewpoint, the class based views seem to be pretty powerless and non-object-oriented. To me, it almost seems like they're artificially "castrated" to make function views look good :-) That's probably not the intention, but... Probably the best illustration of my point: .get_context_data() should return a dictionary. And .render_to_response() needs the output of that. "So" you have to pass the output of .get_context_data() to .render_to_response(). Wait a minute... We're talking object orientation here! Why doesn't .render_to_response() call .get_context_data()? This is just function-like behaviour in a thin object oriented shell. From an OO viewpoint, I'd rather expect a "self.context = {}" in the most top-level view baseclass's __init__(). Not passing along a variable that is calculated in the very same class as a parameter to a method in that very same class. Your point that, effectively, {{ view.something }} is different than {{ something}} is valid, though. In that sense, a class based view that passes {'view': self} as the context dict isn't a drop-in replacement. Would you be more happy with a more magical view that would inject everything from local() into the context dictionary or something like that? Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: class based views: object instead of dictionary as context?
On 02-09-11 10:04, Russell Keith-Magee wrote: To the best of my knowledge, the only reason the view isn't included in the template context is because over more than two years of design discussion, I don't think the idea of including the view in the context was ever proposed. [...] Patches welcome;-) I haven't got a patch (yet), but I at least created a ticket for it: https://code.djangoproject.com/ticket/16744 Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
class based views: object instead of dictionary as context?
Hi, I've got one big what's-the-design-decision/reason question regarding django 1.3's new class based views: why does django encourage a hand-crafted context dictionary instead of "just" passing the view object along? In zope/plone, I was used to having the view object available in the template as 'view'. The django equivalent would be to pass a context of {'view': self} to the template. All the attributes on the view class (well, object) would be available. Django prefers the template to stay simple and stupid: what could be better than encouraging to just add extra methods to the class if you want something special? Now you have to add the method *and* pass it along in the dictionary. Double work? Passing the view object to the template by default seems to me to be an absolute no-brainer. Class based views ought to mean you get the view object in your template, right? But Django doesn't do it. So... is there a specific reason for it? Reinout -- Reinout van Reeshttp://reinout.vanrees.org/ rein...@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Google Organic Search Results for Documentation
On 08/11/2010 09:51 PM, Paul McMillan wrote: I think this is somewhat ameliorated by being able to link to the current trunk documents these days. Many incoming links will be going there. Additionally, for old documents, there is the "these docs are old" message at the top. When I google, I always end up at the /dev docs with a big warning on top "This document is for Django's development version, which can be significantly different from previous releases. Get old docs here:..." The 1.2 docs have the least scary warning. Does the website tell google (via the xml sitemap, for instance) to prefer the /dev docs over the /1.2 docs? I'd say the /1.2 links would be more user friendly to get for default google incoming traffic. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" -- 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: Feature idea
On 06/01/2010 09:42 PM, Sean O'Connor wrote: I've been generally thinking about putting together a package of reusable tools to implement common "patterns" for reusable apps. Included in this would be this type of auto-discovery system as well as a registration pattern. Auto-discovery and registration: setuptools entry points can be used for this. That at least is an existing (partial) solution. I'm already using it in a django project where I've got a couple of packages that can register a render-something-on-a-map method. In the one location where I need it I can then just ask setuptools (well, pkg_resources) for a list of methods and call them. Just for the idea, here's a snippet from a setup.py: entry_points={ 'lizard_map.layer_method': [ 'shapefile_layer = lizard_map.layers:shapefile_layer', ] }, And afterwards iterate through all the entry points and call them (or do something else with them): for entrypoint in pkg_resources.iter_entry_points( group="lizard_map.layer_method"): method = entrypoint.load() method("some argument) Some longer explanation: http://tinyurl.com/ylf3kjb Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" -- 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: First-class WSGI support in Django 1.3 / twod.wsgi
On 05/29/2010 01:51 AM, Gustavo Narea wrote: Basically, when you need to integrate a piece of WSGI middleware that must be present both on development and deployment, you have to get rid of `manage runserver' and use a development server like the one from Paste or CherryPy. Middleware that *must* be present: it reminded me of an old blog post that warned about mandatory middleware. I think I've read it in more than one place, though: http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html The core idea of that post is that if something is mandatory, it isn't middleware anymore. It should be part of your application. I don't really have an opinion about this myself (yet). Do you know what the current way of thinking on this is? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" -- 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: Default ordering on User model
On 05/21/2010 02:59 PM, Karen Tracey wrote: Actually there is no default ordering, and yes, there is a reason, see: http://code.djangoproject.com/ticket/6089, which also shows a workaround for getting ordering back for specific form fields. Granted that is a bit of a pain, and there is some dissatisfaction expressed at the end of the ticket, but I don't see a specific proposal for how to address the issue while still not introducing problem for sites with large numbers of users, so that's the way it is now. Another data point: Plone has a checkbox for that: "do you have many users/groups?". If True, several screens don't attempt to list all users, do sorting, etc. Instead search fields are used. So: best of both worlds. But there's of course some extra code here and there with "if LARGE_AMOUNT_OF_USERS... else ...". Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" -- 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: djangocon.eu sprints (was Re: Class based generic views in 1.3?)
On 05/14/2010 04:27 PM, Jeremy Dunck wrote: On Fri, May 14, 2010 at 9:12 AM, Reinout van Rees<rein...@vanrees.org> wrote: ... I'm used to Plone sprints and there's usually some "make sure you have svn access to x and y" stuff best handled *before* the sprint, that's why I'm asking :-) This might help: http://code.djangoproject.com/wiki/Sprints Yes, it does help :-) I've added a link to that page on the djangocon.eu wiki sprint page. If you have questions after that, let me know -- I'd be happy to improve that page. That page is fine. The page linked from there that tells you how to set up an svn trunk django got me frowning a bit: "symlink django trunk into your system python". Ehm, I'd rather isolate it with virtualenv or buildout to keep trunk's stuff out of the rest of my django projects. So: is that just a missing piece of documentation? Or is the virtualenv kind of isolation rarely done when developing on trunk? Reinout -- 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.
djangocon.eu sprints (was Re: Class based generic views in 1.3?)
On 05/12/2010 10:16 PM, Ben Firshman wrote: This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. I'll be there at the djangocon.eu sprints, but I can't find extra information about that. Are there actions I need to handle beforehand? I'm used to Plone sprints and there's usually some "make sure you have svn access to x and y" stuff best handled *before* the sprint, that's why I'm asking :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" -- 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.