Re: A.objects.getdefault

2012-10-15 Thread Ole Laursen 
On Friday, October 12, 2012 3:35:53 PM UTC+2, Chris Wilson wrote:
>
> I'm strongly in favour of a simple, obvious way to do the common thing, 
> which is to return None if the object doesn't exist, instead of throwing 
> an exception. My preferred method names would be .nget(), .get_or_none() 
> or .first().
>

IMHO the fact that we have all these inventive solutions is ample proof 
that people do come across this problem and find it annoying. I just found 
out today that there's a somewhat related .latest().

Anyway, without a sponsor with commit access I guess this is dead, so I'll 
shut up now. Thank you for your time. 


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/-/xFWfDQzuQ7cJ.
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-15 Thread Anssi Kääriäinen 

On 10/15/2012 03:13 PM, Ole Laursen wrote:

On Friday, October 12, 2012 3:35:53 PM UTC+2, Chris Wilson wrote:

I'm strongly in favour of a simple, obvious way to do the common
thing,
which is to return None if the object doesn't exist, instead of
throwing
an exception. My preferred method names would be .nget(),
.get_or_none()
or .first().


IMHO the fact that we have all these inventive solutions is ample 
proof that people do come across this problem and find it annoying. I 
just found out today that there's a somewhat related .latest().


Anyway, without a sponsor with commit access I guess this is dead, so 
I'll shut up now. Thank you for your time.



For the record, I still do like this idea, specifically .get_or_none().

It seems there is significant support for this idea. I do think this 
method is Pythonic. There are cases where no match from get() isn't 
exceptional, and in such cases try-except just feels wrong.


The counter argument is that this is API bloat, and this will set an 
example for more API bloat.


In the end this is a decision with almost no technical considerations 
and a lot of "good taste" considerations. So, this seems like BDFL area.


If there are no signs from BDFL that .get_or_none() is acceptable, then 
lets bury this one. If it is acceptable, then I am willing to do all the 
work to get this committed.


 - 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-15 Thread Tom Evans 
On Mon, Oct 15, 2012 at 1:42 PM, Anssi Kääriäinen
 wrote:
> On 10/15/2012 03:13 PM, Ole Laursen wrote:
>
> On Friday, October 12, 2012 3:35:53 PM UTC+2, Chris Wilson wrote:
>>
>> I'm strongly in favour of a simple, obvious way to do the common thing,
>> which is to return None if the object doesn't exist, instead of throwing
>> an exception. My preferred method names would be .nget(), .get_or_none()
>> or .first().
>
>
> IMHO the fact that we have all these inventive solutions is ample proof that
> people do come across this problem and find it annoying. I just found out
> today that there's a somewhat related .latest().
>
> Anyway, without a sponsor with commit access I guess this is dead, so I'll
> shut up now. Thank you for your time.
>
> For the record, I still do like this idea, specifically .get_or_none().
>
> It seems there is significant support for this idea. I do think this method
> is Pythonic. There are cases where no match from get() isn't exceptional,
> and in such cases try-except just feels wrong.
>
> The counter argument is that this is API bloat, and this will set an example
> for more API bloat.
>
> In the end this is a decision with almost no technical considerations and a
> lot of "good taste" considerations. So, this seems like BDFL area.
>
> If there are no signs from BDFL that .get_or_none() is acceptable, then lets
> bury this one. If it is acceptable, then I am willing to do all the work to
> get this committed.
>
>  - Anssi

Where would this method live? On the queryset/manager? I'm not
convinced it should be there, since it's a utility method.

My personal ideal would be a new django.shortcuts.get_object_or_none
shortcut function, as I can see using this as an analogue to
get_object_or_404, but I have a feeling shortcuts is not intended to
grow.

Cheers

Tom

-- 
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: contrib.markup deprecation

2012-10-15 Thread Waylan Limberg 
On Sat, Oct 13, 2012 at 1:34 PM, Luke Plant  wrote:

> Hi all,
>
> https://code.djangoproject.com/ticket/18054
>
> I just came across this, and it seems slightly hasty. Most deprecations
> of entire contrib modules would require some discussion on django-devs,
> I would have thought.


The most recent discussion of this on the list was here (although I do
remember it being mentioned previously):

https://groups.google.com/forum/#!msg/django-developers/tRpwMudkCfo/pVIPk8QvRusJ

Luke, perhaps you missed it as it was about markdown. I link to it now
because it includes my take (as the maintainer of the markdown lib) of the
current markdown implementation in contrib.markup.

