`set()` collision with python

[mrmin123]

Hi Raiman,

I recently had a user report an issue with set() in a sikuli-based python script throwing an unexpected error:

[error] TypeError ( set(): 1st arg can't be coerced to org.sikuli.script.Location, org.sikuli.script.Region )

I did some testing and it seems like the set() builtin is being overwritten by sikuli:

print(set.__class__)
# <type 'instancemethod'>

print(set.__class__.__module__)
# '__builtin__'

print(set(['a'])
# [error] TypeError ( set(): 1st arg can't be coerced to org.sikuli.script.Location, org.sikuli.script.Region )
# expected: set(['a']), <type 'set'> for __class__, and '__builtin__' for __class__.__module__

print(set(org.sikuli.script.Region(1, 1, 1, 1)).__class__)
# <type 'org.sikuli.script.Region'>

print(set(org.sikuli.script.Region(1, 1, 1, 1)).__class__.__module__)
# 'org.sikuli.script'

I've made a cursory search through the repo and identified a potential cause: L55-56 in IScreen.java.

I'm not sure what your intention is with the new Sikuli set() functions but a heads up that it seems to be overloading python's builtin set().

This behavior does not exist in 1.1.1.

Thanks for all your hard work!

edit: current workaround:

import __builtin__

__builtin__.set(['a'])
# set(['a'])

[RaiMan]

Thanks for finding, evaluation and feedback.

The problem is caused by the fix

https://bugs.launchpad.net/sikuli/+bug/1742389

which introduces a set() function for class Screen() and hence for the default global SCREEN object at the Python level.

I changed this now in a way, so that an undotted set() function is no longer seen at the Python level.

[RaiMan]

fixed with 1.1.2 build 94 today