Re: A.objects.getdefault

2012-10-09 Thread Anssi Kääriäinen 
On 10 loka, 00:49, Michael Hudson-Doyle  wrote:
> > OK, it seems .get_or_none() method is out. I can see the point of that
> > decision, there are a lot of similar methods that could be added using
> > the convenience argument (like .first() in conjunction
> > with .latest()).
>
> > But, how about .get() with __default kwarg?
>
> My experience is that the _only_ default you will ever use in this
> situation is None.

Good point - it seems all usages of __default with non-None values
would be abuse of the API. So, maybe the kwarg could be named
'__allow_none' or something along those lines?

> FWIW, get_or_none() seems useful to me but I can live without it.

For the record: that is my take on this, too.

 - Anssi

-- 
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: A.objects.getdefault

2012-10-09 Thread Michael Hudson-Doyle 
On 10 October 2012 10:29, Anssi Kääriäinen  wrote:
> On 9 loka, 20:15, ptone  wrote:
>> Unsurprisingly - this has come up before:
>>
>> Earlier 
>> discussionhttps://groups.google.com/forum/?fromgroups=#!topic/django-developers...
>>
>> tickets:https://code.djangoproject.com/ticket/17546https://code.djangoproject.com/ticket/2659https://code.djangoproject.com/ticket/11352
>>
>> All the ticket's were wontfixed
>
> OK, it seems .get_or_none() method is out. I can see the point of that
> decision, there are a lot of similar methods that could be added using
> the convenience argument (like .first() in conjunction
> with .latest()).
>
> But, how about .get() with __default kwarg?

My experience is that the _only_ default you will ever use in this
situation is None.

I think this is because QuerySet.get() returns a full blown object.  A
default object would have to be some other full blown object, and it's
unlikely that you'll be in the situation where you want to find an
object but some other object is an acceptable alternative.  You might
want to find an object and create it if it does not exist -- this is
why get_or_create is a useful API :-)

Dictionaries by contrast can contain 'primitive' types as values and
they have acceptable and varying 'default' values -- 0, '', [] etc.
Many uses of get-with-default could be replaced with a defaultdict.

FWIW, get_or_none() seems useful to me but I can live without it.

Cheers,
mwh

-- 
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: Redesign of djangoproject.com?

2012-10-09 Thread Wim Feijen 
Oops sorry Dana! Thanks Jacob, that's good to hear!

Op dinsdag 9 oktober 2012 23:26:42 UTC+2 schreef Dana Woodman het volgende:
>
> Glad you like the design, but I'm a he. :)
>
> On Tuesday, October 9, 2012 11:58:58 AM UTC-7, Wim Feijen wrote:
>>
>> Hi Jacob, 
>>
>> I was wondering whether there were any entries and whether a decision has 
>> been taken to appoint a benevolent redesigner? 
>>
>> Personally I really liked Dana's proposal, marketing-wise, and 
>> considering she raised the question, I would certainly support her. 
>>
>> My apologies if I missed a conversation on the mailing list.
>>
>> Best regards,
>>
>> Wim
>>
>> Op donderdag 24 mei 2012 19:14:36 UTC+2 schreef Jacob Kaplan-Moss het 
>> volgende:
>>>
>>> Hi folks -- 
>>>
>>> Thanks so much to everyone who's participated in this thread; I feel 
>>> like there's a lot of useful discussion and brainstorming going on. 
>>>
>>> The DSF board met yesterday and discussed the effort --  we're 
>>> determined to get this done soon. Unfortunately, we ultimately think 
>>> that this collaborative effort isn't working: there's a lot of great 
>>> ideas, but some of the discussion is veering closer to "design by 
>>> committee", and nobody's really empowered to move things forward. 
>>>
>>> Ultimately and sadly, though, great design is at odds to a community 
>>> process: the only way we know to get something we *love* is to find 
>>> someone awesome and let them do their thing. 
>>>
>>> So here's the plan: in the next month we're do exactly that: find 
>>> someone awesome, and give them carte blance on the redesign. We'll of 
>>> course give feedback, and touch base with the community a few times, 
>>> but ultimately we're going to put this thing into one person's hands. 
>>>
>>> If you'd like to become the Benevolent Dictator For This Redesign, 
>>> then please send a proposal to . This 
>>> doesn't need to be formal; we just need to know two things: 
>>>
>>> 1. Can you deliver? Convince us that you'll actually be able to get 
>>> this done: show us a track record of shipping, and explain why you'll 
>>> have time to work on this. We'd like to see this land before DjangoCon 
>>> US in September; can you hit that? 
>>>
>>> 2. Are you awesome? Convince us that your design will rock. This can 
>>> come in the form of a mockup, or previous work, or whatever. Again we 
>>> don't need formal stuff here, and we certainly don't expect spec work. 
>>> We just want to make sure your aesthetic matches ours. 
>>>
>>> A few further notes: 
>>>
>>> * I want to stress the informality of this. We don't need or want a 
>>> full formal proposal like you would for a real client; we just want to 
>>> know that you're awesome and can deliver. If you can prove that to us 
>>> in a few words, do it! 
>>>
>>> * You don't have to do this all yourself; we have quite a few 
>>> volunteers. Importantly, we have *plenty* of people who can help on 
>>> the backend (natch), so really all we need is someone who's great at 
>>> the design side. How much of the actual coding you do is up to you. If 
>>> you've got weaknesses that's complete fine, just tell us what help you 
>>> need and we'll fill it in. You'll be in charge visually and 
>>> aesthetically, but we'll encourage you to delegate as much as you can. 
>>>
>>> * We don't currently have a budget assigned; we're thinking this'll be 
>>> volunteer work. However, the DSF *does* have some funds, and if money 
>>> makes the difference we'll spend it. So if you need money to make it 
>>> happen, tell us. We won't penalize you if you need to get paid (but at 
>>> the same time we hope you recognize we probably can't afford market 
>>> rates). 
>>>
>>> * The deadline is Sunday, June 17th, and we'll aim to make a decision 
>>> that week. 
>>>
>>> Thanks everyone! 
>>>
>>> Jacob 
>>>
>>> PS: I'm deliberately burying this down in the thread instead of 
>>> posting this more publicly. I'd like to avoid this becoming a general 
>>> call; I'm more interested in reaching people who're *already* paying 
>>> attention to this effort. I'd appreciate it, then, if you'd keep this 
>>> call off Reddit, Hacker News, etc. However, if you know someone who 
>>> you think *should* be interested, please forward it onto them! 
>>>
>>