Someone else in this discussion mentioned that the markdown implementation
is not safe. I believe that it the case with all "true" markdown
implementations.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

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

Proposal - ``Model.reset_state``

2012-10-15 Thread Yo-Yo Ma 
Problem:

a = A.objects.get(...)
form = AModelForm(data={...}, instance=a)
if form.is_valid():
a = form.save()
else:
a.calculate_foo_field()
a.last_attempt = datetime.now()
a.save()  # Oops, now the instance has the bad data provided to the form


Workarounds:

# Get a fresh copy of ``a``
a = A.objects.get(pk=a.pk)
# Wasted query
# Also, this won't work in the context of a ``select_for_update`` on 
the original instance

# Use ``update`` instead
A.objects.filter(pk=a.pk).update(last_attempt=datetime.now(), ...)
# What about ``calculate_foo_field``?
# Also has the ``select_for_update`` problem


Solution:

a.reset_state()  # Resets the instance's field state to the point of 
creation (using data stored in a ``_state_reset_cache`` dict)
a.reset_foo()  # etc.
a.latest_attempt = datetime.now()
a.save()

Problem: Uses more memory per instance
Solution: Add ``QuerySet.cache_for_reset()`` allowing opt-in usage of the 
feature, treating ``reset_state`` as noop when instance doesn't have the 
state reset cache.

-- 
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/-/kjHIIO5YZJQJ.
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: Proposal - ``Model.reset_state``

2012-10-15 Thread Alex Ogier 
On Mon, Oct 15, 2012 at 12:16 PM, Yo-Yo Ma  wrote:

> Problem:
>
> a = A.objects.get(...)
> form = AModelForm(data={...}, instance=a)
> if form.is_valid():
> a = form.save()
> else:
> a.calculate_foo_field()
> a.last_attempt = datetime.now()
> a.save()  # Oops, now the instance has the bad data provided to the
> form
>
>
> Workarounds:
>
> # Get a fresh copy of ``a``
> a = A.objects.get(pk=a.pk)
> # Wasted query
> # Also, this won't work in the context of a ``select_for_update`` on
> the original instance
>
> # Use ``update`` instead
> A.objects.filter(pk=a.pk).update(last_attempt=datetime.now(), ...)
> # What about ``calculate_foo_field``?
> # Also has the ``select_for_update`` problem
>
>
> Solution:
>
> a.reset_state()  # Resets the instance's field state to the point of
> creation (using data stored in a ``_state_reset_cache`` dict)
> a.reset_foo()  # etc.
> a.latest_attempt = datetime.now()
> a.save()
>
> Problem: Uses more memory per instance
> Solution: Add ``QuerySet.cache_for_reset()`` allowing opt-in usage of the
> feature, treating ``reset_state`` as noop when instance doesn't have the
> state reset cache.


That seems like a heavy-weight solution for something that probably isn't
all that common. The same thing could be achieved by adding a method to
checkpoint the current state, or even clone the instance, which would only
incur the overhead when you know you need it. For example:

a = A.objects.get(...)
form = AModelForm(data={...}, instance=a.clone()) ## copy the state here
if form.is_valid():
a = form.save()
else:
a.calculate_foo_field()
a.last_attempt = datetime.now()
a.save()

This is easy enough to do piecemeal by adding .clone() methods to your
models, and trying to do it generically sends us even farther towards
Django models having all the bureaucracy of a C++ class with
copy-constructors, so I wouldn't advocate adding it to core. Hopefully it
addresses your use case though.

Here's an example of a similar snippet someone has written, though
obviously you want to keep the same PK instead of auto-generating a new
one: http://djangosnippets.org/snippets/904/

Best,
Alex Ogier

-- 
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-15 Thread Jacob Kaplan-Moss 
On Mon, Oct 15, 2012 at 7:42 AM, Anssi Kääriäinen
 wrote:
> In the end this is a decision with almost no technical considerations and a
> lot of "good taste" considerations. So, this seems like BDFL area.

Hi!

After thinking a bit, I'm +1 on the idea, and I think
`Queryset.first()` is the right name (which implies we should probably
have a `last()` for completion).

This mirrors the name used by a few other ORM/collection APIs that I
think have really nice APIS:

