Re: Proposing development discussion forums

[Lee Trout]

I’ve moderated a couple small-medium forums (2k-8k) members as well as
participated in many online.

I am in favor of moving to a forum system for a lot of reasons. I’d be
curious who would be the community manager(s) (not moderators per se) and
if the tone would be similar to the docs and wiki or closer to the IRC
channel and a bit relaxed. It is potentially an opportunity to curate a lot
of great community information similar to the PyCoders newsletter with
advanced tutorials, QA on popular third party libs like storages or getting
started with the  cookiecutter layout.

I agree with James- it will take a moderation team and some manual work to
keep it moving smoothly.

I know PHPBB is the de facto board system but I’ll toss out a hat tip to
XenForo.com. It’s in use for Advrider.com and performs very well.

On Mon, Aug 12, 2019 at 5:04 AM James Bennett  wrote:

> I'm not necessarily opposed to this, but I am a bit skeptical of the
> long-term archival utility of forums, in large part due to my experience as
> a moderator of some decent-sized ones. I think making them useful for that
> purpose is going to require about the same level of manual curation as,
> say, the wiki on code.djangoproject.com does now.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg_L-seA-6AiAdHctheUcqoM5gzqS_ZrbwcCQ_d%3DGo3%2BNQ%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAABi-DqZsxY_oQHb_dQB7%2BVOxo3SxWMXC1gQmYC2WMDZJ60tOQ%40mail.gmail.com.

Re: request for correct django documentation

[Lee Trout]

That is correct. It is deprecated now (2.2) and will stop working in 3.1.

More info is available at
https://docs.djangoproject.com/en/dev/internals/deprecation/

Lee

On Thu, Jul 25, 2019 at 7:24 AM sajjad Hassanzadeh 
wrote:

> in https://docs.djangoproject.com/en/2.2/topics/db/aggregation/ PART :
> Interaction with default ordering or order_by()
> Deprecated since version 2.2:Starting in Django 3.1, the ordering from a
> model’s Meta.ordering
>
>
> I think Django 3.1 must change to 2.1
>
> Thanks.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2b6eac29-852c-4608-a007-f7a9d3284499%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAABi-Dof%3DFybE0HU52RE14BMrzMKR4fqsGwKBTdjoTAuuHKeVw%40mail.gmail.com.

Re: Extend support for long surnames in Django Auth

[Lee Trout]

I thought about that before I posted. I can't remember seeing any settings
that would also carry db consequences other than adding an app. (Or the db
setting dict itself).

On Tuesday, August 2, 2016, Malcolm Box  wrote:

> A setting seems like a dangerous option here, since changing it would
> cause a DB migration to be required.
>
> It's not *that* hard for us to find a value and apply it. Any user that
> really wanted something different could create their own migration to
> change the default - but "leave it to the user" still means picking a value
> for the sane default...
>
> Cheers,
>
> Malcolm
>
> On 2 August 2016 at 14:01, Lee Trout  > wrote:
>
>> I know there's always resistance to adding more settings but this seems
>> like a candidate for a value in a setting with a sane default that a user
>> could quickly and easily change.
>>
>> On Tuesday, August 2, 2016, James Pic > > wrote:
>>
>>> Thanks for your reply Aymeric. If I understand correctly the best way to
>>> approach this, besides increasing the current limits - which I've had to do
>>> myself a few times - is to create a separate app providing a custom model
>>> with an ArrayField for name (sorting) and a migration script, and let time
>>> tell if this is more useful than the current approach and wether it should
>>> become default or not after a long-enough while ?
>>>
>>> Again, thanks for your reply, every time I read messages from engineers
>>> like you it makes me a better one myself and I'm sure it's the case for
>>> most other persons. I understand it can sometimes be hard for you - and
>>> other experienced core devs- to have to deal with us, so I really want to
>>> show my appreciation and love and I think I can speak for everyone of us
>>> when I say thank you for your contribution and your sharing and making
>>> everyone of us better every time you take some time for us.
>>>
>>> Keep up the great work
>>>
>>> Best regards
>>>
>>> --
>>> 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/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Malcolm Box
>
> --
> 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/CAF3R4sVikNLgr1DVtKw_3ps7gFuH

