Testing documentation

[Daniele Procida]

I have done some work on writing up a tutorial for testing (part 5 of the 
existing tutorial, in effect).

My draft so far:




I'd really appreciate feedback, on any aspect of this.

Trac ticket is .

Thanks,

Daniele

-- 
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: #16779 - a tutorial for first time Django contributors

[Daniele Procida]

On Sat, Nov 10, 2012, Tim Graham  wrote:

>Any specific feedback on this paragraph, or the tutorial as whole, would be 
>appreciated:

My four thoughts:

Firstly: I like to see things like:

./runtests.py --settings=test_sqlite

include a comment when appropriate; in this case to say why we are using 
--settings=test_sqlite

Secondly: "For advanced users who wish to use virtualenv" - is this really 
implying that only advanced users would use virtualenv? 

I think that the most helpful thing to say to people who are not using 
virtualenv already is that they need spend 15 minutes learning to use it before 
they do anything else, because it's one of the most valuable and easy to learn 
tools they will ever encounter.

Thirdly: if everyone is using virtualenv, would that eliminate the difficulties 
trying to explain PYTHONPATH?

Fourthly: although this and the Working with Git and GitHub tutorial explain 
the technical part of the process well, they both somewhat assume that you're 
able to come up with complete if not perfect patch.

In reality I think a lot of back-and-forth refinement goes on before that point 
is reached - what would be handy is advice on how to proceed when your patch is 
incomplete and you need some feedback before going further.

But this looks great, I wish I had read it myself before trying to submit 
anything.

Daniele

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

Tutorials

[Daniele Procida]

I am one of those people who can only learn things by doing them, and finds it 
very hard to grasp things from reference materials. The Django documentation is 
excellent on the latter, but not quite so good on the tutorials that would 
guide me through doing things in a way that will help me learn.

I've made a couple of tutorial contributions so far (which if I am honest 
simply reflect the steps I took when I was learning the topic). They are the 
testing tutorial  and 
a uWSGI/nginx tutorial, which though it may not be quite right for the Django 
docs has gone into the uWSGI docs.

I'd like to contribute more tutorials to the documentation, and since the next 
thing I need to get to grips with is logging I will write my own notes so I 
remember how to do it, and I could create a tutorial for it.

Would that be useful for the documentation? I realise that a tutorial is always 
going to be a partial and incomplete introduction to a subject, but newcomers 
need to start with something concrete, and it gives them some purchase on the 
reference material that is already provided.

Are there other topics that really ought to have tutorials written for them?

Daniele

-- 
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: make the source code of the django tutorial available ?

[Daniele Procida]

I'm re-opening an old discussion - 
https://groups.google.com/d/topic/django-developers/MbLD1BL5xkQ/discussion. 
Sorry if it all comes out weird, I'm having to do it in Google Groups.

I propose maintaining a repository of the Polls tutorial code, with each 
branch representing the state of the code at the end of each tutorial.

I realise that there is a danger that people might be tempted simply to 
checkout the code rather than type it in, following all the useful steps 
and mis-steps that the tutorial provides, but at the same time it would 
have other significant advantages that it would be a shame to forego just 
in order to save people from temptation, especially if they are strongly 
warned against it.

The advantages:

A learner likely won't just follow the steps in the tutorial, but will also 
want to play and experiment, and break things. It will make for a better 
learning experience if that's possible with the safety-net of being able to 
return to a known good state. 

In particular, it will make it easier for the learner to reset their 
tutorial code so that they can go on to the next tutorial after playing 
freely with it. And sometimes, it might be weeks or months later that they 
want to do part five, or go back to have a look at some particular thing in 
it from an earlier stage.

It will help the documentation writers. It's difficult to build on the work 
in the tutorial if it's not easy to get where it was. For example, a new 
tutorial could use the Polls application to tackle logging or static files 
- which is what I would like to start doing now - but it's quite a bore to 
have to go through all the steps in all the previous tutorials just so you 
can start writing it.

I think it would be worthwhile having an official repository for this 
purpose.

Regards,

Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/qAizMhCo0iQJ.
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.

Tutorial review

[Daniele Procida]

There has been some discussion of the tutorials on IRC, and at the same time 
I've been working through the tutorials again.

I've made some amendments (who knows, they may even amount to improvements) and 
commented on them, at .

Some of the changes are just expanations, but some affect the tutorial code.

Ticket: .

Daniele

-- 
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: Tutorial review

[Daniele Procida]

On Thu, Jan 31, 2013, Daniele Procida  wrote:

>There has been some discussion of the tutorials on IRC, and at the same
>time I've been working through the tutorials again.
>
>I've made some amendments (who knows, they may even amount to
>improvements) and commented on them, at <https://github.com/django/
>django/pull/688/files>.
>
>Some of the changes are just expanations, but some affect the tutorial code.
>
>Ticket: <https://github.com/django/django/pull/688/files>.
 
Or even <https://code.djangoproject.com/ticket/19706>.

Daniele

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

An idea for the URL dispatcher

[Daniele Procida]

I have an idea for the URL dispatcher, and I'd like to know what your thoughts 
are.

Often - not always but often - a Django URL will map to a model instance via a 
URLconf and a view.

I can think of a few uses for a feature that used Django's URLconfs to return 
the model instance, if there is one, mapped to by a particular URL.

In other words, one would feed a URL to the system, which would return a model 
instance, if one could be uniquely associated with that URL. 

Examples of the utility of this idea:

* applications that handle links to other Django models using generic content 
types often make the admin user select the object's class and instance; this 
feature would allow them also to enter a URL into a form, and the system would 
then select the object's class and instance, if a match can be found

* web server logs and analytics reports list URLs visited, that then have to be 
interpreted; from this one could obtain a report listing actual things that 
visitors were interested in

* it could be an easy way to get to the admin URL for any model instance from 
its URL

Currently, Django's URLconfs are used to call views. But, I think it would be 
feasible to amend them so that they could also return an object, using optional 
arguments to ask it to do that instead of calling the view.

As I understand it, namespacing like:

(r'^help/', include('apps.help.urls', namespace='foo', app_name='bar')),

already helps map URLs and model instances. Then, if each particular URLconf 
had an optional argument:

mapper = some_mapping_function

then as long as there is some way to tell the URL dispatcher that it should not 
call the view, but instead call the mapper, it will return the model instance 
if it finds one.

So my questions are:

* would this functionality be valuable
* is the concept viable
* and would it be worth the effort to develop it?

I'd certainly have a lot of use for it myself, but I don't know whether it 
would be more widely useful, and I don't fully understand what would be 
involved in implementing it.

Daniele

-- 
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: An idea for the URL dispatcher

[Daniele Procida]

On Wed, Mar 20, 2013, Carl Meyer  wrote:

>> Often - not always but often - a Django URL will map to a model
>> instance via a URLconf and a view

>I think this is an interesting idea for some specific use cases, but I
>don't think its implementation belongs in the core url-resolver code,
>for a couple reasons

>If you work on implementing this outside Django and find that you need
>hooks that are not currently available, those hooks would making
>interesting feature proposals for Django.

Thanks for the feedback.

I think it would at minimum require hooks so that the URL dispatcher could call 
other functions, not just views.

So:

* the URL dispatcher could be invoked with a special argument when you want it 
not to call views but perform some other function

* the URL confs could take this argument, and call the function it specifies 
instead of the usual view, failing gracefully if the function doesn't exist


I guess it would have to be a keyword argument such as:

{ 'alternative_function': 'some.alternative.function'}

In fact this would allow you to use the URL dispatcher for other URL-related 
things, not just my URL-to-model functionality (though I can't think of 
anything very useful just at this moment).

Then as you say the actual functionality would be built outside Django itself.

How does that sound?

Daniele

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

Messages templates documentation

[Daniele Procida]

 could be expand to provide more guidance on how to implement this.

For example, should messages be dealt with at the site template level, or at 
the application template level? 

This is particularly relevant if one is developing a re-usable application. 

If an application's templates include messages code, then if that application 
is used in a site that also has messages code in its base templates, messages 
will be displayed twice. Using the site templates to handle messages also means 
they can be presented consistently. 

On the other hand, not handling messages in the applications' templates means 
forgoing the opportunity to customise their appearance, location and the 
headings under which they appear.

So should the advice be to treat message template output as a site-wide 
feature, or as an application-related feature?

Dabiele

-- 
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: Messages templates documentation

[Daniele Procida]

On Fri, Apr 19, 2013, Russell Keith-Magee  wrote:

>> So should the advice be to treat message template output as a site-wide
>> feature, or as an application-related feature?
>
>I'm not sure I see why this is something that Django needs to state an
>opinion on. Django deals with the issue at the server side - making sure
>that messages can be captured, stored and retrieved as necessary. The
>decision of how to display those messages really is up to the end user. I
>can see legitimate reasons why you'd want to take both approaches you
>describe, and the decision to use one or the other really depends on the
>templates and visual layout of the site under discussion.

Thanks, that's useful.

When the question came up, one opinion was that messages are site-wide, so 
displaying them in application-specific templates is incorrect:



Even if Django's advice is that it doesn't really matter where messages 
templates are as long as they behave nicely, that would be useful advice.