-- 
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/-/b_HxYxv4CgwJ.
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: A.objects.getdefault

2012-10-09 Thread Anssi Kääriäinen 
On 9 loka, 20:15, ptone  wrote:
> Unsurprisingly - this has come up before:
>
> Earlier 
> discussionhttps://groups.google.com/forum/?fromgroups=#!topic/django-developers...
>
> tickets:https://code.djangoproject.com/ticket/17546https://code.djangoproject.com/ticket/2659https://code.djangoproject.com/ticket/11352
>
> All the ticket's were wontfixed

OK, it seems .get_or_none() method is out. I can see the point of that
decision, there are a lot of similar methods that could be added using
the convenience argument (like .first() in conjunction
with .latest()).

But, how about .get() with __default kwarg? No new method, and this is
obviously Pythonic - see dict.get() and dict.pop(). The default
argument for pop() is there only to avoid code like:
try:
val = somedict.pop('somekey')
except KeyError:
val = None

The __default kwarg is easy to implement:
https://github.com/akaariai/django/commit/3ea711544364723b26fcef83dc700f0b359655c9

On the other hand, this is still API bloat... So, I will not push this
issue further without some support for this idea.

It would maybe be time to investigate again the "chainable" manager
methods. Having them available would solve a lot of the convenience
method problems. And a lot of other problems, too...

 - Anssi

-- 
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: Redesign of djangoproject.com?

2012-10-09 Thread Dana Woodman 
 

Glad you like the design, but I'm a he. :)

