Minor nit and patch: I've found that really for me what users want to see is a case insensitive sort of objects, not the current python case sensitive sort. So that the order of objects from dtml-in and tree is a, A, b, B as apposed to A, B, a, b. Anyway Ive patched dtml-in and dtml-tree to do this sort on a ignore_case tag. Is this useful to anyone else? And Ive thought of patching my Zope so this is the default behaviour.... what does anyone else think. The next thing to patch is ZCatalog...
Andy McKay wrote:
Anyway Ive patched dtml-in and dtml-tree to do this sort on a ignore_case tag. Is this useful to anyone else?
yes! :-)
And Ive thought of patching my Zope so this is the default behaviour.... what does anyone else think. The next thing to patch is ZCatalog...
To be honest, why not just mail Guido (not literally! ;-) and suggest a change to python. IMNSHO, the default sort isn't as useful as it could be because of this and should be made to behave as you describe rather than like it is now. Pretty much every sort I do of strings in a python project uses the sort method below insetad of the default. This is a pain. def _default_sort(x,y): return cmp(string.lower(x),string.lower(y)) Who thinks the default python sort should stay like it is? Who thinks it should change? (reasons of course would be helpful, particularly if you want it to stay like it is ;-) cheers, Chris PS: With this being a general python issue, IMO, I've cc'ed to the python list, hope I'm not out of order... PPS: Is there such a thing as wishlist@python.org, if you see what I mean?
On Wed, 06 Dec 2000 18:00:31 +0000, Chris Withers <chrisw@nipltd.com> wrote:
(reasons of course would be helpful, particularly if you want it to stay like it is ;-)
I noticed the smiley, so Im not sure how serious the suggestion is. Ill bite anyway: 1. Python doesnt distinguish between 8-bit-strings and byte arrays. (for example, ZODB uses 8-byte-long 'strings' as oids). Do you want a casewise sort for byte arrays too? 2. 'sort' uses 'cmp'; so effectively you are asking for string's cmp to be case insensitve. Can you demonstrate a case-sensitive collation function that is as simple as your case-insensitive one:
def _default_sort(x,y): return cmp(string.lower(x),string.lower(y))
3. ZCatalog stores objects in a pre-sorted order. Changing the sort order of any object (not just strings) would break *all* existing ZCatalog instances that store mixed case strings. (and other applications too - the python language reference documents that this assmption is safe at least until python3k) Toby Dickenson tdickenson@geminidataloggers.com
3. ZCatalog stores objects in a pre-sorted order. Changing the sort order of any object (not just strings) would break *all* existing ZCatalog instances that store mixed case strings. (and other applications too - the python language reference documents that this assmption is safe at least until python3k)
Looking at this and other reasons I won't try to hack ZCatalog. I'll stick to making lower case string indexes.... Seems the safest all around.
I'm still trying to figure out what the missing pieces are... if anyone else has gotten a Linux Zope talking to a Win2K SQL Server 2000, I would appreciate some guidance. It seems I would have to write my own Product from scratch to do this, no matter what. None of the ODBC Products seem to be available for Unix, and ODBC from Unix <-> Windows will require additional software like EasySoft's ODBC Bridge anyway. Or I could just not use ODBC at all and make some Product customized to MS SQL Server. Some may suggest using ActiveState's Perl Methods for Zope and DBD::Proxy. :) It's a possibility, but I'd like to see if more conventional solutions exist. -- Neil Kandalgaonkar, ActiveState
I am currently running Zope <-> ZSQLRelayDA <-> SQLRelay+FreeTDS <-> SQLServer on NT. It works, but not particularly robustly it would seem. -d On Thu, Dec 07, 2000 at 02:57:28PM -0800, Neil K wrote:
I'm still trying to figure out what the missing pieces are... if anyone else has gotten a Linux Zope talking to a Win2K SQL Server 2000, I would appreciate some guidance.
It seems I would have to write my own Product from scratch to do this, no matter what. None of the ODBC Products seem to be available for Unix, and ODBC from Unix <-> Windows will require additional software like EasySoft's ODBC Bridge anyway. Or I could just not use ODBC at all and make some Product customized to MS SQL Server.
Some may suggest using ActiveState's Perl Methods for Zope and DBD::Proxy. :) It's a possibility, but I'd like to see if more conventional solutions exist.
-- Neil Kandalgaonkar, ActiveState
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- Dyon Balding <dyon@devcoder.com.au>
Thanks to everyone for their assistance yesterday. I feel like I'm really close to making this work now, but I can't get the Product to connect. I always get "Invalid connection string". One thing that puzzles me is the distinction between 'Server' and 'Datasource'. If Datasources are what we're defining in the interfaces file, that looks a whole lot like Server. I've seen PHP help pages dealing with these Sybase libs and MSSQL; somehow they only need to specify user, password, and database. TIA for any assistance you can offer. What I've done: ---------------- I have successfully compiled the SybaseDA product, with Sybase libs, etc, set SYBASE and LD_LIBRARY_PATH environment variables in Zope startup. As far as I know, I have created a valid 'interfaces' file. It looks like this: spindler master tcp eth0 xxx.xxx.xxx.xxx 1433 query tcp eth0 xxx.xxx.xxx.xxx 1433 where spindler is the hostname of my computer, xxx.xxx.xxx.xxx is the dotted-quad of my sql server. On the windows side, the SQL Server has Network Utility on, port 1433. (it refers to itself as SPINDLER, does case matter?) I created a test database with user/passwd and so on. The output I get upon connection: ---------------------------------- Invalid connection string: database: quux, password: xxxxx, server: spindler, transactional: Y, user: neilk Traceback (innermost last): File /home/neilk/Zope/Zope-2.2.4-src/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /home/neilk/Zope/Zope-2.2.4-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook File /home/neilk/Zope/Zope-2.2.4-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/neilk/Zope/Zope-2.2.4-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_adddcSybaseConnection) File /home/neilk/Zope/Zope-2.2.4-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_adddcSybaseConnection) File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Products/SybaseDAv2/DA.py, line 100, in manage_adddcSybaseConnection File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Shared/DC/ZRDB/Connection.py, line 132, in __init__ (Object: RoleManager) File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Shared/DC/ZRDB/Connection.py, line 161, in edit (Object: RoleManager) File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Shared/DC/ZRDB/Connection.py, line 240, in connect (Object: RoleManager) File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Products/SybaseDAv2/db.py, line 147, in __init__ File /home/neilk/Zope/Zope-2.2.4-src/lib/python/Products/SybaseDAv2/db.py, line 306, in _error BadRequest: (see above) -- Neil Kandalgaonkar, ActiveState
Toby Dickenson wrote:
(reasons of course would be helpful, particularly if you want it to stay like it is ;-)
I noticed the smiley, so Im not sure how serious the suggestion is.
It was serious, the smiley was 'cos I couldn't understand why anyone would want it to stay like it is :-)
1. Python doesnt distinguish between 8-bit-strings and byte arrays. (for example, ZODB uses 8-byte-long 'strings' as oids). Do you want a casewise sort for byte arrays too?
I don't know. Show me why this is bad :-)
2. 'sort' uses 'cmp'; so effectively you are asking for string's cmp to be case insensitve. Can you demonstrate a case-sensitive collation function that is as simple as your case-insensitive one:
def _default_sort(x,y): return cmp(string.lower(x),string.lower(y))
I see your point. I guess cmp is implemented in C? How about a third optional argument? def _case_sensitive_sort(x,y): return cmp(x,y,string.CASE_SENSITIVE) def _default_sort(x,y): return cmp(x,y)
3. ZCatalog stores objects in a pre-sorted order. Changing the sort order of any object (not just strings) would break *all* existing ZCatalog instances that store mixed case strings. (and other applications too - the python language reference documents that this assmption is safe at least until python3k)
Sorry, don't qutie follow this... explanation for a simpleton? ;-) cheers, Chris
Chris Withers wrote:
Who thinks the default python sort should stay like it is? Who thinks it should change? (reasons of course would be helpful, particularly if you want it to stay like it is ;-)
Python's sort() lets you sort based on not only strings but also tuples, lists, and numbers, which is a very useful feature. Thus sort() is intended to be a highly generalized method. It is useful but not ideal for sorting text strings. What you *really* want is a second method, perhaps in a new module (called "textops" or something similar) that would also include multilingual text splitters and other utilities for working with human-readable text. BTW have you ever tried this? data = [[], (), 0, '', {}] data.sort() print data The one thing I wonder is whether the sort order is consistent between different versions of Python. I get: [0, {}, [], '', ()] Shane
On Thu, 07 Dec 2000 10:54:06 -0500, Shane Hathaway <shane@digicool.com> wrote:
The one thing I wonder is whether the sort order is consistent between different versions of Python.
I actually have a Collector bug report on exactly this question. http://classic.zope.org:8080/Collector/1219/view (Status: pending. and has been for 8 months :-( In reality, I think it is only a theoretical problem. The current implementation takes much more care than it is required to by the language reference. Indeed, extra effort was taken in Python 2.0's implementation of Unicode. Toby Dickenson tdickenson@geminidataloggers.com
Shane Hathaway wrote:
BTW have you ever tried this?
data = [[], (), 0, '', {}] data.sort() print data
The one thing I wonder is whether the sort order is consistent between different versions of Python. I get:
[0, {}, [], '', ()]
This is consistent across Python versions. The sequence types are in alphabetical order: Dictionary, List, String, Tuple This is documented somewhere. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Shane Hathaway wrote:
Python's sort() lets you sort based on not only strings but also tuples, lists, and numbers, which is a very useful feature. Thus sort() is intended to be a highly generalized method. It is useful but not ideal for sorting text strings. What you *really* want is a second method, perhaps in a new module (called "textops" or something similar) that would also include multilingual text splitters and other utilities for working with human-readable text.
I agree that's a good idea, but all I'm talking about is the simple case of sorting strings, in which python's current implementation isn't very helpful and I don't see any situation where sorting: Andrew David Wayne bart sophie is better than sorting: Andrew bart David sophie Wayne cheers, Chris
See below (nothing earth shattering tho) ;) ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Shane Hathaway" <shane@digicool.com> Cc: <zope-dev@zope.org> Sent: Wednesday, January 03, 2001 10:58 AM Subject: Re: [Zope-dev] case insensitive sorts
Shane Hathaway wrote:
Python's sort() lets you sort based on not only strings but also tuples, lists, and numbers, which is a very useful feature. Thus sort() is intended to be a highly generalized method. It is useful but not ideal for sorting text strings. What you *really* want is a second method, perhaps in a new module (called "textops" or something similar) that would also include multilingual text splitters and other utilities for working with human-readable text.
I agree that's a good idea, but all I'm talking about is the simple case of sorting strings, in which python's current implementation isn't very helpful and I don't see any situation where sorting:
Andrew David Wayne bart sophie
is better than sorting:
Andrew bart David sophie Wayne
That's only because you use NT (ach spit). ;)
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Andrew David Wayne bart sophie
is better than sorting:
Andrew bart David sophie Wayne
That's only because you use NT (ach spit). ;)
Thats not actually true. It is how python behaves on WinNt, Win9X, Linux, etc (I have tested this) -Andy
Andy McKay wrote:
Minor nit and patch: I've found that really for me what users want to see is a case insensitive sort of objects, not the current python case sensitive sort. So that the order of objects from dtml-in and tree is a, A, b, B as apposed to A, B, a, b.
Anyway Ive patched dtml-in and dtml-tree to do this sort on a ignore_case tag. Is this useful to anyone else? And Ive thought of patching my Zope so this is the default behaviour.... what does anyone else think. The next thing to patch is ZCatalog...
The way I approached this was to have a ZPatterns attribute provider, or a method, that provides a modified version of the value I want to sort on. For example, I have a load of documents and folders with titles like Big Folder brown document "Berries for Cooking" list I wanted to present these sorted by non-case-sensitive first letter or number. So, I made a method "title_for_sorting" that stripped off any punctuation at the start, and returned the first 20 characters in all lower case. In this case, as it was a ZPatterns application, the method was presented as an attribute of the object using some skin-script. I used this attribute as a field-index in my SiteIndex ZCatalog. The reason I mention this is that sometimes case-insensitivity is not enough for sensible sorting. In this case, I had to strip out punctuation too. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Oh yeah for the ZCatalog I have two indexes one upper case and one lower case for some of my classes. No problemo. My area to attack though is the standard views such as the management interface... How's life in Lancaster? Went to school there and grew up in Garstang.... -- Andy McKay, Developer. ActiveState. ----- Original Message ----- From: "Steve Alexander" <s.alexander@lancaster.ac.uk> To: "Andy McKay" <andym@activestate.com> Cc: <zope-dev@zope.org> Sent: Wednesday, December 06, 2000 11:03 AM Subject: Re: [Zope-dev] case insensitive sorts
Andy McKay wrote:
Minor nit and patch: I've found that really for me what users want to see is a case insensitive sort of objects, not the current python case sensitive sort. So that the order of objects from dtml-in and tree is a, A, b, B as apposed to A, B, a, b.
Anyway Ive patched dtml-in and dtml-tree to do this sort on a ignore_case tag. Is this useful to anyone else? And Ive thought of patching my Zope so this is the default behaviour.... what does anyone else think. The next thing to patch is ZCatalog...
The way I approached this was to have a ZPatterns attribute provider, or a method, that provides a modified version of the value I want to sort on.
For example, I have a load of documents and folders with titles like
Big Folder
brown document
"Berries for Cooking" list
I wanted to present these sorted by non-case-sensitive first letter or number. So, I made a method "title_for_sorting" that stripped off any punctuation at the start, and returned the first 20 characters in all lower case. In this case, as it was a ZPatterns application, the method was presented as an attribute of the object using some skin-script. I used this attribute as a field-index in my SiteIndex ZCatalog.
The reason I mention this is that sometimes case-insensitivity is not enough for sensible sorting. In this case, I had to strip out punctuation too.
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Andy McKay wrote:
Minor nit and patch: I've found that really for me what users want to see is a case insensitive sort of objects, not the current python case sensitive sort. So that the order of objects from dtml-in and tree is a, A, b, B as apposed to A, B, a, b.
Anyway Ive patched dtml-in and dtml-tree to do this sort on a ignore_case tag. Is this useful to anyone else? And Ive thought of patching my Zope so this is the default behaviour.... what does anyone else think. The next thing to patch is ZCatalog...
The way I approached this was to have a ZPatterns attribute provider, or a method, that provides a modified version of the value I want to sort on.
For example, I have a load of documents and folders with titles like
Big Folder
brown document
"Berries for Cooking" list
I wanted to present these sorted by non-case-sensitive first letter or number. So, I made a method "title_for_sorting" that stripped off any punctuation at the start, and returned the first 20 characters in all lower case. In this case, as it was a ZPatterns application, the method was presented as an attribute of the object using some skin-script. I used this attribute as a field-index in my SiteIndex ZCatalog.
The reason I mention this is that sometimes case-insensitivity is not enough for sensible sorting. In this case, I had to strip out punctuation too.
Hm, reading this... just a loose comment. In light of the awkward search interface of ZCatalogs, would it be a good idea to make a search interface for ZCatalog ZPatterns based? This would add the possibility to make it configurable wrt case sensitivity, and to do nice things with ANDing and ORing different kinds of indexes. The only thing I can't judge whether it would be possible to make this generic enough. for-what-it's-worth Rik
Rik Hoekstra wrote:
Hm, reading this... just a loose comment. In light of the awkward search interface of ZCatalogs, would it be a good idea to make a search interface for ZCatalog ZPatterns based? T
I'm starting to feel like a stuck record on this, but lots of people seem to be asking for it in their own way... ;-) If the ZSearch Interface was properly documented and fully featured (ie defined how you search an object that supports the interface, and how you would index objects using that interface) then we wouldn't be stuck with the ZCatalog. It would enable people to write SQLIndexers, ZPatterns-based Catalogs and anything else they want, all of which would be freely interchangeable with the ZCatalog. Comments? Chris
Chris Withers wrote:
Rik Hoekstra wrote:
Hm, reading this... just a loose comment. In light of the awkward search interface of ZCatalogs, would it be a good idea to make a search interface for ZCatalog ZPatterns based? T
I'm starting to feel like a stuck record on this, but lots of people seem to be asking for it in their own way... ;-)
If the ZSearch Interface was properly documented and fully featured (ie defined how you search an object that supports the interface, and how you would index objects using that interface) then we wouldn't be stuck with the ZCatalog. It would enable people to write SQLIndexers, ZPatterns-based Catalogs and anything else they want, all of which would be freely interchangeable with the ZCatalog.
Comments?
Chris
I would love to see this happen. Sounds like a fishbowl project to me! -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
participants (12)
-
Andy Dawkins -
Andy McKay -
Casey Duncan -
Chris Withers -
Dyon Balding -
Neil K -
Phil Harris -
Rik Hoekstra -
Shane Hathaway -
Steve Alexander -
Steve Alexander -
Toby Dickenson