Daniele

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

Setting aside easy-pickings for sprints

[Daniele Procida]

At the start of the sprints at DjangoCon Europe next month, I'll be holding a 
workshop called "Don't be afraid to commit" for people who'd like to get 
involved in Django projects (including Django itself of course).

It'll cover: virtualenv, using GitHub, writing tests and creating 
documentation, all oriented towards the Django Project ways of working.

Between now and then would it be possible for some very simple tickets to be 
set aside for people who will then have a chance to tackle some real issues at 
their first sprint, after the workshop?

Thanks,

Daniele

-- 
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: Setting aside easy-pickings for sprints

[Daniele Procida]

On Mon, Apr 29, 2013, Daniele Procida  wrote:

>At the start of the sprints at DjangoCon Europe next month, I'll be
>holding a workshop called "Don't be afraid to commit" for people who'd
>like to get involved in Django projects (including Django itself of course).

I've written up the tutorial for the workshop:

<https://dont-be-afraid-to-commit.readthedocs.org>

I'd appreciate any comments/corrections/criticism.

>Between now and then would it be possible for some very simple
>tickets to be set aside for people who will then have a chance to
>tackle some real issues at their first sprint, after the workshop?

I haven't yet been through the tickets looking for suitable candidates,  but I 
will do that over the next week.

Assuming that people come out of this workshop and feel ready to take part in 
the Django sprint, they will likely be first-time Django committers. Would 
anyone like to volunteer to help steer them into the process?

Thanks,

Daniele

-- 
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: Perception of attitude in tickets

[Daniele Procida]

On Fri, May 10, 2013, Simon  wrote:

>Of course, once the ticket has been closed, the only way to appeal is 
>through the mailing lists. To myself as a newcomer, that just feels like a 
>way of making further dissent less visible. I'm sure this isn't the case 
>but that's certainly the feeling I got.

Surely the process should begin, not end, with the email list? Or better still 
sometimes, #django-developers on irc.freenode.net.

Daniele

-- 
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: Perception of attitude in tickets

[Daniele Procida]

On Mon, May 13, 2013, Łukasz Rekucki  wrote:

>> The status WONTFIX sounds awfully rude to me. It's like saying "That's a
>> pony and you can't have one, ever." It implies a terminal finality which
>> actually isn't meant in some cases, because it is possible (as we've seen)
>> and even sometimes recommended by a core developer, for a sufficiently
>> determined person to push for change on the mailing list and make it happen.
>>
>
>You can blame this on my lack of social skills, but I really don't see how
>it's rude.

Maybe it's not rude, but it is off-putting. Perhaps there are some proposals 
that really do deserve to have the door closed firmly in their faces - that's 
what "WONTFIX" suggests to me, even if it's not what's intended.

Daniele

-- 
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: Remote participation in sprints

[Daniele Procida]

On Wed, May 15, 2013, Shai Berger  wrote:

>Hi all,
>
>This saturday and sunday there are supposed to be sprints in DjangoCon EU in 
>Warsaw. To my regret, I could not be present at the conference. However,
>I may 
>be able to set aside the two days and participate in the sprint remotely.
>
>Will there be an effective way to do this while communicating with the 
>developers present at the sprint? IRC? Google hangout? IM?

#djangocon and #django-sprint on irc.freenode.net

Daniele

-- 
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: Prevent data loss in the admin

[Daniele Procida]

On Mon, Dec 8, 2014, Rune Kaagaard  wrote:

>I've made a branch that adds optimistic concurrency control to the admin: 
>https://github.com/runekaagaard/django-lock-the-admin/compare/adminlock. It 
>works for the main change object and inlines and has tests. All tests 
>passes with postgres and sqlite.

I like the concept.

I would prefer however to see something like:

3 items on this page have been updated by another user while you were 
editing them.

You can:

* see the other user's changes[link] in a new browser window, and apply 
your changes there, or
* refresh this pages[link] (Warning! your changes here will be lost!) 
and reapply your changes here

This way the user is invited to compare the differences and to copy their 
changes over, rather than simply lose them.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141208125127.743977646%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Daniele Procida]

On Tue, Dec 16, 2014, Schmitt, Christian  wrote:

>Somehow I hate it. The website is the worst website I've seen since a long
>time.
>The contrast is really aweful.
>The issue Tracker got unusable due to the colors that aren't focused on
>readability.
>
>Overall it looks like a mess, just to have a new design.
>
>Doesn't look like a designer or a graphic guy had his hands on that.
>I can't realized why some should replace a good and usable design which had
>some practical usage and also a good readability with the "thing" we have
>now.
>
>Sorry but I will stick to the old docs as for now or use the PDF ones with
>my custom style (since your colors are aweful, too).
>
>Django should focus on a clear design which is helpful for readability and
>not this stupid mess.

As the message you replied to indicated, various people worked very hard on 
this. 

Your comments are unkind and hurtful, and also completely useless, since they 
don't identify a single specific problem or improvement.

Here's the code ; you're welcome 
to help improve it if you can.

In the meantime I have removed you from our email lists, since your tone is not 
welcome here. Please don't come back unless you can communicate in a more 
acceptable way.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141217081139.62356388%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Daniele Procida]

On Wed, Dec 17, 2014, Torsten Bronger  wrote:

>> In the meantime I have removed you from our email lists, since
>> your tone is not welcome here. Please don't come back unless you
>> can communicate in a more acceptable way.
>
>Is this customary procedure on this mailing list in such cases?

People are very rarely as discourteous as that, so it doesn't happen often.

We have a code of conduct for the community 
.

>Normally one simply ignores postings/authors one doesn't like.

It wasn't something I simply didn't "like". It was unkind and disparaging 
remarks (not to mention aimed at people who had put in a lot of collaborative 
effort on behalf of the community, and at their work).

It's not acceptable here and won't be tolerated, whoever is making the remarks 
or whom they're aimed at.
 
>I hope that banned users don't have the answers to my questions.  ;-)
>Besides, a sock puppet is made in minutes ...

He's not banned; he's welcome back here at any time. It's the tone that's not 
permitted.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141217115915.954054400%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Daniele Procida]

On Wed, Dec 17, 2014, Rob  wrote:

>On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt wrote:
>>
>> Somehow I hate it. The website is the worst website I've seen since a long 
>> time.
>> The contrast is really aweful.
>> The issue Tracker got unusable due to the colors that aren't focused on 
>> readability.
>>
>
>Clearly.  My audit extension flags 47 contrast problems on the home page 
>alone.  The site is not very accessible contrast wise.
>
>Doesn't look like a designer or a graphic guy had his hands on that.
>>
>
>It clearly had a designer,  but they don't grok usability.
>
>I hate to be "that guy" but this is not really an improvement other than it 
>works on mobile now ...

We'd hate you to be "that guy" too. However, so far you are "that guy", since 
merely announcing that you have identified numerous accessibility issues is 
useless. 

The repository is . It's all open. 
If you're able to suggest or make improvements, you know what to do if you want 
to stop being "that guy".

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141217133711.440709691%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: How to Display the number of active users in Django Site with IP address

[Daniele Procida]

On Sun, Dec 21, 2014, Avinash Kunuje  wrote:

>How to Display the number of active users in Django Site with IP address

Hello Avinash. 

You'll get answers to questions like this on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, which is for the discussion of 
the development of Django itself.

You might also find the #django IRC channel on irc.freenode.net helpful.

Daniele


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141221135742.1404254792%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Updating logging docs

[Daniele Procida]

On Tue, Dec 30, 2014, Lee Trout  wrote:

>I'd like to see a mention of the defaults existing in
>`django.utils.log.DEFAULT_LOGGING` *at a minimum*. Given the desire to
>understand the entire technical scope I think it would be worth repeating
>the default settings in the default logging configuration heading at the
>bottom of the page (and toss a comment in django.utils.log that if it's
>updated remember to update the docs).
>
>Thoughts?

I think that logging needs a proper step-by-step how-to, not more topic or 
reference documentation. That would make the existing documentation far more 
meaningful.

It's something I've been meaning to look at for a couple of years at least, but 
I'm not actually any closer to it.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141230191812.1826892749%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Django documentation doesn't show correctly in any browser

[Daniele Procida]

On Tue, Jan 13, 2015, Some Developer  wrote:

>Any suggestions? I'm pretty sure I can't be the only one who is having 
>issues.

It's not looking like that for me, no idea what's happening for you.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150113193644.435475248%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: TabularInline

[Daniele Procida]

On Fri, Mar 13, 2015, Rodrigo Ancavil  wrote:

>Can I display model's function fields on a TabularInline? 

Hi Rodrigo.

You'll get answers to questions like this on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, which is for the discussion of 
the development of Django itself.

You might also find the #django IRC channel on irc.freenode.net helpful.

Daniele


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150314102904.335423926%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Django's docs application as a reusable app

[Daniele Procida]

We've been looking at the application used by the Django Project to build and 
manage the Sphinx documentation:



We want similar functionality for some of our own websites, because doing it 
this way is a much more seamless way than having documentation hosted on Read 
the Docs, particularly from the point of view of the styling.