On Tuesday, October 9, 2012 11:58:58 AM UTC-7, Wim Feijen wrote:
>
> Hi Jacob, 
>
> I was wondering whether there were any entries and whether a decision has 
> been taken to appoint a benevolent redesigner? 
>
> Personally I really liked Dana's proposal, marketing-wise, and considering 
> she raised the question, I would certainly support her. 
>
> My apologies if I missed a conversation on the mailing list.
>
> Best regards,
>
> Wim
>
> Op donderdag 24 mei 2012 19:14:36 UTC+2 schreef Jacob Kaplan-Moss het 
> volgende:
>>
>> Hi folks -- 
>>
>> Thanks so much to everyone who's participated in this thread; I feel 
>> like there's a lot of useful discussion and brainstorming going on. 
>>
>> The DSF board met yesterday and discussed the effort --  we're 
>> determined to get this done soon. Unfortunately, we ultimately think 
>> that this collaborative effort isn't working: there's a lot of great 
>> ideas, but some of the discussion is veering closer to "design by 
>> committee", and nobody's really empowered to move things forward. 
>>
>> Ultimately and sadly, though, great design is at odds to a community 
>> process: the only way we know to get something we *love* is to find 
>> someone awesome and let them do their thing. 
>>
>> So here's the plan: in the next month we're do exactly that: find 
>> someone awesome, and give them carte blance on the redesign. We'll of 
>> course give feedback, and touch base with the community a few times, 
>> but ultimately we're going to put this thing into one person's hands. 
>>
>> If you'd like to become the Benevolent Dictator For This Redesign, 
>> then please send a proposal to . This 
>> doesn't need to be formal; we just need to know two things: 
>>
>> 1. Can you deliver? Convince us that you'll actually be able to get 
>> this done: show us a track record of shipping, and explain why you'll 
>> have time to work on this. We'd like to see this land before DjangoCon 
>> US in September; can you hit that? 
>>
>> 2. Are you awesome? Convince us that your design will rock. This can 
>> come in the form of a mockup, or previous work, or whatever. Again we 
>> don't need formal stuff here, and we certainly don't expect spec work. 
>> We just want to make sure your aesthetic matches ours. 
>>
>> A few further notes: 
>>
>> * I want to stress the informality of this. We don't need or want a 
>> full formal proposal like you would for a real client; we just want to 
>> know that you're awesome and can deliver. If you can prove that to us 
>> in a few words, do it! 
>>
>> * You don't have to do this all yourself; we have quite a few 
>> volunteers. Importantly, we have *plenty* of people who can help on 
>> the backend (natch), so really all we need is someone who's great at 
>> the design side. How much of the actual coding you do is up to you. If 
>> you've got weaknesses that's complete fine, just tell us what help you 
>> need and we'll fill it in. You'll be in charge visually and 
>> aesthetically, but we'll encourage you to delegate as much as you can. 
>>
>> * We don't currently have a budget assigned; we're thinking this'll be 
>> volunteer work. However, the DSF *does* have some funds, and if money 
>> makes the difference we'll spend it. So if you need money to make it 
>> happen, tell us. We won't penalize you if you need to get paid (but at 
>> the same time we hope you recognize we probably can't afford market 
>> rates). 
>>
>> * The deadline is Sunday, June 17th, and we'll aim to make a decision 
>> that week. 
>>
>> Thanks everyone! 
>>
>> Jacob 
>>
>> PS: I'm deliberately burying this down in the thread instead of 
>> posting this more publicly. I'd like to avoid this becoming a general 
>> call; I'm more interested in reaching people who're *already* paying 
>> attention to this effort. I'd appreciate it, then, if you'd keep this 
>> call off Reddit, Hacker News, etc. However, if you know someone who 
>> you think *should* be interested, please forward it onto them! 
>>
>

-- 
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/-/Pg_duG2HgnYJ.
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: A.objects.getdefault

2012-10-09 Thread Tino de Bruijn 
+1 on a method that returns non upon not finding. We don't need to do:

try:
   val = some_dict.get('key')
except KeyError:
   val = None

either. A nget or get_or_none would save me a lot of boilerplate code in my
views as well.

Tino

On Tue, Oct 9, 2012 at 8:48 PM, Wim Feijen  wrote:

> For me, get_or_none would prevent a lot of boilerplate code in my views,
> so I am in favor of adding the method.
>
> Wim
>
> Op dinsdag 9 oktober 2012 19:15:55 UTC+2 schreef ptone het volgende:
>
>> Unsurprisingly - this has come up before:
>>
>> Earlier discussion
>> https://groups.google.com/**forum/?fromgroups=#!topic/**
>> django-developers/Saa5nbzqQ2Q
>>
>> tickets:
>> https://code.djangoproject.**com/ticket/17546
>> https://code.djangoproject.**com/ticket/2659
>> https://code.djangoproject.**com/ticket/11352
>>
>> All the ticket's were wontfixed
>>
>  --
> 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/-/_nHUoZZICcQJ.
>
> 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: Redesign of djangoproject.com?

2012-10-09 Thread Jacob Kaplan-Moss 
Hi Win --

Yes, we selected one of the bids, and we're working with that team to
get a new site out. Stay tuned!

Jacob

