Oh, you drive me nuts...

Ralf Schlatterbeck schrieb:
> I've repeatedly said that -- since the comma should be a decimal comma
> too, I DO NOT WANT the comma to mean "or".

But you know that we *need* to support things like

  2, 5

because they are supported currently for ids and integers.

> Same for blank. I DO NOT WANT a space to implicitly mean "or".

You know that we *need* to support the space, because thinks like

  2 5

are supported for ids.

Both cases are important for compatibility, and you don't mention them
in your proposal.  In fact, what you intend to do is to *break*
compatibility for very common and convenient search expressions.

> If you see ranges as things that can contain just one number (as it is
> currently implemented in roundup.date.Range) you won't need the sets.

Why would I want to see ranges like that? Ranges have limits, not members!

There is a reason for this implementation:  Roundup supports non-SQL
backends.  If it wouldn't, we would have supported date searches right
away using

  WHERE DATE(fieldname) = date1

and inclusive range searches using

  WHERE DATE(fieldname) BETWEEN date1 AND date2

Instead of generally impacting Roundup's search facilities it would have
been better do date range searches the SQL way and teach the non-SQL
backend to extract the date component from a datetime value.

Maybe you are too deeply involved in the Roundup code to be able to take
up an ordinary user's viewpoint.

> Zen of Python:
> Beautiful is better than ugly

Well, concerning curly braces, this is surely a matter of taste.
I like them.

> Readability counts

Sets with curly brackets are /very/ readable!
And surely,

  {1, 2, 5} or [10;20]

is very much better readable than

  1 or 2 or 5 or 10; 20

> Special cases aren't special enough to break the rules

You fail to name the rules which you accuse me to fail.

> There should be one-- and preferably only one --obvious way to do it

/preferably/ only one /obvious/ way.

But we *must* already support several ways, e.g. because of the existing
date range syntax.

> If the implementation is hard to explain, it's a bad idea

I /have/ explained my concept, and it wasn't hard at all.

The implementation can get modularized nicely and be easy to explain as
well.

> Or to fix a misconception: We don't need sets of numbers for full
> expressiveness.

What you mean is, you can express every search without using sets.

But this is *not* the same as expressiveness.

I won't answer to you anymore in this issue until you explain how you
intend to

- stay compatible to the current search facilities
  /without/ treating the comma and the blank like 'or'
- have ranges inclusive by default for numbers and get away without
  a configuration switch for the default range of dates ("magic lever")
- meet user expectations /without/ treating ids, which certainly
  /look like/ numbers, exactly like numbers

Maybe you understand it that way:

Ids walk like integers and swim like integers and quack like integers;
they certainly /are/ integers.

Well, of course they are not /real/ integers; they don't do all this by
themselves but need someone to wind them up first.

But surely they look like integers, and the common user doesn't know the
difference; thus, (s)he should be able to treat them like integers.

There is no need to turn ids into /real/ integers; the backend can
happily continue to take care of the winding up.

End of transmission.
-- 
Tobias