So, we want to explore the possibility of turning the application into a 
reusable application, that can easily be dropped into a Django-based website to 
build Sphinx documentation.

The application currently is quite tied into the deployment environment and 
configuration of the Django Project website, so some of the work will be be to 
abstract it from that.

A reusable version of the application will be useful for the many people who 
have Django sites and Sphinx documentation. It could be useful for the Django 
Project too, because abstracting its configuration and environment conditions 
will presumably make it easier to deploy the Django Project site in a different 
environment in the future.

If anyone's interested in being involved in this, let me know.

Regards,

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150814115637.1761782431%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Django's docs application as a reusable app

[Daniele Procida]

On Fri, Aug 14, 2015, Jannis Leidel  wrote:

>Daniele,
>
>> On 14 Aug 2015, at 13:56, Daniele Procida  wrote:
>> 
>> We've been looking at the application used by the Django Project to
>build and manage the Sphinx documentation:
>
>When you say we, who is that?

We = Divio, http://divio.ch, and associated projects such as django CMS.

>I'm not eager to collaborate at this point as it would essentially come
>close to a rewrite and we're already short staffed on the Django
>websites team. If you'd turn it into a separate package the amount of
>customization and glue code to reintegrate it into the Django site code
>would be more work for us than we currently can handle. But at least the
>license is the same as Django's so feel free to use it however you like.
>Just please understand that you'd probably be on your own.
>
>In relation to that, have you looked at alternatives like
>
>- https://pypi.python.org/pypi/django-sphinxdoc/
>- https://pypi.python.org/pypi/django-docs
>- https://github.com/rtfd/readthedocs.org

Yes, we're looking at various ways of doing it, of which this is one.

>Of course there is also the commercial offer from the ReadTheDocs folk
>at https://readthedocs.com/ that should be interesting for businesses
>that aim at using Sphinx for documentation. I hear that Eric and the
>others at RTD are good people and would welcome input from you.

They certainly are - we use RTD a lot, and love it, and in fact we sponsor it 
too.

Thanks for the feedback.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150814144958.864375293%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: simplifying the install page

[Daniele Procida]

On Fri, Sep 25, 2015, Tim Graham  wrote:

>The install page mentions several different ways to install Django, from 
>pip install (recommended), to `setup.py install`, to symlinking the Django 
>checkout in your site-packages. Do you see any reason to keep the latter 
>methods instead of recommending pip all the time? 
>
>https://docs.djangoproject.com/en/1.8/topics/install/

I can't see any good reason to keep symlink method, but maybe I am missing 
something.

I'd prefer to see the use of virtualenv built-in to the process from the very 
start, and a quickstart version of the instructions as the first thing that 
people see:

virtualenv django-virtualenv
source django-virtualenv/bin/activate
pip install django

I know that's not so simple, and that Windows users need to do something a bit 
different, but at least seeing something that simple near the top of the 
document would be a promise that installation *can* be that easy.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150925170726.2021833171%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

User notification by email of account detail changes

[Daniele Procida]

I've been discussing with Florian on IRC a suggestion for improved account 
security.

On many sites, you will get a message a message like this:

>Hello evildmp,
>
>We wanted to let you know that your GitHub password was changed.
>
>If you did not perform this action, you can recover access by entering
>dani...@vurt.org into the form at https://github.com/password_reset.
>
>To see this and other security events for your account, visit https://
>github.com/settings/security.
>
>If you run into problems, please contact support by visiting https://
>github.com/contact or replying to this email.

(In fact my gumtree.com account was compromised, and this mechanism is how I 
learned about it, and was able to alert Gumtree and have a fraudulent 
advertisment removed from my account within minutes).

A similar thing would be valuable in Django, to help improve the security of 
all Django accounts and sites.

I am not sure how it could or should be implemented; Florian suggests as part 
of a more general audit framework.

On a related matter, my djangoproject.com account has an associated email 
address (not the same one as at code.djangoproject.com) but I don't think I am 
able to change that.

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151115134646.344271125%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: User notification by email of account detail changes

[Daniele Procida]

On Sun, Nov 15, 2015, Baptiste Mispelon  wrote:

>For your djangoproject account, you can change your display name and 
>email there: https://www.djangoproject.com/accounts/edit/.

Heh, thanks, not even Florian was aware of that.

Is this documented somewhere?

Daniele

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151115135755.1018584772%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Daniele Procida]

On Mon, Dec 28, 2015, Samuel Bishop  wrote:

>I think the general concept would be covered by either creating a "fourth 
>division". So we would go from "topics", "reference", and "how-to", to 
>"topics", "reference", "how-to", and "implementation"/"internals"/"APIs"/etc
>Or enhancing the content in the reference section so that in addition to 
>our existing handwritten documentation, we expose the 'api-docs' tree as an 
>addendum to the reference section.

The main existing sections are:

* tutorials (/intro)

Tutorials take the new user by the hand through a series of steps. The 
important thing isn't to explain all the steps, but to achieve something useful 
with a minimum of effort. 

After every step of a tutorial, the user should have something that works, even 
if they barely understand what is happening (and it's not necessary for them to 
understand, that can come later. What matters is that they are successful).

* how-to guides (/howto)

How-to guides are recipes that take the user through steps in key subjects. 
They are more advanced than tutorials and assume a lot more about what the user 
already knows than tutorials do, and unlike documents in the tutorial they can 
stand alone.  

* discussion and explanation (/topic)

Aimed at explaining (at a fairly high level) rather than doing.

* reference (/ref)

Technical reference for APIs, key models and so on. It doesn't need to explain 
so much as describe and instruct.


I don't know who came up with this structure in Django, but whoever did got it 
absolutely right.

The structure doesn't confuse teaching with explaining, and understands why 
tutorials should be concerned with concrete and particular rather than abstract 
and general matters. It understands the difference between explaning how to 
achieve something and explaining how something works. And so on.

I think that the structure of the documentation as much as its content is what 
makes it so good, but also that it's structure is obvious - so I am surprised 
that not everyone finds it so obvious. If that's the case then I agree it 
should be made more explicit.

Daniele

-- 
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/20151229005216.254922486%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Not calling things twice in templates

[Daniele Procida]

The for ... empty pattern in templates is common and useful: 


But this is another common pattern:

{% if my_bonnet.bees %}

{% for bee in my_bonnet.bees %}
{{ bee }}
...

In other words, we have to check first for items in the iterable before 
creating a  or whatever other furniture to put them in.

The problem here is that my_bonnet.bees gets asked for twice, and it could be 
my.bonnet(), some very expensive function.

One solution is to put everything inside:

{% with my_bonnet.bees as bees %}

but now:

* we've used up a precious level of indentation
* we've introduced a new variable in the templates to worry about
* it just feels a bit fussy

Is this enough of an issue to make it worthwhile implementing some other 
approach in the template system?

Daniele

-- 
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: Not calling things twice in templates

[Daniele Procida]

On Mon, Jun 3, 2013, Russell Keith-Magee  wrote:

>> But this is another common pattern:
>>
>> {% if my_bonnet.bees %}
>> 
>> {% for bee in my_bonnet.bees %}
>> {{ bee }}
>> ...
>>
>> The problem here is that my_bonnet.bees gets asked for twice, and it could
>> be my.bonnet(), some very expensive function.

>Any other syntax I can think of requires introducing another indentation
>level. Have you got a specific suggestion for how to address this?

Not really. I wasn't even sure if would be considered much of an issue.

But I can think of two:

* introducing a template syntax that means "don't re-fetch"
 
perhaps: !my_bonnet.bees or: my_bonnet.bees.cached

I don't know if the latter would even be possible.


* managing it at the function level

The template author might not even know which functions are expensive. So 
perhaps it should be the function writer's responsibility to make take care of 
this:

@expensive
def bees(self):

which will tell the template system not to re-evaluate it while serving the 
same request.


I think I like this second suggestion better, because it keeps templates as 
simple as possible. And this way, the template author won't have to worry about 
keeping up-to-date with re-written functions that have become more expensive or 
less expensive.

Daniele

-- 
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: Not calling things twice in templates

[Daniele Procida]

On Tue, Jun 4, 2013, Andre Terra  wrote:

>I'm mostly concerned with ambiguous behaviour for the clauses which include
>other operands. For example,

Looking at the various solutions that have been proposed, I am not at all sure 
that this is something that the template author should have to deal with at 
all. 

Most of the suggested avenues seem to make the template-writing more complex, 
and the templates more full of important decisions about whether they want 
their code to touch the database in expensive ways, which is surely asking more 
of the template design process than is appropriate.

Also, the {% with expensive.method as variable %} way of doing things already 
exists, and doesn't seem more complex than the suggested alternatives.

What about my earlier suggestion that this be dealt with in Python, not in 
templates - that the Python programmer decides, for a particular method (or 
class, because I guess a class could have an expensive __init__()) whether that 
thing should be re-evaluated more than once per request, or per context?

Daniele


-- 
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: Meta-Proposal: Write *above* quotations in mailing list replies

[Daniele Procida]

On Tue, Jun 4, 2013, Yo-Yo Ma  wrote:

>If you're posting to this list by logging in to https://groups.google.com/ 
>rather than via email, I'd like to propose that you write your reply above 
>the quoted message to which you're replying. 