On Tue, Oct 9, 2012 at 1:58 PM, Wim Feijen  wrote:
> Hi Jacob,
>
> I was wondering whether there were any entries and whether a decision has
> been taken to appoint a benevolent redesigner?
>
> Personally I really liked Dana's proposal, marketing-wise, and considering
> she raised the question, I would certainly support her.
>
> My apologies if I missed a conversation on the mailing list.
>
> Best regards,
>
> Wim
>
> Op donderdag 24 mei 2012 19:14:36 UTC+2 schreef Jacob Kaplan-Moss het
> volgende:
>>
>> Hi folks --
>>
>> Thanks so much to everyone who's participated in this thread; I feel
>> like there's a lot of useful discussion and brainstorming going on.
>>
>> The DSF board met yesterday and discussed the effort --  we're
>> determined to get this done soon. Unfortunately, we ultimately think
>> that this collaborative effort isn't working: there's a lot of great
>> ideas, but some of the discussion is veering closer to "design by
>> committee", and nobody's really empowered to move things forward.
>>
>> Ultimately and sadly, though, great design is at odds to a community
>> process: the only way we know to get something we *love* is to find
>> someone awesome and let them do their thing.
>>
>> So here's the plan: in the next month we're do exactly that: find
>> someone awesome, and give them carte blance on the redesign. We'll of
>> course give feedback, and touch base with the community a few times,
>> but ultimately we're going to put this thing into one person's hands.
>>
>> If you'd like to become the Benevolent Dictator For This Redesign,
>> then please send a proposal to . This
>> doesn't need to be formal; we just need to know two things:
>>
>> 1. Can you deliver? Convince us that you'll actually be able to get
>> this done: show us a track record of shipping, and explain why you'll
>> have time to work on this. We'd like to see this land before DjangoCon
>> US in September; can you hit that?
>>
>> 2. Are you awesome? Convince us that your design will rock. This can
>> come in the form of a mockup, or previous work, or whatever. Again we
>> don't need formal stuff here, and we certainly don't expect spec work.
>> We just want to make sure your aesthetic matches ours.
>>
>> A few further notes:
>>
>> * I want to stress the informality of this. We don't need or want a
>> full formal proposal like you would for a real client; we just want to
>> know that you're awesome and can deliver. If you can prove that to us
>> in a few words, do it!
>>
>> * You don't have to do this all yourself; we have quite a few
>> volunteers. Importantly, we have *plenty* of people who can help on
>> the backend (natch), so really all we need is someone who's great at
>> the design side. How much of the actual coding you do is up to you. If
>> you've got weaknesses that's complete fine, just tell us what help you
>> need and we'll fill it in. You'll be in charge visually and
>> aesthetically, but we'll encourage you to delegate as much as you can.
>>
>> * We don't currently have a budget assigned; we're thinking this'll be
>> volunteer work. However, the DSF *does* have some funds, and if money
>> makes the difference we'll spend it. So if you need money to make it
>> happen, tell us. We won't penalize you if you need to get paid (but at
>> the same time we hope you recognize we probably can't afford market
>> rates).
>>
>> * The deadline is Sunday, June 17th, and we'll aim to make a decision that
>> week.
>>
>> Thanks everyone!
>>
>> Jacob
>>
>> PS: I'm deliberately burying this down in the thread instead of
>> posting this more publicly. I'd like to avoid this becoming a general
>> call; I'm more interested in reaching people who're *already* paying
>> attention to this effort. I'd appreciate it, then, if you'd keep this
>> call off Reddit, Hacker News, etc. However, if you know someone who
>> you think *should* be interested, please forward it onto them!
>
> --
> 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/-/BIpmPoJtjvMJ.
>
> 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: Redesign of djangoproject.com?

2012-10-09 Thread Wim Feijen 
Hi Jacob, 

I was wondering whether there were any entries and whether a decision has 
been taken to appoint a benevolent redesigner? 

Personally I really liked Dana's proposal, marketing-wise, and considering 
she raised the question, I would certainly support her. 

My apologies if I missed a conversation on the mailing list.

Best regards,

Wim

