List & Dictionary properties; General property handling thoughts
This may seem like a redundant question, but this is the third time I've come across the desire to be able to store values persistantly as lists or dictionaries. I've read all the suggestions in the archives pointing out alternatives (<dtml-return expr="{'id': 'item'}">, TinyTable, string.split('value1|value2|..', '|'), "lines" property, SQL DB, etc.) but I still don't quite get the "Zen" of why this wouldn't make sense in practice. People have mentioned that it seems redundant with existing structures like tokens or lines, but these don't seem to have all the familiar benefits of lists and dicts, like instantly accessible mutability and _methods_, plus no added overhead. I know you can manipulate data within lists & dicts in a Python script, but it's just not why I require. Following this thought, I wonder if it wouldn't be handy to be able to cut, copy, & paste properties between valid objects, and provide a way to convert existing property values to different types? Also, the ability to import/export propertysheets of OFS objects could be useful as well (like in ZClasses). The facilities to do these things already exist, so would it be agreed by others in the community to promote these changes? Is it too late to try and work this into Zope3? Trying-to-help-Zope-grow-10x-ingly yours, Eron
Hi Eron, I believe tokens and lines properties are actually implemented as lists in python, so you should be able to use them that way. Maybe if you could give a compelling use-case for a dictionary property it would help clarify the need? In my own experience it seems that when at first I think I need a dictionary property.. what I really need is another class. ;-) -steve On Wednesday, December 26, 2001, at 05:37 PM, Eron Lloyd wrote:
This may seem like a redundant question, but this is the third time I've come across the desire to be able to store values persistantly as lists or dictionaries. I've read all the suggestions in the archives pointing out alternatives (<dtml-return expr="{'id': 'item'}">, TinyTable, string.split('value1|value2|..', '|'), "lines" property, SQL DB, etc.) but I still don't quite get the "Zen" of why this wouldn't make sense in practice. People have mentioned that it seems redundant with existing structures like tokens or lines, but these don't seem to have all the familiar benefits of lists and dicts, like instantly accessible mutability and _methods_, plus no added overhead. I know you can manipulate data within lists & dicts in a Python script, but it's just not why I require.
Following this thought, I wonder if it wouldn't be handy to be able to cut, copy, & paste properties between valid objects, and provide a way to convert existing property values to different types? Also, the ability to import/export propertysheets of OFS objects could be useful as well (like in ZClasses). The facilities to do these things already exist, so would it be agreed by others in the community to promote these changes? Is it too late to try and work this into Zope3?
Trying-to-help-Zope-grow-10x-ingly yours,
Eron
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hello Steve - Yeah, it seems that lines are stored internally as lists; tokens seem like a weird property to me with (kinda like a "tuple array"). Guess they would be handy for things like keywords, etc. My only problem with requiring a compelling reason to have a mapping property is that I shouldn't need one! If more than half of the built-ins are supported already, then why not provide for them all? Maybe this is just a general rant about Zope itself. Some very basic "Pythonic" concepts seem to be missing (the lack of "one way of doing it" being a big culprit); this is why some people move on to things like WebWare. Why do we need "lines" and "tokens" instead of traditional "lists" and "tuples"? Why a "boolean" property instead of a simple "0/1" integer value? "String" & "Text" are understandable, as well as "date", "int", "long", and "float". On the other hand, "selection" and "multiple selection" seem to mix content and presentation--something it seems the platform is trying to avoid. I think I will poke around in the internals a bit and try to make some sense of Zope's property handling infrastructure. It seems to be a "dusty corner" of the codebase that hasn't seen much love as of late. As I mentioned before, there are several revamps we could probably institutue now to make it more sensible. I just hope this doesn't have its roots deep within the dark layer of ZODB persistance. I'm about as able as a spelunker with a lighter for a torch when it comes to that point. Taking-a-"beginner's mind"-attitude-towards-Zope-Zen, Eron P.S. - Just got your book. Looks great! On Thursday 27 December 2001 06:01 am, Steve Spicklemire wrote:
Hi Eron,
I believe tokens and lines properties are actually implemented as lists in python, so you should be able to use them that way. Maybe if you could give a compelling use-case for a dictionary property it would help clarify the need? In my own experience it seems that when at first I think I need a dictionary property.. what I really need is another class. ;-)
-steve
On Wednesday, December 26, 2001, at 05:37 PM, Eron Lloyd wrote:
This may seem like a redundant question, but this is the third time I've come across the desire to be able to store values persistantly as lists or dictionaries. I've read all the suggestions in the archives pointing out alternatives (<dtml-return expr="{'id': 'item'}">, TinyTable, string.split('value1|value2|..', '|'), "lines" property, SQL DB, etc.) but I still don't quite get the "Zen" of why this wouldn't make sense in practice. People have mentioned that it seems redundant with existing structures like tokens or lines, but these don't seem to have all the familiar benefits of lists and dicts, like instantly accessible mutability and _methods_, plus no added overhead. I know you can manipulate data within lists & dicts in a Python script, but it's just not why I require.
Following this thought, I wonder if it wouldn't be handy to be able to cut, copy, & paste properties between valid objects, and provide a way to convert existing property values to different types? Also, the ability to import/export propertysheets of OFS objects could be useful as well (like in ZClasses). The facilities to do these things already exist, so would it be agreed by others in the community to promote these changes? Is it too late to try and work this into Zope3?
Trying-to-help-Zope-grow-10x-ingly yours,
Eron
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (2)
-
Eron Lloyd -
Steve Spicklemire