__in and comma-separated strings.

I've got a patch to let __in accept comma-separated strings; I'm using
this locally to avoid going through the trouble of splitting a string
before processing a GET. The exact same technique is used in
django-admin, and I'd bet many other apps as well.

Is there a reason why this behaviour isn't default, or should I send
the patch? __in will break on strings as far as I'm concerned.


J. Leclanche / Adys

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alex Gaynor]

On Tue, Oct 27, 2009 at 11:57 AM, Jerome Leclanche <adys.wh@...> wrote:

>
> I've got a patch to let __in accept comma-separated strings; I'm using
> this locally to avoid going through the trouble of splitting a string
> before processing a GET. The exact same technique is used in
> django-admin, and I'd bet many other apps as well.
>
> Is there a reason why this behaviour isn't default, or should I send
> the patch? __in will break on strings as far as I'm concerned.
>
>
> J. Leclanche / Adys
>
> >
>

I'd be -1 on this, this ties __in to an arbitrary serialization format
for no good reason.  Your view you knows what your particular logic
is, Django's ORM shouldn't be making wild guesses.

Ale

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche <adys.wh@...> wrote:
> I've got a patch to let __in accept comma-separated strings; I'm using
> this locally to avoid going through the trouble of splitting a string
> before processing a GET.

I'm -1 on this. Is `filter(foo__in=s.split())` really all that hard?

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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

It's not... if you got control over the code. However my patch is
specifically targeted at GET processing. You have to add a bunch of
checks after each other, it quickly becomes overwhelming.

Alex, I'm interested by what you mean exactly by "tying __in to an
arbitrary serialization format". What else would you propose?


J. Leclanche / Adys



On Tue, Oct 27, 2009 at 6:08 PM, Jacob Kaplan-Moss <jacob@...> wrote:

>
> On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche <adys.wh@...> wrote:
>> I've got a patch to let __in accept comma-separated strings; I'm using
>> this locally to avoid going through the trouble of splitting a string
>> before processing a GET.
>
> I'm -1 on this. Is `filter(foo__in=s.split())` really all that hard?
>
> 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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alex Gaynor]

On Tue, Oct 27, 2009 at 12:19 PM, Jerome Leclanche <adys.wh@...> wrote:

>
> It's not... if you got control over the code. However my patch is
> specifically targeted at GET processing. You have to add a bunch of
> checks after each other, it quickly becomes overwhelming.
>
> Alex, I'm interested by what you mean exactly by "tying __in to an
> arbitrary serialization format". What else would you propose?
>
>
> J. Leclanche / Adys
>
>
>
> On Tue, Oct 27, 2009 at 6:08 PM, Jacob Kaplan-Moss <jacob@...> wrote:
>>
>> On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche <adys.wh@...> wrote:
>>> I've got a patch to let __in accept comma-separated strings; I'm using
>>> this locally to avoid going through the trouble of splitting a string
>>> before processing a GET.
>>
>> I'm -1 on this. Is `filter(foo__in=s.split())` really all that hard?
>>
>> Jacob
>>
>> >
>>
>
> >
>

I meant precisely what I said, comma separating values in a GET string
is a fairly arbitrary means of serializing a value, in past I've seen
other characters used (or just having multiple values in the
querystring such as a=3&a=4), assuming a comma separated value is the
definition of arbitrary.  As for what I would propose instead:
nothing, what we have now works.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

On Tue, Oct 27, 2009 at 6:23 PM, Alex Gaynor <alex.gaynor@...> wrote:

>
> I meant precisely what I said, comma separating values in a GET string
> is a fairly arbitrary means of serializing a value, in past I've seen
> other characters used (or just having multiple values in the
> querystring such as a=3&a=4), assuming a comma separated value is the
> definition of arbitrary.  As for what I would propose instead:
> nothing, what we have now works.
>
> Alex
>

Right, I can see how this could become confusing. I just assumed a
comma-separated string would be pretty standard.
Point still stands, it's impossible to pass a true iterable (1-char
iterables don't count) to a GET. I did think of adding the possibility
of having multiple identical get keys, but this requires an overhaul
of GET handling in Django.

My long term goal: Releasing a django-filters (and django-jsfilters)
module which would make it easy to have very advanced filtering
methods on a project. You can see the concept on a live website here:
http://db.mmo-champion.com/items

Add Filter => ...
There's foreignkey handling, operators, etc.
Plan is to be able to autogenerate a listing like this one:
http://db.mmo-champion.com/static/js/definitions/filters.js
Plan is also to be able to handle Q()s and F()s seamlessly.

Changing topic a bit, then: What kind of changes would the GET backend
need to support this kind of features? I'm open to suggestions, even
if they have no chance to make it to django core.



J. Leclanche / Adys

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche <adys.wh@...> wrote:
> Point still stands, it's impossible to pass a true iterable (1-char
> iterables don't count) to a GET.

What?

>>> from django.http import QueryDict
>>> q = QueryDict('a=1&a=2&a=3&b=4&b=5')
>>> q.getlist('a')
[u'1', u'2', u'3']
>>> q.getlist('b')
[u'4', u'5']

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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Right.

I'll experiment a bit more with this and look for a better solution
than comma-splitting.

J. Leclanche / Adys



On Tue, Oct 27, 2009 at 6:39 PM, Jacob Kaplan-Moss <jacob@...> wrote:

>
> On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche <adys.wh@...> wrote:
>> Point still stands, it's impossible to pass a true iterable (1-char
>> iterables don't count) to a GET.
>
> What?
>
>>>> from django.http import QueryDict
>>>> q = QueryDict('a=1&a=2&a=3&b=4&b=5')
>>>> q.getlist('a')
> [u'1', u'2', u'3']
>>>> q.getlist('b')
> [u'4', u'5']
>
> 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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---