Re: Extend support for long surnames in Django Auth

[Lee Trout]

I know there's always resistance to adding more settings but this seems
like a candidate for a value in a setting with a sane default that a user
could quickly and easily change.

On Tuesday, August 2, 2016, James Pic  wrote:

> Thanks for your reply Aymeric. If I understand correctly the best way to
> approach this, besides increasing the current limits - which I've had to do
> myself a few times - is to create a separate app providing a custom model
> with an ArrayField for name (sorting) and a migration script, and let time
> tell if this is more useful than the current approach and wether it should
> become default or not after a long-enough while ?
>
> Again, thanks for your reply, every time I read messages from engineers
> like you it makes me a better one myself and I'm sure it's the case for
> most other persons. I understand it can sometimes be hard for you - and
> other experienced core devs- to have to deal with us, so I really want to
> show my appreciation and love and I think I can speak for everyone of us
> when I say thank you for your contribution and your sharing and making
> everyone of us better every time you take some time for us.
>
> Keep up the great work
>
> Best regards
>
> --
> 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/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: graphics artist (e.g. OmniGraffle) needed for updated middleware graphic

[Lee Trout]

I have an omnigraffle license and could help a bit later this week if no
one else is interested.

I'm out of touch with Django lately... I read the DEP and I'm assuming
you're after an updated graphic to explicitly show the behavior of proper
short circuiting and the better guarantees around what is and isn't
called...

It might be best to expand this in to 2 or 3 graphics and show the various
states (or an animated gif)...

Lee

On Mon, May 9, 2016 at 9:48 PM, Tim Graham  wrote:

> Would someone like to help update the graphic in this section [0] for the
> new-style middleware implemented in PR#6501 [1]. I'm not quite sure what
> the updated graphic will look like yet, but there isn't any use thinking
> about that if we don't have someone to do the work. :-) The existing image
> is done in OmniGraffle [2] but I guess we're open to other solutions too.
>
> [0]
> https://docs.djangoproject.com/en/1.9/topics/http/middleware/#hooks-and-application-order
> [1] https://github.com/django/django/pull/6501
> [2]
> https://github.com/django/django/tree/bf3057d10bc1e78a8e45142a8288a733b3e908a2/docs/topics/http/_images
>
> --
> 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/890120ba-3f7e-40ad-86d0-f3f9c7a08a6b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAABi-Dq485Ncy7vqhHEe6Q6sk-cLOsXeiDxzVe6y3yXvpw%2BxYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support a javascript template language on the server

[Lee Trout]

I don't want to add any noise here- but I just had a chance to glance over
this conversation and I've basically been doing what Carl describes with
Angular. (In fact I joke often about calling it Djangular). I have a view
that prerenders angular templates (accepts the path to the template in the
url e.g. /views/renderng/path/to/ng/template.html) filling in data that is
available on the server and minimizing what I'm tracking in the scope in
Angular.

It's been working really well but I did have to change my Angular
interpolation provider start and end markers to [[ and ]]. So I have
templates similar to:

Hello {{ user.first_name }}
You have [[ data.points ]] points

Or to share a URL for a specific controller:




I also do as Carl suggested and smuggle data in script tags. This has been
useful when rendering the base template and sharing global URLs.


window.foo = {
urls: {
dataEndpointFoo: "{% url  "endpoint-foo" %}"
}
};



On Tue, Jun 2, 2015 at 3:05 PM, Emil Stenström  wrote:

> On Tuesday, 2 June 2015 20:31:41 UTC+2, Carl Meyer wrote:
>>
>> On 06/02/2015 11:53 AM, Emil Stenström wrote:
>> > I would love to see some code here if you have it available? How do you
>> > pass the JSON and the templates from the view to the client side?
>>
>> I don't have code I can share at the moment, but I'm hoping to blog
>> about this technique, and I'll let you know if/when I do.
>>
>
> Please do, and thanks again for sharing how you get this going. I
> subscribed to the oddbird blog, so if you post it there you don't have to
> tell me :)
>
> --
> 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/a34fff52-24df-4a54-a512-0553b0ffc322%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAABi-DpknKGODsVqW%2BSik-96JpBJcp3%3DZ0Wjk3NVpBPhA2e_5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Updating logging docs

