Re: [Pythoncard-users] Resource Editor bug (?)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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.
>
>
>