Op donderdag 24 mei 2012 19:14:36 UTC+2 schreef Jacob Kaplan-Moss het 
volgende:
>
> Hi folks -- 
>
> Thanks so much to everyone who's participated in this thread; I feel 
> like there's a lot of useful discussion and brainstorming going on. 
>
> The DSF board met yesterday and discussed the effort --  we're 
> determined to get this done soon. Unfortunately, we ultimately think 
> that this collaborative effort isn't working: there's a lot of great 
> ideas, but some of the discussion is veering closer to "design by 
> committee", and nobody's really empowered to move things forward. 
>
> Ultimately and sadly, though, great design is at odds to a community 
> process: the only way we know to get something we *love* is to find 
> someone awesome and let them do their thing. 
>
> So here's the plan: in the next month we're do exactly that: find 
> someone awesome, and give them carte blance on the redesign. We'll of 
> course give feedback, and touch base with the community a few times, 
> but ultimately we're going to put this thing into one person's hands. 
>
> If you'd like to become the Benevolent Dictator For This Redesign, 
> then please send a proposal to . 
> This 
> doesn't need to be formal; we just need to know two things: 
>
> 1. Can you deliver? Convince us that you'll actually be able to get 
> this done: show us a track record of shipping, and explain why you'll 
> have time to work on this. We'd like to see this land before DjangoCon 
> US in September; can you hit that? 
>
> 2. Are you awesome? Convince us that your design will rock. This can 
> come in the form of a mockup, or previous work, or whatever. Again we 
> don't need formal stuff here, and we certainly don't expect spec work. 
> We just want to make sure your aesthetic matches ours. 
>
> A few further notes: 
>
> * I want to stress the informality of this. We don't need or want a 
> full formal proposal like you would for a real client; we just want to 
> know that you're awesome and can deliver. If you can prove that to us 
> in a few words, do it! 
>
> * You don't have to do this all yourself; we have quite a few 
> volunteers. Importantly, we have *plenty* of people who can help on 
> the backend (natch), so really all we need is someone who's great at 
> the design side. How much of the actual coding you do is up to you. If 
> you've got weaknesses that's complete fine, just tell us what help you 
> need and we'll fill it in. You'll be in charge visually and 
> aesthetically, but we'll encourage you to delegate as much as you can. 
>
> * We don't currently have a budget assigned; we're thinking this'll be 
> volunteer work. However, the DSF *does* have some funds, and if money 
> makes the difference we'll spend it. So if you need money to make it 
> happen, tell us. We won't penalize you if you need to get paid (but at 
> the same time we hope you recognize we probably can't afford market 
> rates). 
>
> * The deadline is Sunday, June 17th, and we'll aim to make a decision that 
> week. 
>
> Thanks everyone! 
>
> Jacob 
>
> PS: I'm deliberately burying this down in the thread instead of 
> posting this more publicly. I'd like to avoid this becoming a general 
> call; I'm more interested in reaching people who're *already* paying 
> attention to this effort. I'd appreciate it, then, if you'd keep this 
> call off Reddit, Hacker News, etc. However, if you know someone who 
> you think *should* be interested, please forward it onto them! 
>

-- 
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/-/BIpmPoJtjvMJ.
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: A.objects.getdefault

2012-10-09 Thread Wim Feijen 
For me, get_or_none would prevent a lot of boilerplate code in my views, so 
I am in favor of adding the method.

Wim

Op dinsdag 9 oktober 2012 19:15:55 UTC+2 schreef ptone het volgende:
>
> Unsurprisingly - this has come up before:
>
> Earlier discussion
>
> https://groups.google.com/forum/?fromgroups=#!topic/django-developers/Saa5nbzqQ2Q
>
> tickets:
> https://code.djangoproject.com/ticket/17546
> https://code.djangoproject.com/ticket/2659
> https://code.djangoproject.com/ticket/11352
>
> All the ticket's were wontfixed
>

-- 
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/-/_nHUoZZICcQJ.
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: A.objects.getdefault

2012-10-09 Thread ptone 
Unsurprisingly - this has come up before:

Earlier discussion
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/Saa5nbzqQ2Q

tickets:
https://code.djangoproject.com/ticket/17546
https://code.djangoproject.com/ticket/2659
https://code.djangoproject.com/ticket/11352

All the ticket's were wontfixed

-- 
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/-/XrgxWInpLJgJ.
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: A.objects.getdefault

2012-10-09 Thread ptone 
So basically you want:

https://docs.djangoproject.com/en/dev/ref/models/querysets/#get-or-create

but without the create part - just an empty(), unsaved, object?

This existing method is so close to what you want - that I'd be inclined to 
explore whether it could be modified to do more.

In forms we already have the .save(commit=False) pattern - so it is not 
without reason that we could adopt that for the notion of 'create' on that 
method.

Because get_or_create takes an open list of kwargs, we can't just use 
'commit' - but we could use '__commit'

So it would look like:

obj, created = A.objects.get_or_create(slug="hello", __commit=False)

what the value of created should be in this case is tricky - arguments 
could be made either way.

so I'm far from certain this sort of overloading of get_or_create is 
workable, but if a method were added, but if  method were to be added, I'd 
argue it should follow the get_or_* naming pattern.

This is so easy to do in a custom manager or queryset, the question is 
whether this is a common enough need to bake into the default.

-Preston