[Lee Trout]

Hey gang,

I finally got past 1.5 and I'm finding so many nice features in 1.7. Thanks
to everyone!

To my surprise logging had an overhaul from #21714 [0] and I found the
documentation a bit confusing / lacking of details.

Theres an explanation of merging settings in
https://docs.djangoproject.com/en/1.7/topics/logging/#configuring-logging
but no description of what the defaults are.

Visiting
https://docs.djangoproject.com/en/1.7/topics/logging/#django-s-default-logging-configuration
doesn't offer any more help to understanding the technical details.

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?

Thanks & Happy New Year!
Lee


[0] https://code.djangoproject.com/ticket/21714

-- 
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/CAABi-DrSoyo%3D-eYe%2BQDJ4qjHuSH_CVLaSei90yTQAcWN_YyUPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FR: Setting for CSRF Header (pull-request included)

[Lee Trout]

Looking at it objectively I'm on the fence. Angular's $http is easily
configurable at the provider level and I feel like the onus is on any
front-end tool to be flexible enough to work with different servers. At the
same time if I needed the same code to talk to Django, Flask, and Node then
I would expect that I could get all of them on some common ground. Of
course I would probably just roll my own middleware in that case...

I hold that opinion because maintaining a handful of projects, for me, is
easier by having the backend as the constant and just remembering when I'm
rolling djangular that I need to config a couple settings when I start off
with Angular. (Another being setting X-Requested-With so request.is_ajax
works as expected).


On Fri, Nov 22, 2013 at 2:28 PM, Wesley Alvaro  wrote:

> I've been using AngularJS with Django, but I have to override the default
> CSRF cookie/header values in AngularJS since only one of the values (the
> cookie name) can be overridden in Django.
>
> This is a humble request to add a setting for the CSRF header name so that
> I can maintain it as my "AngularJS CSRF settings" and I'm sure others would
> like it too.  Changing the cookie and header to XSRF-TOKEN and X-XSRF-TOKEN
> respectively means that CSRF in Angular just works. Nice. With AngularJS's
> popularity on the sharp incline, I see this being quite a useful-to-many
> feature.
>
> I acknowledge that adding a setting is not ideal, so I welcome any ideas
> you may have.
> Pull request here: https://github.com/django/django/pull/1958
>
> Thanks,
> -Wes
>
> --
> 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/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/CAABi-Dqvj%2BDxgu3ys_62jPw%3D6RWjndVZ2dpic0hNqbbDrZZchg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: first() and last(), earliest() and latest()

[Lee Trout]

Let me clarify that I would expect both qs[:1][0] and qs[0] to raise
IndexError if there were no results.


On Thu, May 16, 2013 at 11:05 AM, Lee Trout  wrote:

> That's what I thought- But why not just qs[0]?
>
> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
> the [:1] is unnecessary. I would expect both to raise IndexError.
>
>
>
> On Wed, May 15, 2013 at 11:39 PM, Alex Ogier  wrote:
>
>> Significantly better. The latter method loads every single model in the
>> queryset into Python, potentially the whole database!
>>  On May 15, 2013 9:24 PM, "Lee Trout"  wrote:
>>
>>> Is qs[:1][0] better form than list(qs)[0]?
>>>
>>>
>>> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong wrote:
>>>
>>>> I've updated the first() and last() to not accept any arguments. Please
>>>> review it and let me know if there's anything else I need to change.
>>>> Hopefully this can get merged in during the sprints and make it into 1.6 
>>>> :).
>>>>
>>>> The pull request is here: https://github.com/django/django/pull/1056
>>>>
>>>> Best,
>>>> Selwin
>>>>
>>>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>>>>
>>>>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>>>>> > > "latest()", but in this new pull request, you can pass multiple
>>>>> field names
>>>>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>>>>> more
>>>>> > > flexible and requires less typing, but I wonder if we should just
>>>>> get rid
>>>>> > > of the optional field arguments and rely on "order_by" for
>>>>> ordering. "There
>>>>> > > should be one-- and preferably only one --obvious way to do it".
>>>>> >
>>>>> > Considering "There should be one-- and preferably only one --obvious
>>>>> way to
>>>>> > do it", I definitely prefer to rely on order_by to do the ordering,
>>>>> not on
>>>>> > first.
>>>>> >
>>>>> > .order_by('name').first()
>>>>> >
>>>>> > is clear and readable in my opinion.
>>>>>
>>>>> My thoughts exactly, we already have one method that does ordering, I
>>>>> don't think it is necessary to make these methods incorporate that
>>>>> functionality. If we did, we might argue that other QuerySet
>>>>> operations could be supported as well and that would just result in a
>>>>> bloated API. Especially if there's no performance gain (the QuerySet
>>>>> would be cloned anyway), and it only saves a few lines of code.
>>>>>
>>>>> Also, skimming through this thread, I think there was a consensus on
>>>>> first() and last() not taking any ordering arguments, i.e. the first
>>>>> proposed syntax:
>>>>>
>>>>> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>>>>>
>>>>>
>>>>> Michal
>>>>>
>>>>  --
>>>> 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.
>>>>
>>>>
>>>>
>>>
>>>  --
>>> 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.
>>>
>>>
>>>
>>  --
>> 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.
>>
>>
>>
>
>

-- 
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: first() and last(), earliest() and latest()

[Lee Trout]

That's what I thought- But why not just qs[0]?

Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
the [:1] is unnecessary. I would expect both to raise IndexError.



On Wed, May 15, 2013 at 11:39 PM, Alex Ogier  wrote:

> Significantly better. The latter method loads every single model in the
> queryset into Python, potentially the whole database!
> On May 15, 2013 9:24 PM, "Lee Trout"  wrote:
>
>> Is qs[:1][0] better form than list(qs)[0]?
>>
>>
>> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong  wrote:
>>
>>> I've updated the first() and last() to not accept any arguments. Please
>>> review it and let me know if there's anything else I need to change.
>>> Hopefully this can get merged in during the sprints and make it into 1.6 :).
>>>
>>> The pull request is here: https://github.com/django/django/pull/1056
>>>
>>> Best,
>>> Selwin
>>>
>>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>>>
>>>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>>>> > > "latest()", but in this new pull request, you can pass multiple
>>>> field names
>>>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>>>> more
>>>> > > flexible and requires less typing, but I wonder if we should just
>>>> get rid
>>>> > > of the optional field arguments and rely on "order_by" for
>>>> ordering. "There
>>>> > > should be one-- and preferably only one --obvious way to do it".
>>>> >
>>>> > Considering "There should be one-- and preferably only one --obvious
>>>> way to
>>>> > do it", I definitely prefer to rely on order_by to do the ordering,
>>>> not on
>>>> > first.
>>>> >
>>>> > .order_by('name').first()
>>>> >
>>>> > is clear and readable in my opinion.
>>>>
>>>> My thoughts exactly, we already have one method that does ordering, I
>>>> don't think it is necessary to make these methods incorporate that
>>>> functionality. If we did, we might argue that other QuerySet
>>>> operations could be supported as well and that would just result in a
>>>> bloated API. Especially if there's no performance gain (the QuerySet
>>>> would be cloned anyway), and it only saves a few lines of code.
>>>>
>>>> Also, skimming through this thread, I think there was a consensus on
>>>> first() and last() not taking any ordering arguments, i.e. the first
>>>> proposed syntax:
>>>>
>>>> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>>>>
>>>>
>>>> Michal
>>>>
>>>  --
>>> 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.
>>>
>>>
>>>
>>
>>  --
>> 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.
>>
>>
>>
>  --
> 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.
>
>
>

-- 
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: first() and last(), earliest() and latest()

[Lee Trout]

Is qs[:1][0] better form than list(qs)[0]?