* SQLalchemy 
(http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html#sqlalchemy.orm.query.Query.first)
* Storm 
(http://people.canonical.com/~therve/storm/storm.store.ResultSet.html#first)
* Backbone (http://backbonejs.org/#Collection-Underscore-Methods /
http://documentcloud.github.com/underscore/#first)

If someone produces a patch I'll review it and commit it.

Jacob

-- 
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: Update on localflavor move

2012-10-15 Thread Aymeric Augustin 
Hi Adrian,

Thanks for taking the lead on this! I reviewed related tickets in Trac and I 
have a few suggestions.


1) Can we move the fields defined in django.contrib.localflavor.generic.forms 
to django.forms?

Currently the US-biased fields are in django.forms and the non-biased ones in 
django.contrib.localflavor.generic.forms — an interesting perspective :)

The alternative is to deprecate them entirely.


2) There's a dozen Trac tickets for adding new countries: Bulgaria, Nicaragua, 
Hungary, Malaysia, Venezuela, South Korea, Bangladesh, New Zealand, Guatemala, 
Latvia, Iran, Singapore.

Would it make sense to create these local flavors now — maybe after asking the 
community to update the patches if they aren't ready?


3) I'd like to see some guidelines on what features a local flavor is expected 
to provide.

Two examples:
- Are model fields that just inherit TextField and set a particular form_class 
useful? (#10087)
- Are pluralization template filters a good idea? (#17632)

I believe it's a good thing for the Django community to maintaining some 
consistency among local flavors. Since we plan to defer to local maintainers in 
each country, we should document the expectations and best practices.


-- 
Aymeric.



-- 
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-15 Thread Michael Hudson-Doyle 
On 16 October 2012 07:19, Jacob Kaplan-Moss  wrote:
> On Mon, Oct 15, 2012 at 7:42 AM, Anssi Kääriäinen
>  wrote:
>> In the end this is a decision with almost no technical considerations and a
>> lot of "good taste" considerations. So, this seems like BDFL area.
>
> Hi!
>
> After thinking a bit, I'm +1 on the idea, and I think
> `Queryset.first()` is the right name (which implies we should probably
> have a `last()` for completion).
>
> This mirrors the name used by a few other ORM/collection APIs that I
> think have really nice APIS:
>
> * SQLalchemy 
> (http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html#sqlalchemy.orm.query.Query.first)
> * Storm 
> (http://people.canonical.com/~therve/storm/storm.store.ResultSet.html#first)
> * Backbone (http://backbonejs.org/#Collection-Underscore-Methods /
> http://documentcloud.github.com/underscore/#first)

To me, first() is something else -- it implies an order (Storm will
raise an exception if you call first() on an result set without an
order) and it implies that it will not raise if the query matches more
than one object.  I thought the API proposed here more closely
resembled Storm's "one()" or SQLalchemy's "scalar()" (or maybe its
just how "get()" works already in SQLAchemy).

Not saying it wouldn't be useful, just different...

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: Update on localflavor move

2012-10-15 Thread Mahdi Yusuf 
Hi,

I have setup testing in a pull request
here
.

If this solution is acceptable. I can duplicate the process on the other
local flavours.

I would appreciate feedback.

--
Mahdi Yusuf

On Mon, Oct 15, 2012 at 4:16 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Adrian,
>
> Thanks for taking the lead on this! I reviewed related tickets in Trac and
> I have a few suggestions.
>
>
> 1) Can we move the fields defined in
> django.contrib.localflavor.generic.forms to django.forms?
>
> Currently the US-biased fields are in django.forms and the non-biased ones
> in django.contrib.localflavor.generic.forms — an interesting perspective :)
>
> The alternative is to deprecate them entirely.
>
>
> 2) There's a dozen Trac tickets for adding new countries: Bulgaria,
> Nicaragua, Hungary, Malaysia, Venezuela, South Korea, Bangladesh, New
> Zealand, Guatemala, Latvia, Iran, Singapore.
>
> Would it make sense to create these local flavors now — maybe after asking
> the community to update the patches if they aren't ready?
>
>
> 3) I'd like to see some guidelines on what features a local flavor is
> expected to provide.
>
> Two examples:
> - Are model fields that just inherit TextField and set a particular
> form_class useful? (#10087)
> - Are pluralization template filters a good idea? (#17632)
>
> I believe it's a good thing for the Django community to maintaining some
> consistency among local flavors. Since we plan to defer to local
> maintainers in each country, we should document the expectations and best
> practices.
>
>
> --
> Aymeric.
>
>
>
> --
> 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.
>
>


-- 
Mahdi Yusuf

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