I think that would be a bad idea.

>The way it stands now, about half 
>of the messages that I can see (without clicking to the Google Groups 
>website) are just:
>
>> So and So said:
>>> This that the other
>>> and the other

That looks as though other people have been doing upside-down quoting too, but 
I'm not sure because I'm not sure what the digest does.

>Thoughts?

I propose the opposite:

* quote what needs to be quoted for context
* don't quote anything that doesn't need to be quoted
* replies to particular points go immediately below quoted material

This makes it easier to read and follow a thread, and is a far more comfortable 
way to understand who is saying what, and in reply to whom.

Daniele 

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

Explaining application instances

[Daniele Procida]

There are a couple of places in the documentation that refer to "application 
instances":




However, it's not really clear what an application instance is or why I might 
need to deploy multiple instances of one.

I think that's worth explaining in the documentation, especially since I have 
found a number of questions and discussions on the subject elsewhere.

I'd suggest that the explanation be incorporated in the URLs documentation.

Is the following largely correct:

* an application runs as an instance
* normally one doesn't need to worry about this
* sometimes though one might want to run an additional instance of an 
application
* one names the multiple instances through the "namespace" argument in a URL 
pattern
* URL reversing is the only reason we'd have for naming the multiple instances

I still don't quite see why one might want to run an additional instance of an 
application. If it's just to provide a different set of URLs for it, why not 
write some additional URLs to the views that the provide the different 
functionality?

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Explaining application instances

[Daniele Procida]

On Thu, Jul 11, 2013, Russell Keith-Magee  wrote:

>On Thu, Jul 11, 2013 at 3:57 PM, Daniele Procida  wrote:

>> I still don't quite see why one might want to run an additional instance
>> of an application. If it's just to provide a different set of URLs for it,
>> why not write some additional URLs to the views that the provide the
>> different functionality?

>The only use cases for "application instance" behaviours is where you've
>got an app that is configurable in it's capabilities, and you want to
>deploy two different capability configurations in the same URL space. It's
>an unusual edge case of usage, but it is one that Django supports.
>
>The best example I can give of an application instance would be using admin
>itself. Imagine a situation where you not only want to have access control
>on certain models of the admin, but you want to have different admin
>registrations. You have a Shopping Cart model with items in the cart; admin
>users can see all the details of the customer and what they've purchased,
>but sales representatives can only see a subset of fields on the cart. You
>could do this with two completely separate admin.site objects, with
>different ModelAdmin registrations, deployed at different URLs in your
>system.
>
>However, this doesn't involve a duplication of tables -- there's still only
>1 admin history table, which is used by both admin "instances".
>
>Does that explanation help at all?

Thanks, it does a bit! What about a non-admin example though? Would there be 
any case for that? Generally in an application if one needed to use the same 
tables and models but provide a different view upon them, one would simply 
create a view to do that, and the URL pattern to point to it.


Reading through the documentation some more, another matter arises.

Multiple application instances require namespacing. This could also be required 
when one wants to use - for example - {% url "archive" %} in templates, because 
you might have two different applications that both name patterns "archive". 

Perhaps you wouldn't choose to do this yourself, but if you're using other 
developers' reusable applications, you might find yourself in such a situation. 
So these applications ought to have their URLs namespaced. 

<https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces> 
doesn't actually give this as a reason for namespacing URLs (it only gives 
multiple application instances as a case), though 
<https://docs.djangoproject.com/en/dev/intro/tutorial03/#namespacing-url-names> 
does. 

So perhaps the resuable application case should be mentioned in 
<https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces> too. 


There's still a difficulty though. We can namespace URL patterns by using 
include() (I think this is the only way). 

This means that the namespacing becomes the responsibility of the including 
URLconf, likely the root project URLconf, whereas I might have created an 
application that I want to distribute, that has a pattern named "archive" and 
some templates or template snippets that make use of {% url "archive" %}. 

This will constrain anyone who uses my application and needs to namespace it to 
override all these templates, which could be tedious.

This isn't really a documentation issue, but perhaps the documentation could 
help address it by suggesting that authors use URL pattern name forms that 
aren't likely to be found in other applications.

I have created a ticket for this.

<https://code.djangoproject.com/ticket/20734>

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate admindocs?

[Daniele Procida]

On Thu, Jul 25, 2013, Aymeric Augustin  
wrote:

>I'd like to deprecate admindocs.

I love admindocs.

When I first started using Django, I would always find ready to hand, and the 
fact that it was right there, in the interface of the thing I was working with, 
really helped me build a picture in my head of the way the system worked 
together and what was available.

Particularly useful was the automatic linking to  related objects.

I refer to admindocs regularly still. There might be other ways to check for 
example what fields or attributes a model has, but I can't think of a quicker 
one, or one that automatically keeps itself up-to-date with the state of the 
model with no action required.

I'd hate to see it go.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Daniele Procida]

On Tue, Jul 30, 2013, Andre Terra  wrote:

>As for the reasons for disallowing negative indexes, dcramer's comment in
>the ticket makes it clear: there is no way to infer what the last item in a
>query would be, except if you order it descendingly. For what is worth,
>production code should never rely on any kind of indexing that's not
>accompanied by an explicit order-by clause, as the default ordering is
>unrealiable -- at least in PostgreSQL[2], and I assume in other vendors as
>well[3].

By "an explicit order-by clause" I presume you include the "ordering" attribute 
on the model?

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

django.utils.functional.cached_property

[Daniele Procida]

Is there any reason why django.utils.functional.cached_property should not be 
documented, so that it can easily be used?



I'd have a lot of use for it.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: django.utils.functional.cached_property

[Daniele Procida]

On Wed, Aug 7, 2013, Aymeric Augustin  
wrote:

>2013/8/6 Daniele Procida 
>
>> Is there any reason why django.utils.functional.cached_property should not
>> be documented, so that it can easily be used?
>>
>> <https://code.djangoproject.com/ticket/20870>
>>
>
>Yes, it's stable enough.
>
>The main drawback of the current implementation is that it's impossible to
>clear the cached value. That should be mentioned in the docs.

*Where* would be a good place to mention this?

There doesn't seem to be a single place in the documents for "handy decorators 
you might like". Perhaps there should be, with links to 
<https://docs.djangoproject.com/en/dev/topics/http/decorators/> for example.

There's 
<https://docs.djangoproject.com/en/1.5/ref/utils/#module-django.utils.functional>
 of course, but no-one would actually find it there unless they were already 
looking for it.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: django.utils.functional.cached_property

[Daniele Procida]

On Thu, Aug 8, 2013, Russell Keith-Magee  wrote:

>One suggestion -- a new special topic guide on performance tweaking



I'd like to take that on, if unless anyone else feels they should be 
responsible for it, since it will involve a certain amount of structural change 
in the documents.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

GZipMiddleWare documentation

[Daniele Procida]

What should the documents have to say on the subject now, in light of 
?



Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GZipMiddleWare documentation

[Daniele Procida]

On Sat, Aug 10, 2013, Russell Keith-Magee  wrote:

>I also have a nagging feeling in the back of my head that there have been
>questions raised about whether GZIPMiddleware should exist *at all* -- that
>there's some niggling detail in the WSGI spec that says that GZip
>compression should be applied at the web server level, not the WSGI level.
>Can anyone confirm if I'm hallucinating on this point? And if I'm not,
>perhaps we should just be deprecating GZipMiddlware?

There is this discussion:  which 
concludes that it shouldn't be deprecated because some versions of nginx 
( don't work with Etags 
and GZip as expected otherwise).

If that's because nginx doesn't behave properly, and the only reason for not 
deprecating it, then perhaps it should be renamed 
"GZipForMisbehavingBrowsersMiddleware".

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Performance optimisation documents, ticket 20877

[Daniele Procida]

Work in progress; comments appreciated: 


Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Usage and documentation of F()

[Daniele Procida]

I noticed while looking for material for 
 that 

 mentions that:

product.number_sold = F('number_sold') + 1

is faster than:

product.number_sold += 1
 
though this doesn't seem to be mentioned in the database optimisation page.

That's easy enough to address, and 

 seems like a sensible place for it.

However the mentions of F() that I did find raised a number of questions.

The F() class seems to be a handy general-purpose way to refer to the value of 
a model field..


Firstly, it's not explained how, in expressions like:

product.number_sold = F('number_sold') + 1

(from 
)
 Django knows that F('number_sold') is refers to the product model. 

Does it know because product.number_sold is the field that this expression 
refers to? What would happen if we did:

product.number_in_stock = F('number_in_stock') - F('number_sold)

(i.e. can we make such calculations multiple other fields in one go?), or:

product.number_to_reorder = F('number_sold)

for example? What are the rules of the usage syntax of F()?

Secondly, the main documentation for F() 

 doesn't mention this kind of use at all: it only suggests that it might be 
useful in queries.

Since this use seems to be just one of multiple uses for F(), shouldn't a more 
general description of F() belong somewhere else (where) instead?


Finally, are there any other useful ways to use F() not covered by these two 
examples?


Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance optimisations in the deployment checklist document

[Daniele Procida]

On Fri, Aug 16, 2013, Tim Graham  wrote:

>I don't think there's a reason to recommend one of the two cached sessions 
>backends over the other as the choice is application dependent, but +1 on a 
>link to 
>https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-
>sessions as 
>something to consider.

There should presumably also be a similar pointer to this topic in the general 
optimisation and performance documentation described in 
.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[Daniele Procida]

On Mon, Aug 19, 2013, Paul C. Anagnostopoulos  wrote:

>I'd like to contribute to Django by improving the "Built-in template tags 
>and filters" document. I forked the Django repository at GitHub. Then I 
>tried to clone it according to the instructions in "Working with Git and 
>GitHub." I received:

It sounds like you've resolved the issue you had, but you might find the 
Git/Github pages at 

 useful - they are the result of my having struggled through just the kind of 
problems you described.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Idiot makes mistake

[Daniele Procida]

I am so sorry, no sooner than I am entrusted with the commit bit I have managed 
to push -f to django/django instead of my  own fork, and God knows what kind of 
mess I have made.

I am covered in shame and swear never to use -f again.

So sorry, a million abject apologies.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

version number in Django documentation URLs

[Daniele Procida]

RTFD.org can use "latest" for the version number in docs - why don't we?

It would be nice to be able to refer for example to 
.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Django Trac ticket keywords

[Daniele Procida]

Would there be any objection if I used a keyword ("afraid_to_commit" or 
something) to mark tickets that I think would be suitable for first-time 
committers doing the "Don't be afraid to commit" tutorial to tackle?

That way I can provide a URL like:



that is always likely to return some suitable tickets.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: version number in Django documentation URLs

[Daniele Procida]

On Fri, Aug 30, 2013, Baptiste Mispelon  wrote:

>On 08/30/2013 12:10 AM, Daniele Procida wrote:
>> RTFD.org can use "latest" for the version number in docs - why don't we?
>>
>> It would be nice to be able to refer for example to docs.djangoproject.com/en/latest/internals/release-process/>.

>https://docs.djangoproject.com/en/stable/internals/release-process/ 
>works, but I'm not sure that it's documented anywhere.

Yes, that's exactly what I was looking for, thanks!

Would it be possible to add "beta" too, or would that always be the same as 
"dev" anyway?

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Trac ticket keywords

[Daniele Procida]

On Fri, Aug 30, 2013, Russell Keith-Magee  wrote:

> Is "afraid to commit" a different set of criteria to "easy pickings"? The
>original intention was that the easy pickings checkbox would be populated
>with tickets that were appropriate for first timers (because they were
>relatively simple in scope).

Yes - it's something like "really incredibly easy pickings"!

Some of them are even slightly artificial, things that one wouldn't normally 
raise a ticket for - a typo in the documentation for example - but having a 
ticket makes it easy for someone to go through the whole issue-fixing workflow 
without running into complications when they do it for the first time.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

django.utils.functional documentation

[Daniele Procida]

There are caching/laziness-related functions and classes in 
django.utils.functional, but none seem to be documented (apart from 
cached_property which has documentation forthcoming).


django.utils.functional.memoize

Caches the output of a function in a dictionary. Could this be implemented as a 
decorator, and if so, would that be a more elegant way to make use of it?


django.utils.functional.lazy

Makes a callable lazy. Could this also be implemented as a decorator? And could 
a function be both memoized and made lazy?


django.utils.functional.allow_lazy

A decorator that makes a function respect the laziness of its arguments - if 
it's called with lazy arguments, it will itself become lazy.


django.utils.functional.LazyObject
django.utils.functional.SimpleLazyObject

Wrappers to make classes lazy. The difference between them is that when the 
wrapped classes are finally instantiated, the former makes it possible to 
manipulate the instantiation. The difference between these and 
django.utils.functional.lazy:

* lazy() can be applied to any callable, not just objects
* lazy() needs to know in advance what type the resulting items will be, 
whereas these don't


django.utils.functional.Promise
django.utils.functional.curry
django.utils.functional.lazy_property

I can't work out what these are for. Are they things that ought to be 
documented?


Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GZipMiddleWare documentation

[Daniele Procida]

On Fri, Aug 9, 2013, Daniele Procida  wrote:

>What should the documents have to say on the subject now, in light of
><https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/>?
>
><https://code.djangoproject.com/ticket/20887>

I'm rasising this issue again, because our documentation still suggests using 
GZipMiddleware and doesn't offer any warnings; I'd submit a pull request 
updating the documents, but I don't know enough about the subject to know what 
it should actually say.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance optimisation documents, ticket 20877

[Daniele Procida]

On Sat, Aug 10, 2013, Daniele Procida  wrote:

><https://code.djangoproject.com/ticket/20877>
>
>Work in progress; comments appreciated: 
><https://github.com/django/django/pull/1463>

Any further comments would be welcomed. There's some disagreement about the 
appropriateness of the last section, 
<https://github.com/django/django/pull/1463/files#L5R318> so it would be 
particularly usefukl to have some further opinion on that.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance optimisation documents, ticket 20877

[Daniele Procida]

On Fri, Sep 13, 2013, Florian Apolloner  wrote:

>On Friday, September 13, 2013 4:18:05 PM UTC+2, Daniele Procida wrote:
>>
>> Any further comments would be welcomed. There's some disagreement about 
>> the appropriateness of the last section, <
>> https://github.com/django/django/pull/1463/files#L5R318> so it would be 
>> particularly usefukl to have some further opinion on that. 
>>
>
>Personally I'd remove it completely for the following reasons:
> * Especially newcomers tend to think that they need the most performant 
>system
)
> * This dual-import of libraries where you try to select the most 
>"efficient" versions quite often results in issues for those versions which 
>didn't get used by the developer

I've re-written that section now to emphasise the caveats and the need to 
verify improvements, and to de-emphasise the prospect of exciting perfromance 
gains.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance Docs

[Daniele Procida]

On Fri, Sep 20, 2013, Alex Gaynor  wrote:

>I didn't follow this PR as it was in progress, but I just sat down and read
>them. I have to say I'm extremely saddened by
>https://docs.djangoproject.com/en/dev/topics/performance/#alternative-
>software-implementations.

See if  is less 
saddening then.

If not, can you suggest something that would work in the context of a document 
that's really intended to be an overview for users not already experienced in 
these matters (and in particular, ones who may be tempted to think "Python's 
slow! I need something faster").

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

IRC users invited to support PyCon UK Django sprinters

[Daniele Procida]

At the Don't be afraid to commit workshop at PyCon UK today there were a lot of 
attendees 

 (31 of them). 

Many of them said they'd come to the Django sprint tomorrow (Monday 23rd 
September), which runs 1000-1230 and 1330-1600 UTC+1. 

If anyone can be in #django-sprint to help out that would be very nice indeed.

Thanks,

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: IRC users invited to support PyCon UK Django sprinters

[Daniele Procida]

On Mon, Sep 23, 2013, Daniele Procida  wrote:

>At the Don't be afraid to commit workshop at PyCon UK today there were a
>lot of attendees <http://dont-be-afraid-to-commit.readthedocs.org/en/
>latest/attendance_record.html#pycon-uk-in-coventry-22nd-september-2013>
>(31 of them). 
>
>Many of them said they'd come to the Django sprint tomorrow (Monday 23rd
>September), which runs 1000-1230 and 1330-1600 UTC+1. 
>
>If anyone can be in #django-sprint to help out that would be very nice indeed.

I just want to say thanks to everyone who helped the sprinters (or even just 
popped in to say hello) on IRC, but especially Tim Graham, who was there 
throughout the day and really helped make it a success.

It was an excellent sprint. We had 14 people involved, and I think all of them 
were were first-time Django contributors. Several were people who had very 
little experience of this at all (many installed Git and set up GitHub accounts 
for the first time yesterday in the workshop), but today several pull requests 
were made and merged:

<https://github.com/django/django/commit/c81b6f7b834da8d8fbcf679679ce158173df3a05>
 
<https://github.com/django/django/commit/98e0453f00958af63b50e70990903eb6a04e1933>
<https://github.com/django/django/commit/6a30075eaa52b3d91665195a34901ac450df5bbb>
<https://github.com/django/django/commit/a53caf28bf2ab29cf4e78a968b3887ddb6d6e83d>
<https://github.com/django/django/commit/41167645b1039067127fa215d4d28296bfa4cfdc>
<https://github.com/django/django/commit/e15f7f31d048ead5453b5ee810235cf88b42b3cc>

there's one open pull request:

<https://github.com/django/django/pull/1662>

and I think a couple more people at least are still working on theirs.

Having friendly strangers on hand in the IRC channels made their first 
impressions of the Django community a very good one. There was a very positive 
(and excited, once people started getting close to making pull requests) vibe 
at our table, and some of the sprinters were beaming with delight after their 
pull requests were merged.

I was taken aback when I saw how many people had turned up for the workshop on 
Sunday 
(<http://dont-be-afraid-to-commit.readthedocs.org/en/latest/attendance_record.html#pycon-uk-in-coventry-22nd-september-2013>
 - over 30 of them), but in fact I think it was the most successful one so far.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Hyperlink CSS on djangoproject.com

[Daniele Procida]