On Tuesday, October 9, 2012 7:05:17 AM UTC-7, Ole Laursen wrote:
>
> Hi!
>
> What do people think of
>
>   A.objects.getdefault(slug="hello")  # returns None if slug doesn't exist
>   A.objects.getdefault(slug="hello", default=A())  # returns empty object 
> if slug doesn't exist
>
> I find that in practice, most of the time it would be better to get None 
> back instead of the DoesNotExist exception, but changing .get() is of 
> course impossible without breaking the API.
>
> I do think that
>
>   A.objects.get(slug="hello", default=None)
>
> is more elegant, but it might break some code. Although it does seem 
> really unlikely anyone would add a field named "default" to their model and 
> then use it to locate a unique object.
>
> The only related info I found in the issue tracker and on this list was a 
> thread from 2006.
>
> Ole
>

-- 
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/-/XsLFfxITG7IJ.
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: Pretty Django model instaces updating

2012-10-09 Thread Kee 
I also propose these two little helpers, one is ``refresh()`` and other is 
``update()``
https://gist.github.com/3859962

``update()`` updates instance without calling ``save()`` and calling 
signals and returns updated instance (sometimes you want to update instance 
without involving save signals)

This helpers are particularly useful in writing tests, may be makes sense 
including them not to ``djanog.db.models`` but to ``django.test`` or 
``django.test.tools``.

-- 
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/-/FxGwLxwM8SAJ.
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: A.objects.getdefault

2012-10-09 Thread Carlos Goldsmith 
On Tue, Oct 9, 2012 at 7:29 AM, Anssi Kääriäinen wrote:

> On 9 loka, 17:05, Ole Laursen  wrote:
> > Hi!
> >
> > What do people think of
> >
> >   A.objects.getdefault(slug="hello")  # returns None if slug doesn't
> exist
> >   A.objects.getdefault(slug="hello", default=A())  # returns empty object
> > if slug doesn't exist
> >
> > I find that in practice, most of the time it would be better to get None
> > back instead of the DoesNotExist exception, but changing .get() is of
> > course impossible without breaking the API.
> >
> > I do think that
> >
> >   A.objects.get(slug="hello", default=None)
> >
> > is more elegant, but it might break some code. Although it does seem
> really
> > unlikely anyone would add a field named "default" to their model and then
> > use it to locate a unique object.
> >
> > The only related info I found in the issue tracker and on this list was a
> > thread from 2006.
>
> My approach would be to define .nget() method - just a shorthand for:
> try:
>obj = qs.get(somecondition)
> except DoesNotExist:
>obj = None
>
> This would be really simple to implement, and I know I would use it.
> It would also be simple to document:
> "works exacltly like .get(), but when .get() raises
> DoesNotExist .nget() returns None".
>
> If the .getdefault() is wanted, then we could always
> have .get(somecondition, __default=None). Using '__' as prefix will
> guarantee there will be no name clashes.
>
>  - Anssi
>


Hi -
Personally I would prefer to override the get method intentionally on a per
model basis. Or add a customized nget type method as is suggested by Ansii.
I could see new coders getting in the habit of using something like
getdefault without putting enough thought into it.

As an engineer I tend to think that beauty is achieved not by what you add
but by what you take away so I would personally vote to keep this
out of Django.  But I wouldn't be distraught if it made it in.

-CJ-


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

-- 
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: A.objects.getdefault

2012-10-09 Thread Anssi Kääriäinen 
On 9 loka, 17:05, Ole Laursen  wrote:
> Hi!
>
> What do people think of
>
>   A.objects.getdefault(slug="hello")  # returns None if slug doesn't exist
>   A.objects.getdefault(slug="hello", default=A())  # returns empty object
> if slug doesn't exist
>
> I find that in practice, most of the time it would be better to get None
> back instead of the DoesNotExist exception, but changing .get() is of
> course impossible without breaking the API.
>
> I do think that
>
>   A.objects.get(slug="hello", default=None)
>
> is more elegant, but it might break some code. Although it does seem really
> unlikely anyone would add a field named "default" to their model and then
> use it to locate a unique object.
>
> The only related info I found in the issue tracker and on this list was a
> thread from 2006.

My approach would be to define .nget() method - just a shorthand for:
try:
   obj = qs.get(somecondition)
except DoesNotExist:
   obj = None

This would be really simple to implement, and I know I would use it.
It would also be simple to document:
"works exacltly like .get(), but when .get() raises
DoesNotExist .nget() returns None".

If the .getdefault() is wanted, then we could always
have .get(somecondition, __default=None). Using '__' as prefix will
guarantee there will be no name clashes.

 - Anssi

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

A.objects.getdefault

2012-10-09 Thread Ole Laursen 
Hi!

What do people think of

  A.objects.getdefault(slug="hello")  # returns None if slug doesn't exist
  A.objects.getdefault(slug="hello", default=A())  # returns empty object 
if slug doesn't exist

