Re: A.objects.getdefault

[Wim Feijen]

Hi,

Ticket 19326 has been marked as ready for check-in for some time. Can 
some-one have a look at it?

 https://code.djangoproject.com/ticket/19326

Thanks,

Wim


Op donderdag 29 november 2012 23:45:38 UTC+1 schreef Wim Feijen het 
volgende:
>
> Hi Anssi,
>
> When I thought about it, the most prominent usecase seemed to me of 
> getting one of a set of many and expecting just one result. In that case, 
> get_or_none would suffice. However, as a method name, I prefer first() for 
> being concise. 
>
> For me it is ok to just have the first() method without last(). For 
> example, sqlalchemy defines first() but not last(). Although jquery does 
> define both.
>
> I agree that ordering should be applied and in case no ordering is 
> specified on the model, I really would like to use ordering by pk. Doesn't 
> filter provide results by default in that order? Unfortunately, I was not 
> able to comprehend the workings of clone so I am not sure.
>
> Regards, Wim
>
> Op donderdag 29 november 2012 08:12:28 UTC+1 schreef Anssi Kääriäinen het 
> volgende:
>>
>> On 29 marras, 01:13, Wim Feijen  wrote: 
>> > Hi, the patch has been updated and now works. 
>> > 
>> > Still, feedback would be appreciated. So, Anssi, Jacob? 
>>
>> Apart of some whitespace errors the patch looks good to me. 
>>
>> There isn't last() method in the patch. Implementing one is going to 
>> be a little more challenging as one needs to change the direction of 
>> all the ordering clauses. Do we want one in the same patch? 
>>
>> A bigger problem might be that we already have .latest() which does 
>> something a bit different. I wonder if having both .last(filter_args) 
>> and .latest(by_field) is going to be confusing. 
>>
>> Another API issue is that should .first() check for some ordering? 
>> This could add some protection. In testing conditions things might 
>> work, but when updates are done to the rows the expected ordering 
>> suddenly changes. One option is to do automatic ordering on PK if 
>> there isn't any other ordering present. 
>>
>> I still like the idea of .get_default() mainly for the added "if 
>> multiple objects returned, then throw an error" protection it gives. 
>> From implementation/maintenance perspective these are really easy 
>> additions, from API bloat perspective maybe not... 
>>
>>  - Anssi 
>>
>

-- 
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/-/KNzxgP8L-V0J.
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: serializers.serialize on a single object

[Russell Keith-Magee]

Sure - sounds like a reasonable suggestion to me. Feel free to open a
ticket and provide a patch!

Yours,
Russ Magee %-)

On Thu, Jan 10, 2013 at 3:21 AM, Gabriel Warshauer-Baker
wrote:

> As Luke Plant pointed out a few years ago, you *can* just do:
>
> def serialize_one_object_to_json(**obj):
> return serializers.serialize("json", [obj])[1:-1]
> But, since you almost always want this exact behavior when serializing a
> single object, it seems like this is a good candidate for functionality to
> add to serializers.serialize itself.
>
> --
> 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/-/2T5reILz_q8J.
> 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.

Re: runserver stdout and stderr piping problems

[Russell Keith-Magee]

I'm not aware of a ticket for this issue, and I couldn't find one from a
quick search, so feel free to open one. The approach described by the OP
seems reasonable, so if you want to provide a patch as well, feel free.

Yours,
Russ Magee %-)

On Wed, Jan 9, 2013 at 11:37 PM, Chris Proto  wrote:

> Did you ever get around to opening a ticket for this?  If so, what is the
> status?
>
>
> On Friday, January 20, 2012 1:04:29 PM UTC-7, JuhaS wrote:
>>
>> I was launching manage.py runserver from another app and trying to
>> capture the output correctly without luck using pipes. Eventually I
>> narrowed the problem down to two issues. In my opinion they are bugs
>> but I thought I'd ask for confirmations here before creating a ticket
>> and patch.
>>
>> Issue 1: The startup message of development server isn't flushed.
>>
>> The result is that starting the server from console directly it is
>> printed correctly during startup, but using pipes the message isn't
>> flushed until shutdown (Ctrl+C pressed). Since log messages use etderr
>> (issue 2) they are flushed before the startup message.
>>
>> Example:
>>
>> $ python manage.py runserver 2>> output 1>> output  // redirect stderr
>> and stdout to file named output
>>
>> [send few http requests]
>> [press Ctrl+C]
>>
>> $ cat output
>>
>> [20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358
>> [20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358
>> [20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358
>> Validating models...
>>
>> 0 errors found
>> Django version 1.4 alpha 1, using settings 'djangotut.settings'
>> Development server is running at http://127.0.0.1:8000/
>> Quit the server with CONTROL-C.
>>
>> Since the actual log messages go to stderr (next issue), the startup
>> message keeps hanging until shotdown when it's eventually printed to
>> end of the file. I tried with many commands and all showed the same
>> issue.
>>
>> Is this a clear bug?
>>
>> SOLUTION: adding a stdout.flush() to runserver.py fixes this for me.
>>
>>
>> Issue 2: Log entries about http requests go to stderr
>>
>> For some reason the log entries go to stderr (for example 'GET //
>> HTTP...'). Is this a bug, or is there some reason for this?
>>
>  --
> 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/-/GgVXCHG1e2QJ.
>
> 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.

Re: #14633 - organization of settings docs

[Tim Graham]

Thanks for the suggestion, I've added a topical index to the pull request.

On Tuesday, January 8, 2013 12:49:58 PM UTC-5, ptone wrote:
>
> Looks good overall Tim - I do think that the primary reference should be 
> kept alphabetical within core - this is most useful when you have a setting 
> you need to look up.  But I do think that a 'by-topic' cross reference 
> index could also be very useful for discovering or learning about all 
> settings.  Such an index could be at the bottom of the page, and include 
> the topics suggested, as well as the deprecated settings - settings that 
> apply to more than one topic could be duplicated in such an index, and 
> deprecated settings could be duplicated under a topic, and under a 
> "deprecated" heading in such an index. This is a case where more 
> organization is only good, and there is no reason we have to choose an 
> either or.
>
> -Preston
>
>
> On Monday, January 7, 2013 1:02:49 PM UTC-8, Tim Graham wrote:
>>
>> I'd appreciate feedback on 
>> #14633- "Organize settings 
>> reference docs". So far I've broken out the settings 
>> for each contrib app into their own sections. The one comment on the pull 
>> request suggests further breaking up the settings listed in the "Core 
>> settings" section, e.g. logging, caches, globalization (i18n/l10n), email, 
>> file uploads/media, storages, and security. I don't feel strongly about 
>> this proposal: it could be useful, but it could also be ambiguous as to 
>> which section a particular settings belongs in.
>>
>> The pull request also suggests organizing the default settings.py in a 
>> similar fashion.  While it may be outside of the scope of this ticket, it 
>> could be worthwhile to discuss that suggestion as well.
>>
>

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

serializers.serialize on a single object

[Gabriel Warshauer-Baker]

As Luke Plant pointed out a few years ago, you *can* just do:

def serialize_one_object_to_json(obj):
return serializers.serialize("json", [obj])[1:-1]
But, since you almost always want this exact behavior when serializing a 
single object, it seems like this is a good candidate for functionality to 
add to serializers.serialize itself.

-- 
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/-/2T5reILz_q8J.
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: runserver stdout and stderr piping problems

[Chris Proto]

Did you ever get around to opening a ticket for this?  If so, what is the 
status?


On Friday, January 20, 2012 1:04:29 PM UTC-7, JuhaS wrote:
>
> I was launching manage.py runserver from another app and trying to 
> capture the output correctly without luck using pipes. Eventually I 
> narrowed the problem down to two issues. In my opinion they are bugs 
> but I thought I'd ask for confirmations here before creating a ticket 
> and patch. 
>
> Issue 1: The startup message of development server isn't flushed. 
>
> The result is that starting the server from console directly it is 
> printed correctly during startup, but using pipes the message isn't 
> flushed until shutdown (Ctrl+C pressed). Since log messages use etderr 
> (issue 2) they are flushed before the startup message. 
>
> Example: 
>
> $ python manage.py runserver 2>> output 1>> output  // redirect stderr 
> and stdout to file named output 
>
> [send few http requests] 
> [press Ctrl+C] 
>
> $ cat output 
>
> [20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358 
> [20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358 
> [20/Jan/2012 13:54:24] "GET // HTTP/1.1" 200 358 
> Validating models... 
>
> 0 errors found 
> Django version 1.4 alpha 1, using settings 'djangotut.settings' 
> Development server is running at http://127.0.0.1:8000/ 
> Quit the server with CONTROL-C. 
>
> Since the actual log messages go to stderr (next issue), the startup 
> message keeps hanging until shotdown when it's eventually printed to 
> end of the file. I tried with many commands and all showed the same 
> issue. 
>
> Is this a clear bug? 
>
> SOLUTION: adding a stdout.flush() to runserver.py fixes this for me. 
>
>
> Issue 2: Log entries about http requests go to stderr 
>
> For some reason the log entries go to stderr (for example 'GET // 
> HTTP...'). Is this a bug, or is there some reason for this? 
>

-- 
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/-/GgVXCHG1e2QJ.
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: About Understanding of source code

[is_null]

This should be mentioned too:

import ipdb; ipdb.set_trace()

If you didn't already, then go ahead and mess with it.

-- 
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/-/I1-zmObIpWEJ.
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.