On Wed, May 15, 2013 at 7:48 AM, Selwin Ong  wrote:

> I've updated the first() and last() to not accept any arguments. Please
> review it and let me know if there's anything else I need to change.
> Hopefully this can get merged in during the sprints and make it into 1.6 :).
>
> The pull request is here: https://github.com/django/django/pull/1056
>
> Best,
> Selwin
>
> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>
>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>> > > "latest()", but in this new pull request, you can pass multiple field
>> names
>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>> more
>> > > flexible and requires less typing, but I wonder if we should just get
>> rid
>> > > of the optional field arguments and rely on "order_by" for ordering.
>> "There
>> > > should be one-- and preferably only one --obvious way to do it".
>> >
>> > Considering "There should be one-- and preferably only one --obvious
>> way to
>> > do it", I definitely prefer to rely on order_by to do the ordering, not
>> on
>> > first.
>> >
>> > .order_by('name').first()
>> >
>> > is clear and readable in my opinion.
>>
>> My thoughts exactly, we already have one method that does ordering, I
>> don't think it is necessary to make these methods incorporate that
>> functionality. If we did, we might argue that other QuerySet
>> operations could be supported as well and that would just result in a
>> bloated API. Especially if there's no performance gain (the QuerySet
>> would be cloned anyway), and it only saves a few lines of code.
>>
>> Also, skimming through this thread, I think there was a consensus on
>> first() and last() not taking any ordering arguments, i.e. the first
>> proposed syntax:
>>
>> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>>
>> Michal
>>
>  --
> 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.
>
>
>

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

[Lee Trout]

+1 for logging. It took me way too long to figure out how to get everything
working properly using a different (builtin) class. I agree with #19395
that an example (or two) would be great.

Here's what I'm currently using which makes use of a rotating file handler
and a custom date formatter (If it offers any inspiration or
clarification): https://gist.github.com/4489135

On Mon, Jan 7, 2013 at 3:59 PM, Tim Graham  wrote:

> Hi Daniele,
>
> I think additional tutorials would be welcome. My suggestion, before you
> dive in and start writing, would be to create a ticket with an outline of
> the proposed tutorial.  That will give the community a chance to take a
> look and provide feedback and suggestions before you spend time doing the
> actual writing.
>
> For some ideas, here is the list of "coming soon" tutorials that were at
> the end of tutorial 4 for a long time:
>
>- Advanced form processing
>- Using the RSS framework
>- Using the cache framework (see ticket below)
>- Using the comments framework (not sure about this, since I think
>comments may be removed from Django, see #18965)
>- Advanced admin features: Permissions
>- Advanced admin features: Custom JavaScript
>
> These may not be the best options at this point, but someone thought they
> were good ideas at one point.
>
> In addition, here are some tutorial tickets that have been "accepted":
>
> #16526  - Add a tutorial on
> caching
> #19106  - Add new tutorial
> on breaking templates into blocks
>
> I think your suggestion of logging is a good candidate -- you may want to
> take a look at #19395  as
> well.
>
> Thank-you for your contributions thus far, and I look forward to seeing
> what you come up with in the future. :-)
>
> Tim
>
> On Friday, January 4, 2013 5:42:44 PM UTC-5, Daniele Procida wrote:
>>
>> 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 > com/en/1.5//intro/tutorial05/>
>> 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 view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/vdn9xXpBvEAJ.
>
> 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.
>

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

Updating default errors in contrib.auth.forms.PasswordResetForm

[Lee Trout]

Hi all,

I wasn't sure if it was best to open a ticket or post to the dev group so 
here I am...

I was curious what others thought about changing the default error in the 
PasswordResetForm which currently displays "That e-mail address doesn't 
have an associated user account. Are you sure you've registered?".

I feel like there could be a better default that doesn't expose the fact 
that an email may or may not be in use. (And that probably goes for the 
unusable password error, too.)

Relevant bits:
https://github.com/django/django/blob/stable/1.4.x/django/contrib/auth/forms.py#L191

Lee

-- 
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/-/9EylAZDthMsJ.
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.