I find that in practice, most of the time it would be better to get None 
back instead of the DoesNotExist exception, but changing .get() is of 
course impossible without breaking the API.

I do think that

  A.objects.get(slug="hello", default=None)

is more elegant, but it might break some code. Although it does seem really 
unlikely anyone would add a field named "default" to their model and then 
use it to locate a unique object.

The only related info I found in the issue tracker and on this list was a 
thread from 2006.

Ole

-- 
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/-/yt14RXkhAkwJ.
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: #16630: Support for HTML5 input types

2012-10-09 Thread Felipe Prenholato 
If matters, +1.

People can easily change from $('input[type=text]') to
$('input[type=text],input[type=email]'), it's a easy, no pain change, with
various benefits of HTML5 fields.

I would only suggest that people can do something like
number_field=IntegerField(html5=False) in form (at least in 1.5) so fields
back to input type=text in rendering and who don't wanna touch css/js and
third party apps to fix the code, just put this and everything works.

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2012/10/1 Stephen Burrows 

> Hey all - Last I heard, today was the last day for new features for 1.5. I
> was triaging tickets yesterday and ran this ticket. [1] The ticket looks
> fine, and it addresses the issues raised here. The only new issue (raised
> on the ticket) is that this change could break third-party javascript and
> css if anyone is relying on those fields having type="text". Although this
> is a valid concern, I still think it would be worth switching over to HTML5
> at long last – perhaps with a slightly more explicit warning in the
> backwards-compatibility section of the release notes so that designers know
> they need to watch out for that.
>
> Since the only obstacle seems to be getting some sort of consensus among
> core devs that this is a change that's okay to make, I was hoping to get
> some feedback, and maybe get the patch merged in.
>
> Best,
> Stephen
>
> [1] https://code.djangoproject.com/ticket/16630
>
> On Tuesday, December 27, 2011 8:15:19 AM UTC-8, Jonas H. wrote:
>
>> This patch has been around for while now. I just updated the patch so it
>> applies cleanly against rev 17281.
>>
>> So, can we get this patch into trunk or is something missing?
>>
>> Jonas
>>
>> --
>> http://jonas.lophus.org | http://django-mongodb.org
>>
>> Want to become a Django MongoDB Engine/Django-nonrel core developer?
>> Get in touch: django-non...@**googlegroups.com
>>
>>  --
> 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/-/FSBHz8GBxAIJ.
>
> 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: Feature request: collectstatic shouldn't recopy files that already exist in destination

2012-10-09 Thread Florian Apolloner 
Hi Stephen,

On Tuesday, October 9, 2012 7:28:43 AM UTC+2, Stephen Burrows wrote:
>
> I'm a little confused by the track the discussion took recently... my 
> impression was that the solution would *not* be to change from 
> last_modified to a checksum, or to add an additional checksum method. 
> Instead, storage backeds could support a has_changed method, which could be 
> overridden to provide last_modified checking *or* checksum comparisons - or 
> any other method of checking whether a file has changed. This seems like a 
> useful, easy-to-explain, very generic way to handle checking whether a file 
> has changed.


This would be one way to do it (we've also discussed that in IRC), but we 
couldn't figure out any implementation that would actually be useable. To 
make this work you'd need to have a function signature like "def 
has_changed(file_name, other_thing)" whereas other_thing would be some 
hash/modified_time whatever provided by the source storage. Now we are back 
to the situation I described in my answer to Jeremy…

 

> And since what staticfiles actually cares about is whether the file has 
> changed, it seems like it would make more 

sense to use a method that checks whether the file has changed, rather than 
> just checking the last modification date.


Well staticfiles doesn't care, it's only collectstatic which cares to some 
extend. So in my opinion the cleanest way (which means without coupling the 
two needed storage backends together to strongly) is to provide your own 
collectstatic command where you can do what you want with the checks (if 
you have problems implementing that we'd happily move some code to extra 
methods to make reusing collectstatic easier).
 

> Would I be correct in thinking that the main argument against this is API 
> bloat, or is there something else that I'm not seeing?
>

I'd rather say: We don't see __any__ nice way to actually support something 
which is generic enough the be useful. 

Cheers,
Florian

-- 
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/-/vjZYGSYGnwUJ.
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: Feature request: collectstatic shouldn't recopy files that already exist in destination

2012-10-09 Thread Florian Apolloner 
Hi Jeremy,

On Tuesday, October 9, 2012 5:15:04 AM UTC+2, jdunck wrote:
>
> Would it be reasonable to have a backend-specific hook to determine a 
> fingerprint, where that could be mtime or md5 or whathaveyou as long as 
> equality (or maybe ordering) works?
>

Given our discussion in IRC yesterday the answer seems to be no. Eg 
consider this: collectstatic actually uses two backends, a "source" 
storage-backend and an "upload" storage-backend. Now if the 
storage-backends are allowed to return any fingerprint, how would you make 
sure that both of these backends actually use the same fingerprint? So 
essentially to have a S3-backend which (let's just abuse modified_time for 
now) returns a md5 hash from modified_time, you'd have to also change the 
other backend you want to use (usually just the local filesystem backend) 
to return md5 instead…

Cheers,
Florian

-- 
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/-/zsJ1b1zETFMJ.
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:

2012-10-09 Thread Igor 
фейсик после ipo сильно потерял в цене акций - им нужна комерциализация 
конче ;)