On djangoproject.com and the docs in particular, we don't underline hyperlinks, 
though we do, with dots, if it's a hyperlink to a class or function or module.

That means users need to rely on the colour of the text to determine whether 
something is a link or not. 

It works fine for me, but I don't know how well it will work for colourblind 
users (I tested it using a simulator - 

 and it wasn't actually too bad in that).

Is there any reason not to have all links underlined, in the interestes of 
improved accessibility?

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Hyperlink CSS on djangoproject.com

[Daniele Procida]

On Tue, Sep 24, 2013, Marc Tamlyn  wrote:

>As someone who has color blindness (off the top of my head I can't remember
>the exact condition, but it's not simple red-green that 1 in 8 men have) it
>looks fine to me. Personally I like the distinction between the external
>and internal links.

It's not so much between internal and external links, but between links to 
documentation topics (orange, not underlined) and links to Django objects 
(green, underlined).

>My guidance for people is generally that if you aren't using the actual
>colour to denote meaning (eg Red is bad), and the colours still appear
>different in monochrome, then chances are everyone can see it OK. Maybe not
>as clear as you, but OK enough.

Yes, the contrast between links and documentation topics links (i.e. not 
underlined) seems OK, even though they are less obviously links.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

A policy on calling super()

[Daniele Procida]

There's some discussion of a particular class, django.views.base.View, and 
whether its __init__() should contain a super(View, self).__init__().

But there's also a wider question of whether there should be a general rule 
about this, whether the integrity of the __init__() chain should be maintained, 
and whether it matters that not all of our classes that are likely to be 
subclassed do it.

Any comments?

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

IRC users invited to support PyCon Ireland Django sprinters

[Daniele Procida]

I'm running a "Don't be afraid to commit workshop" at PyCon Ireland. The 
sprints will be on 14th to 15th October - 
.

Last time it worked brilliantly well having a few active people in 
#django-sprint. If anyone can be around for the next one, that would be 
wonderful.

Thanks,

Daniele

-- 
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/20131003160004.574033262%40smtp.ntlworld.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Design discussion: admin alert messages

[Daniele Procida]

On Tue, Oct 8, 2013, Ryan Allen  wrote:

>Good thought, I'll get some color test screenshots put together today.

I've used  which I thought was quite good, but 
perhaps you know of better ones.

Daniele

-- 
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/20131008133736.887872701%40smtp.ntlworld.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal to end the war with flake8 warnings

[Daniele Procida]

On Wed, Oct 9, 2013, Tim Graham  wrote:

>Our docs currently state: "Note, however, that patches which only remove 
>whitespace (or only make changes for nominal PEP 8 conformance) are likely 
>to be rejected, since they only introduce noise rather than code 
>improvement. Tidy up when you're next changing code in the area." I 
>somewhat disagree, I think it's better to make cleanups in separate commits 
>so that when looking at a commit, you don't need to figure out what changes 
>are stylistic and what changes are needed for the fix.

I certainly agree with this.

Daniele

-- 
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/20131009192201.149641%40smtp.ntlworld.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Introduction

[Daniele Procida]

On Sat, Oct 12, 2013, Jasvir Singh  wrote:

>I am Jasvir Singh, a student of Computer Science.
>5-6 months ago, I started working on django and found it is a really
>efficient tool.
>Now I want to do some development for django.
>
>Can anyone please suggest me some task/project to do.

Hi Jasvir. If you'd like to contribute to Django itself, why not have a look at 
the ticket tracker: ?

In particular you might want to choose something straightforward to begin with, 
so look for tickets marked as "easy pickings": 
.

>May I start with making some video tutorials, in which I'll explain
>how to make a poll or blog application?

That too could be a valuable contribution to the community, though it will 
probably be more work, and will probably benefit fewer people.

You have probably already done so, but if not, take a look at 


Regards,

Daniele

-- 
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/20131012142338.1774804393%40smtp.ntlworld.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Nginx and Ubuntu Service Define

[Daniele Procida]

On Mon, Oct 14, 2013, Muhammed TÜFEKYAPAN  wrote:

>I use digitalocean as a server. I upload my django project files on my 
>server and start to setup. Made postgresql settings etc but I can't define 
>my new project as a new service on nginx. How can I define my new projest 
>as a service and make possible to start it as "service blabla start". 
>
>When I type "service --stat?s-all" I can't see my new project now. 

Hi Muhammed. Your best bet for an answer is the django-users email list, 
 - the web interface is 
. 

The django-developers email list is for the discussion of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net, and 
the #nginx channel is helpful too but I am not sure if that's where your 
solution will lie.

Good luck!



-- 
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/20131014173442.620435032%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ImportError: cannot import name actions

[Daniele Procida]

On Tue, Oct 15, 2013, rok  wrote:

>I have recently been testing the 1.6b4 tag with a new app we are
>writing, using apache and wsgi. However, I could not get rid of the
>following issue happening on every request:

You'll be better off asking this question over on the Django users email list, 
rather than here (this list is for the development of Django itself, rather 
than general usage or deployment questions).

You can sign up to the django-users list at 
.

The #django IRC channel on IRC (on irc.freenode.net) is also very helpful.

Daniele

-- 
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/20131015151136.1292469435%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ImportError: cannot import name actions

[Daniele Procida]

On Tue, Oct 15, 2013, rok  wrote:

>I thought since the 1.6 release is in the final stretch this might be 
>somewhat related to bugfixing. I posted it to the users forum.

Well it could indeed be a bug of course. Is it feasible for your to reduce it 
to something easily reproducible?

Daniele

-- 
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/20131015172645.879459680%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: An argument against mark_safe.

[Daniele Procida]

On Wed, Oct 16, 2013, Jonathan Slenders  wrote:

>Some people still have javascript in their templates and they use template 
>tags inside their javascript. :(

I am not sure if you're saying this is a bad thing, but it is unavoidable, 
isn't it? For example I use the Google Maps API, and I don't know of any other 
way to generate the map items dynamically than to build some of the JS for it 
using template tags. Is there a problem doing it like this, and is there a 
better way?

Daniele

-- 
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/20131017080600.1363122391%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Help related executing system command from django

[Daniele Procida]

On Thu, Oct 17, 2013, Jorge Cardoso Leitão  wrote:

>I suggest you to post your question in the django-users mailing list.
>This mailing list is for the development of Django itself.

The django-users list can be found at 
.

The #django IRC channel on IRC (on irc.freenode.net) is also very helpful.

Daniele

-- 
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/20131017103116.1382276699%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Django logo usage terms self-contradiction

[Daniele Procida]

"Additional text may not be added so that it appears to be part of the logo."

 section 3.2:

"A group or event may use a logo that incorporates the Django logo by adding a 
word or picture [...]"

Also, there appears to be no section 3.1 on the latter page.

Daniele

-- 
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/20131017135509.1987695617%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django logo usage terms self-contradiction

[Daniele Procida]

On Fri, Oct 18, 2013, Russell Keith-Magee  wrote:

>Thanks for the heads up. The first piece of text you've indicated predates
>the second, so it needed to be updated. I've just made the change.
>
>As for there being no Section 3.1 -- I'm not sure what you're referring to
>here. I can see a Section 3 that contains 2 subsections, numbered 1 and 2;
>section 3.1 has 6 subclauses 3.1.1-3.1.6.

That's changed! 

Earlier today there was no list marker "1." for the  "You may incorporate 
the Django name into the name of any group or event, provided that:"

Maybe the re-rendering of the page restored it.

Daniele

-- 
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/20131017230651.851306701%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Creating a minimal custom user model. Seems last_login is required. Should it be?

[Daniele Procida]

On Sun, Oct 20, 2013, Harry Percival  wrote:

>I'm trying to create a minimal custom user model.  The only thing I care 
>about is email.  But it seems Django really wants me to set a last_login 
>field.  Can I avoid it somehow?
>
>I don't care about last_login!  Can this be circumvented?  Should that 
>signal be optional, or gracefully handle the case where the user model has 
>no last_login field?  Should I log this as a bug?

I can reproduce this. I can't think of a good reason why a User absolutely must 
have a last_login, so please raise a ticket.

You're probably aware already, but the User model as provided here also breaks 
the superuser creating process called by syncdb. It doesn't ask for a username, 
and goes straight to asking for an email address, at which point it raises an 
error: AttributeError: 'Manager' object has no attribute 'get_by_natural_key'. 
I don't know if you were expecting that.

The full traceback is .

Daniele

-- 
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/20131020224826.2047120542%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Creating a minimal custom user model. Seems last_login is required. Should it be?

[Daniele Procida]

On Mon, Oct 21, 2013, Tino de Bruijn  wrote:

>@Harry, just out of curiosity, may I ask how you *do* authenticate your
>users?

I think he challenges them to a sword fight with rolled-up umbrellas.

Daniele

-- 
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/20131021141029.1537145532%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/groups/opt_out.

Re: When to use single quotes and double quotes

[Daniele Procida]

On Sun, Oct 27, 2013, Zach Borboa  wrote:

>I'm seeing a mix of both singly- and doubly-quoted strings in django source.
>Other than docstrings wrapped in triple-double-quotes, when is it 
>appropriate
>to use double quotes instead single quotes?

As far as I understand it doesn't make any difference in Python, but apart from 
cases where what you use is dictated by the context (for example, a string with 
an apostrophe in it needs double quotes) I've wondered the same myself about 
what's preferred in Django.

Should our documentation examples prefer one rather over the other?

Daniele

-- 
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/20131027212242.1056773858%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Want create patch for smth

[Daniele Procida]

On Thu, Oct 31, 2013, Dmitriy Dmitrienko  wrote:

>My name is Dmitry. I want to create patches for smth , because in my 
>university a teacher wants to create patches for the Moodle system, but i 
>hate moodle and i don't have a choice and it's wrong.
>I am not genius of programming, but i was write two project on django.
>P.S. Not start project from documentation of django :)
>
>Have you got any issues to help me? :)

Hi Dmitriy.

Take a look at the Django issue tracker, .

You might prefer to start with tickets marked as "easy pickings": 
.

If you haven't done so already, you'll need to read the documentation on 
contributing  
and especially 
.

As well as this list, there's the #django-dev channel on irc.freenode.net for 
discussing development of Django.

Thanks,

Daniele

-- 
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/20131031141321.100879823%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django-Should I be here?

[Daniele Procida]

On Sun, Nov 3, 2013, zobcl...@gmail.com  wrote:

>I need a web application to do the following:
>
>1. Authenticate a user (approx. 500 users) then show the user a list of 
>registered devices within the servers dhcpd.conf file. 
>
>2. Offer the user the option to delete an existing device.
>
>3. Offer the user the option to add a device 
>  - under this option I would like to set parameters of the dhcpd.conf 
>file in the background to "USER-device-HOSTGROUP" or something of that 
>nature. 
>  - A place for users to enter their MAC addresses
>
>4. and finally submit their request. Upon submit, the request would be 
>aggregated as per the parameters, appended to the dhcpd.conf file, and the 
>isc-dhcpd-server would be reset "applying" the changes 
>requested.
>
>Is Django the place for me, using python?

Yes, there's no reason you couldn't use Django to write such a web application, 
especially if you already have some familiarity with Python. 

I suggest starting with the Django tutorial: 
 which will quickly 
give you an idea of how several parts of your project might be tackled using 
Django.

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20131103174359.2095291105%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Django Weekend Cardiff

[Daniele Procida]

(With apologies if you have already seen this on another email list or 
newsgroup.)

The UK's first-ever Django conference will take place on the 7th-9th February 
2014 in Cardiff, Wales.



The programme for the event:

Friday: tutorials and demonstrations (also open to the public)
Saturday: talks
Sunday: code sprints and clinics

The conference is Django-focused, but all of all aspects of Python fall within 
its remit - particularly in the tutorials and workshops.

A venue has been booked at Cardiff University.

Registration and ticket sales will open soon, as well as a call for papers.

To be a success, the conference needs the support of:

*   people in Wales, the UK and beyond who will participate as attendees or 
volunteers
*   speakers who'd like to give talks or conduct tutorials
*   organisations locally and internationally willing to provide sponsorship or 
other support

If you can offer support in any of these capacities, please get in touch.

One of the aims of the conference is to establish it as an annual event that 
will raise the profile in Wales of open-source software in general and  Python 
in particular, and also bolster the local open-source software community here. 

Above all, however, the intention is to establish the Django Weekend in Cardiff 
as a meaningful and enjoyable date in the Django/Python calendar.

We'll publish updates on our website, our Twitter account 
 and elsewhere as appropriate.

Daniele

-- 
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/20131113231020.876400118%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to install Django?

[Daniele Procida]

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20131204130245.117094488%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django admin, 'Save as new' option, duplicate m2m relations

[Daniele Procida]

On Tue, Dec 10, 2013, Gheorghe Chirica  wrote:

>I have a simple model which have few m2m relations.
>
>Now, I enabled option in admin panel to duplicate model so, "Save as new" 
>option.
>
>It saves my model as a new one, no problem  with that.
>
>But I want to duplicate m2m relations I have for original model, so new 
>model will have new m2m relations inserted.
>
>I don't need the new model object to refer the same m2m as original one, 
>because when I "save as new" I change some data
>
>and I need new entries for this m2m relations.
>
>
>Can someone guide me how can i achieve this and where to look for it.

Hi Gheorghe. You'll get answers to your questions on the django-users email 
list,  - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20131210123409.1972123618%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Daniele Procida]

