Re: Overhaul extra_requires to include more optional dependencies

2017-12-29 Thread Reinout van Rees

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?

2016-06-27 Thread Reinout van Rees

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?

2016-06-25 Thread Reinout van Rees

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.

2014-09-09 Thread Reinout van Rees

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?

2014-06-16 Thread Reinout van Rees

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

2014-06-01 Thread Reinout van Rees

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

2013-04-04 Thread Reinout van Rees

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!

2013-02-27 Thread Reinout van Rees

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)

2013-02-20 Thread Reinout van Rees

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

2012-07-03 Thread Reinout van Rees

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?

2012-06-02 Thread Reinout van Rees

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

2012-03-26 Thread Reinout van Rees

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

2012-03-26 Thread Reinout van Rees

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

2012-02-17 Thread Reinout van Rees

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

2012-02-16 Thread Reinout van Rees

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

2012-02-16 Thread Reinout van Rees

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

2012-02-16 Thread Reinout van Rees

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

2012-02-05 Thread Reinout van Rees

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

2011-09-17 Thread Reinout van Rees

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

2011-09-16 Thread Reinout van Rees

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?

2011-09-13 Thread Reinout van Rees

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?

2011-09-12 Thread Reinout van Rees

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?

2011-09-12 Thread Reinout van Rees

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?

2011-09-04 Thread Reinout van Rees

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?

2011-09-04 Thread Reinout van Rees

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?

2011-09-02 Thread Reinout van Rees

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?

2011-09-01 Thread Reinout van Rees

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

2010-08-13 Thread Reinout van Rees

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

2010-06-02 Thread Reinout van Rees

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

2010-06-02 Thread Reinout van Rees

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

2010-05-21 Thread Reinout van Rees

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

2010-05-14 Thread Reinout van Rees

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

2010-05-14 Thread Reinout van Rees

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.