On Wed, Jul 20, 2011 at 11:33 AM, Ethan Furman <et...@stoneleaf.us> wrote: > as well as ignoring trailing white space for comparisons)
I wouldn't bother supporting that in the driver. Another background lesson: dBase started as an interactive environment. It didn't look like a spreadsheet, but think of a spreadsheet: the typical use is to start typing stuff in by hand, select some data with the mouse, hit sort, select some numbers and click Summation, see the results on the screen. At the time things were still in the relm of teletype machines were the only thing you looked at was printed output. Screens were new, and the API was still much like a printer. (not exactly true, there was the EDIT command that would clear the screen, draw field names and input boxes and let you enter data and tab/back tab around the screen.) It wasn't until later versions that they added the concept of stringing a bunch of commands together. conditionals came later. A design goal was syntax that is easy to type interactively, not make sense in a formal programming language. today we have "incremental search" where as you type query parameters the search is executed and you see results. If typing "KAR" is all you need to figure out "CARL KARSTEN" is the person you are looking for, then 3 keys are all you need to press. likewise, in dBase you could do DISPLAY FOR LNAME="KAR" and see just the rows where LNAME _begines with_ "KAR" which makes sense for an interactive environment, but causes grief when you try to write programs. later they added the == operator, but maintained backwards computability with the _only compare until you run out of chars_ behaviour. _backwards computability_ is the only reason to implement this in the driver, and given there is currenly no code relying on it, nothing will break if you don't. So don't :) -- Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