On Thu, Apr 3, 2014, Carl  wrote:

>As someone said earlier in the thread, making Python programmers deal with 
>long lines seems like some special form of torture ;)

My own use case is this:

{% with placeholder_width=960 generic_main_width=523 
sidebar_image_size="294x196" entity_image_size="445x384" 
entity_map_size="445x100" person_map_size="445x100" sidebar_map_size="296x100" 
person_image_size="460x460" person_thumbnail_size="40x40" 
lightbox_max_dimension=600 plugin_thumbnail_size="75x75" 
place_image_size="627x418" place_map_size="294x182" body_heading_level=2 %}

Now that's very horrible to read.

This would be much nicer:

{% with 
placeholder_width=960 
generic_main_width=523 
sidebar_image_size="294x196" 
entity_image_size="445x384" 
entity_map_size="445x100" 
person_map_size="445x100" 
sidebar_map_size="296x100" 
person_image_size="460x460" 
person_thumbnail_size="40x40" 
lightbox_max_dimension=600 
plugin_thumbnail_size="75x75" 
place_image_size="627x418" 
place_map_size="294x182" 
body_heading_level=2 
%}

And yes, there is a good reason for wanting to use {% with %} in this way!

Daniele

-- 
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/20140403141333.1946415207%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/d/optout.

"Master/slave terminology" (was: Master/slave trolling pull request accepted to django master branch)

[Daniele Procida]

On Tue, May 27, 2014, Meira  wrote:

>As some of you may have notice, a hot discussion is happening in the 
>comments of this pull request: https://github.com/django/django/pull/2692

If by "hot discussion" you mean silly pictures and noisy accusations...

There is a discussion to be had about this subject, which is why you were 
invited to start one.

You're clearly very angry about it, I don't know why, but if you'd like other 
people to participate in your discussion I suggest you stop making uncivil 
remarks in it - like "trolling" and "insane" - and state your case in a way 
that makes people feel like discussing it with you.

Please understand that if you're not able to moderate your own tone, you will 
not be permitted to post to this email list.

Daniele

-- 
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/20140527123513.196257966%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: "Master/slave terminology" (was: Master/slave trolling pull request accepted to django master branch)

[Daniele Procida]

On Tue, May 27, 2014, Meira  wrote:

>Sorry, I accidentally sent a private reply :) I'll try to repeat it here 
>for others.

I have replied, privately, but I wanted to add publicly:

>The community is trying to protect the django project from the attack of 
>people who seek no good for django. Please stop the confrontation, this 
>will not help anyone. The feedback from the community is the most valuable 
>thing django has, do not ignore it.

We won't - I promise. The feedback - even when it's expressed testily or in 
exasperation - is not just appreciated, but received gratefully. The same goes 
for patches or contributions, *including the ones that are not accepted*.

The Django Project and the Django community are not in my mind two different 
things.

>Calling me angry, uncivil, referring to my way of putting things as 
>inappropriate, suggesting that my tone might disengage people - those are 
>signs of your own anger, if I may suggest. I made no assumptions about you 
>personally or any other of the django maintainers, and I would appreciate 
>if you adopt a similar approach.

You are right and I apologise for making those remarks.

Daniele

-- 
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/20140527134354.57359246%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: "Master/slave terminology" (was: Master/slave trolling pull request accepted to django master branch)

[Daniele Procida]

On Tue, May 27, 2014, Meira  wrote:

>> This second commit was discussed in a Trac ticket and everyone (even you!) 
>> was welcome to give their opinion. 
>>
>
>That's all nice and good, but why is the discussion taking the course of 
>whether or not we're accepting the second commit? It is clearly better than 
>the first. The question is, why the first commit was accepted. 

A human being saw the patch, made the judgement in good faith that it should be 
accepted into core, and merged it.

I don't really see why you say that "why" is the question - it doesn't seem a 
very important one.

Daniele

-- 
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/20140527154651.1054375592%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: "Master/slave terminology"

[Daniele Procida]

On Tue, May 27, 2014, Andromeda Yelton  wrote:

>Which is a little beside the point as the process for merging PRs is not,
>in fact, democracy.  But is also fantastic, because I've spent the last
>week reading TRAC and hanging out here and talking to lots of people trying
>to figure out if Django will be a safe place for me to contribute.  And
>when I see that large a fraction of commenters come down on the side of
>inclusivity, I feel like "django developer" is a hat I can put on.

If we get a single more person contributing to Django as a result, I would 
consider this whole episode as being entirely worth it.

Not that I think it's a sustainable strategy in the long term, of course.

Daniele

-- 
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/20140527165404.1260764507%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Master/slave trolling pull request accepted to django master branch

[Daniele Procida]

On Tue, May 27, 2014, Meira  wrote:

>Black people refer to themselves "a person of color", and then even shorten 
>it: PoC. Isn't that a ridiculous acronym? If I were black, I would be 
>deadly offended if someone dared to call me "a person of color"!

