|
From: Jussi S. <jus...@pp...> - 2006-09-17 09:25:46
|
And the plot thickens...
I've been playing a little with the multipropertyEditor changing the
place in question to look like this:
print '==========================='
if propName in self.checkItems:
print 'propName:', propName, ' in checkItems'
value = self.components["chk"+propName].checked
elif propName in self.popItems:
print 'propName:', propName, ' in popItems'
value = self.components["pop"+propName].stringSelection
elif propName in ('items', 'userdata') or (wClass == 'TextArea' and
propName == 'text'):
print 'propName:', propName, ' in items, userdata or ...'
value = self.components["fld"+propName].text
else:
print 'propName:', propName, ' in else:'
value = self.components["fld"+propName].text
print 'value, type:', value, type(value)
if propName == "textArea": propName = 'text'
if propName not in ['name', 'label', 'stringSelection', 'text',
'toolTip', 'userdata']:
try:
value = eval(value)
print '===> evaluated value, type:', value, type(value)
except:
print "===> Unexpected error:", sys.exc_info()[0]
pass
I then inserted a few component types and tried changing their
properties just to get a feel of what's going on.
1. A checkbox, for example. Trying to change its Checked property on and
off. Here's the result:
===========================
propName: checked in checkItems
value, type: True <type 'bool'>
===> Unexpected error: exceptions.TypeError
===========================
propName: checked in checkItems
value, type: False <type 'bool'>
===> Unexpected error: exceptions.TypeError
This is because eval expects a string and it gets a boolean. The error
was shadowed earlier by pass that 'handles' the exception.
I've been wondering in general about the true reason for this
value=eval(value) thing for a couple hours now and I think it could be
done (a) for validity checking, (b) for getting a useful value evaluated
or (c) for both. But in the particular case of checkItems, the
layouteditor itself has chosen either False or True as the value so
where is the additional value that it gets by checking&evaluating this
value? What I mean is that Checked, Visible and Enabled properties,
which all are booleans, should be listed in the not-in-check also.
2. A button, for example. If I enter (in the command field) the word
open (as I so innocently did before), click update, change open to
value, click update, change value to startTransfer and click update, I get:
===========================
propName: command in else:
value, type: open <type 'str'>
===> evaluated value, type: <type 'file'> <type 'type'>
===========================
propName: command in else:
value, type: value <type 'str'>
===> evaluated value, type: value <type 'str'>
===========================
propName: command in else:
value, type: startTransfer <type 'str'>
===> Unexpected error: exceptions.NameError
I understand the reason for the last exception, but I think it's
logically wrong in this situation. The validity check for the string
entered in the command field, say xyz for example, to my mind is that
the construction on_xyz_command has to be a legal form of a Python
method name. So what I'm saying is that I think the command string
should not be checked here at all but that it should undergo the same
check done for the name property a few lines later. The incidence that
started this thread (the first case above) is another kind of reason for
leaving the command checking out of this context.
What I don' understand at all is the result of the middle one of my
experiments. I think I should have gotten an exception but instead value
evaluates to value?!?
All in all: I can't see the value of this feature in layouteditor. The
evaluation is done in the editor's environment and I fail to see the
usefulness of having the possibility of using the values of the editor
entities in painting my application window!
Well, this was my 2 cents' worth. I'm no Python wizard and this was the
first time ever, that I've looked the resourceEditor under the cover.
Thus, what I'd like to hear would be KEA's (who's signatures throughout
the code make me believe he's the one who knows) explanation for this
eval. Maybe after that I would think differently about the matter.
Cheers,
Jussi Salmela
http://personal.inet.fi/cool/operator
Alex Tweedly kirjoitti:
> Jussi Salmela wrote:
>
>> Hello all and particularly Alex Tweedly, I guess!
>>
>> I'm using Python 2.4.3, wxPython 2.3.0, PythonCard 0.8.2 and its
>> Resource Editor on Win XP SP2.
>>
>> 1. I have an ImageButton and a bunch of other components on my page.
>> 2. I enter
>> open
>> into the command field of the ImageButton component in the Property
>> Editor.
>> 3. I click some other component(s) active and then click ImageButton
>> active again.
>> 4. The command field now contains
>> <type 'file'>
>> instead of the open I entered earlier.
>> 5. If I now run my program I get an error, so not only the display is
>> erroneous but also the resource file.
>> 6. If I retype open in the command field, save and run, everything
>> works as expected.
>>
>>
> Hmmmm - very interesting.
>
> 1. It's not unique to ImageButton - happens with any component.
> 2. It's (probably) not unique to the 'command' attribute - should
> happen to some others, but I haven't tried too hard to see which ones
> it happens with.
>
> It's caused by the following snippet of code in
> modules/propertyEditor.py (and /multipropertyEditor,.py):
>
>> if propName not in ['label', 'stringSelection', 'text',
>> 'toolTip', 'userdata']:
>> try:
>> value = eval(value)
>> except:
>> pass
>
> I'm not 100% sure why this was wanted. It does let you do interesting
> things - e.g. you can enter a string such as
> 3+8
> and it will be evaluated to 11 for you. You can enter a string like
> [20+3*15, 17]
> and it will be evaluated (to [65,17]) for, say, the position value.
> And various other more strange possibilities
> (e.g. enter self.position and you get the current co-ords of
> the property editor window !!)
>
> But I'm not clear on what the *useful* purpose of this eval is.
>
> In any case, the two oddities I know about are 'open' and 'file'
> which both eval to <type 'file'> (though there may be others).
>
> Suggestions (please comment):
>
> 1. short term - just avoid either open or file as command names :-)
>
> 2. figure out an exhaustive list of strings which eval to something
> they "shouldn't", and explicitly check for them (??)
>
> 3. decide that you never want to eval the user-entered value to
> produce a Python type, so add a test something like
> if not isinstance(eval(value), types.TypeType) :
> before resetting the variable 'value', thus
> if propName not in ['label', 'stringSelection', 'text', 'toolTip',
> 'userdata']:
> try:
> if not isinstance(eval(value), types.TypeType) : value
> = eval(value)
> except:
> pass
>
> 4. decide whether there is real purpose in doing an 'eval' here at
> all, and if there is, limiting the use to those cases, somehow.
>
>
>
|