хорошее слово "конче"

нам тоже нужно ентое "конче"

On Tue 09 Oct 2012 07:28:01 EEST, django-developers@googlegroups.com 
wrote:

Today's Topic Summary

Group: http://groups.google.com/group/django-developers/topics

  * Feature request: collectstatic shouldn't recopy files that already
exist in destination <#group_thread_0> [9 Updates]

Feature request: collectstatic shouldn't recopy files that already
exist in destination


Dan Loewenherz  Oct 07 08:58PM -0700

This issue just got me again tonight, so I'll try to push once
more on this
issue. It seems right now most people don't care that this is
broken, which
is a bummer, but in which case I'll just continue using my working
solution.

Dan

ptone  Oct 07 10:38PM -0700

so after scanning this thread and the ticket again - it is still
unclear
that there could be a completely universal solution.

While it would be nice if the storage API had a checksum(name) or
md5(name)
method - not all custom storage backends are going to support a
single
checksum standard. S3 doesn't explicitly support MD5 (apparently it
unofficially does through ETags). Without a universal checksum -
you can't
use it to compare files across arbitrary backends.

I do agree that hacking modified_time return value is a little
ugly - the
API is clearly documented as "returns a datetime..." - so
returning a M55
checksum there is, well, hacky.

If you are passionate about moving this forward, here is what I'd
suggest.

Implement, document, and test .md5(name) as a standard method on
storage
backends - like modified_time this would raise NotImplementedError
if not
available - this could easily be its own ticket. md5 is probably the
closest you'll get to a checksum standard.

Once you have an md5 method defined for backends - you could
support a
--md5 option to collectstatic that would use that as the
target/source
comparison.

Another workaround is to just use collectstatic locally - and rsync
--checksum to your remote if it supports rsync.

-Preston


On Sunday, October 7, 2012 8:59:16 PM UTC-7, Dan Loewenherz wrote:

Jannis Leidel  Oct 08 12:33PM +0200


> It's accurate *only* in certain situations. And on a distributed
development team, I've run into a lot of issues with developers
re-upload files that have already been uploaded because they just
recently updated their repo.

> A checksum is the only true accurate method to determine if a
file has changed.

> Additionally, you didn't address my point that I quoted from.
Storage backends don't just reflect filesystems--they could
reflect files stored in a database, S3, etc. And some of these
filesystems don't support last modified times.

Then, frankly, this is a problem of the storage backends, not
Django's. The S3BotoStorage backend *does* have a modified_time
method:


https://bitbucket.org/david/django-storages/src/1574890d87be/storages/backends/s3boto.py#cl-298

What storage backend do you use that doesn't have a modified_time
method?

> This is a bit confusing...why call it last_modified when that's
doesn't necessarily reflect what it's doing? It would be more
flexible to create two methods:

It's called modified_time, not last_modified.

> def modification_identifier(self):

> def has_changed(self):

> Then, any backend could implement these however they might like,
and collectstatic would have no excuse in uploading the same file
more than once. Overloading last_modified to also do things like
calculate md5's seems a bit hacky to me, and confusing for any
developer maintaining a custom storage backend that doesn't
support last modified.

I disagree, modified_time is perfectly capable of handling your
use case.

Jannis

Jannis Leidel  Oct 08 12:50PM +0200


> so after scanning this thread and the ticket again - it is still
unclear that there could be a completely universal solution.

> While it would be nice if the storage API had a checksum(name)
or md5(name) method - not all custom storage backends are going to
support a single checksum standard. S3 doesn't explicitly support
MD5 (apparently it unofficially does through ETags). Without a
universal checksum - you can't use it to compare files across
arbitrary backends.

You're able to ask S3 for the date of last modification, I don't
see why a comparison by hashing the file content is needed
additionally. It'd have to download the full file to do that on
Django's side and I'm not aware of a API for getting a hash from