You're not black though, and if some black people refer to themselves as 
"persons of colour", the very least you can do is not call that ridiculous.

That is not within the bounds of the courtesy you're expected to maintain while 
in this community.

Daniele

-- 
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/20140527175436.628126548%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Using Exisitng Database on PhpMyAdmin with Python and Django

[Daniele Procida]

On Sat, May 31, 2014, Olouge Eya Ekolle  wrote:

>How can I connect my existing MySQL database created on XAMPP to my 
>Python/Django project? 

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20140531080243.747386602%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Ready for checkin

[Daniele Procida]

"Ready For Check-in" appears in the docs once; "Ready for Checkin" appears five 
times, and on Trac.

Can we change it universally to "Ready for check-in"? Or better "Ready for core 
team review"?

What's wrong with "checkin":

* it's incorrect
* I've more than once read it and imagined it must be a mispelling of "checking"
* it looks like it might be the name of a town in the Balkans

But also it's not immediately obvious what "checkin" (or indeed "check-in") 
means; it sounds like it might involve formally accepting something into the 
system, and so I'd actually prefer something like "Ready for core team review".

Daniele

-- 
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/20140616160827.428367890%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Ready for checkin

[Daniele Procida]

On Mon, Jun 16, 2014, Greg Chapple  wrote:

>Would "Ready for merge" not be a more appropriate term? 

Well no - because it isn't ready for merge. It may well be far from ready. 
Ironically "ready for checking" is closer to the intended meaning.

Daniele

-- 
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/20140616221046.263782193%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Problem in doing Calcultion in django Application

[Daniele Procida]

On Wed, Jun 18, 2014, Muskan arora  wrote:

>I have a problem in calculating Sum.
> my models.py is as follows :-

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20140618072715.393510291%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: django less compilation to empty css

[Daniele Procida]

On Wed, Jul 9, 2014, Muneeb Ahmed  wrote:

> I have gone through a no of tutorials but cant able to compile less to css 
>What is the best technique to compile less to css in django. (Static 
>precomiler, yui, e.t.c)

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele


-- 
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/20140709122523.641583910%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: deprecate contrib.webdesign? (#22789)

[Daniele Procida]

On Fri, Jul 11, 2014, Tim Graham  wrote:

>It provides the lorem template tag. The functionality has not changed in 7 
>years and it has 20 commits in its history which are mostly maintenance 
>oriented (pep8, adding app loading compatibility).

As long as it's not getting in anyone's way, and is not imposing a maintenance 
burden, I would simply leave it alone as much as possible.

There's bound to be someone who loves it dearly and uses it regularly. Let's 
not spoil their day!

Daniele

-- 
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/20140711154029.739072391%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: querry to pass jquery variable value to django template, please responce me need help one of yours...

[Daniele Procida]

On Fri, Aug 1, 2014, Jaiprakash Singh  wrote:

>unfortunately, i am not able find the solution, so require some hints from 
>all of  u guys

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

-- 
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/20140801130123.447258122%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Daniele Procida]

On Thu, Aug 7, 2014, Schmitt, Christian  wrote:

>Currently we already live in a world were everything gets connected. And
>that is really awful. One must consider that Github is definitely a target
>for intelligence agencies. And I don't mean the NSA only.
>Maybe I'm a little bit too paranoid but at the current state of the
>internet we shouldn't try to connect everything, just it is easier to login.

The purpose isn't to make it easier to login - it's to make it harder for 
people to flood Trac with spam. Maintaining that is a real pain in the neck. 

This isn't just about convenience, it's about a significant quantity of work 
just to clean up other people's abuse and to keep the system reasonably clean.

If someone has the time and energy to keep Trac free of spam, that would be a 
solution - but I'd prefer to find a solution that didn't waste valuable human 
time and energy.

Daniele

-- 
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/20140807125600.987319572%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: proposing max line length of 119 + enforcing it with flake8

[Daniele Procida]

On Wed, Sep 3, 2014, Tim Graham  wrote:

>The biggest hurdle is cleaning up the existing code as we currently have 
>~1700 lines longer than that. I attached an initial patch on the ticket to 
>show how long strings can be restructured. If there is no objection, 
>perhaps I can work with some afraid-to-commit workshop participants 
>to divvy up the work. flake8 fixes were a big hit last time.

Sounds like a great idea, and an ideal thing for workshop participants to 
tackle (I have already marked the ticket, as you've probably noticed).

As for the actual length, 119 seems - for now, though who knows when GitHub 
will change their limits - sensible.

Thanks,

Daniele

-- 
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/20140903213028.1622677876%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation tool

[Daniele Procida]

On Fri, Sep 5, 2014, Daniel Chimeno  wrote:

>I'm looking for a documentation tool for my django project.
>Something like JavaDoc or PHPDoc, to be able to generate a HTML|PDF with the
>models, views, urls..
>I've used sphinx to non-related Django projects, but I've never tried with 
>Django.

Hi Daniel.

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

Having said that, Sphinx is an excellent tool for DJango docs.

I hope that helps,

Daniele


-- 
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/20140906134014.702603677%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

[Daniele Procida]

On Sun, Sep 7, 2014, Benjamin Scherrey  wrote:

>Number 84 sounds fine. #86 is just looking for trouble. You were wise in 84
>to keep it positive and not enumerate a list of "banned" behaviour. To have
>86 be anything beyond providing a weapon to be used by anyone looking to be
>"victimized" in order to silence those whom they disagree with, you would
>have to absolutely list the behaviours you don't want to tolerate. Frankly
>84 is about toleration and acceptance whereas 86 can do nothing but
>increase intolerance ultimately.

The only change of substance in 
 is the addition of one 
sentence:

In addition, violations of this code outside these spaces may affect a 
person's ability to participate within them.

which is the case already - this just makes it explicit.

"May affect" give us plenty of scope for a measured and proportionate response 
- it may just mean we watch them more carefully.

Daniele

-- 
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/20140907142424.1464951136%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

[Daniele Procida]

On Mon, Sep 8, 2014, Benjamin Scherrey  wrote:

>Nothing you've written disagrees with what I said, nor do you address
>the core concern I bring up about the "change of substance" which is chock
>full of opportunities for the law of unintended consequences to come up and
>bite us all. 

What in your opinion is (or was) the "change of substance" in 
?

I didn't see any but a very minor one, that only makes explicit something that 
was already the case.

>Re-reading the existing documents, I find that this language
>introduces an entirely different tone to the language of these policies
>and, again, implies some dangerous precedents beyond what the writers may
>intend.

Which language in pull request 86?

Daniele

-- 
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/20140907200417.1287303773%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

[Daniele Procida]

On Mon, Sep 8, 2014, Benjamin Scherrey  wrote:

>I thought I made my objections pretty clear in my original email but I'll
>attempt to be more pedantic about it now. The specific language in the PR
>86 is:
>
>"In addition, violations of this code outside these spaces may affect a
>person's ability to participate within them." for both faq.html and
>index.html.
>
>I disagree with your assertion "that only makes explicit something that was
>already the case" because that's a) not how I read it and b) completely
>impossible to reasonably enforce or expect.

I can assure you that if we became aware of someone's problematic behaviour 
then depending on the behaviour we could do anything from keeping a careful eye 
on the individual to - in extreme cases - banning them from participation.

"Violations of this code outside these spaces may affect a person's ability to 
participate within them" is correct. It doesn't mean that action will be taken, 
but that it may be.

That's already the case. If a known harrasser subscribes starts posting to one 
of our email lists, we might have a quiet word with them, just for example.  

>I hope that what is occurring is
>simply a matter of "I don't think it means what you think it means" but
>what you're really saying here is that all people on this planet must
>comply with our "code of conduct" at all times in all places or risk being
>removed from our community - right after, mind you ironically, claiming to
>support an encourage the participation of all individuals. 

Being removed from the community would be the last, not the first, course of 
action.

>So what is this
>code of conduct that we're imposing on all of humanity for the salvation of
>the world?

You've had your points answered twice already, politely both times. If you want 
to make sarcastic remarks for your own amusement, don't expect any more replies.

Daniele

-- 
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/20140908115639.2110009050%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Daniele Procida]

On Tue, Sep 9, 2014, Russell Keith-Magee  wrote:

>As a matter of formality, I'd like to put this through the technical board
>so that it isn't just a fiat decision by the handful of people motivated to
>participate in this discussion.

By the way, there are three related pieces of information (in Manage > 
Information > General information):

Group name: Django developers

Group email address: django-developers (can't be changed)

Group description: Discussion group for Django developers. This group is used 
for discussion of developing Django itself, not user questions; Please use 
django-users for issues regarding using the framework, questions for the Django 
user community outreach, etc.


The description's the easy one, but I don't think it's going to make a huge 
amount of difference. I doubt it's what catches people's attention. I'd suggest 
something shorter like:

Discussion group for the development of Django and contribution to the 
project. For questions about and help with Django, please use 
django-users.

The group name is the problematic one. If it matches the email address; it's 
misleading; if it doesn't, it's confusing.

Daniele

-- 
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/20140909080110.1041430080%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.