[Zope] Error: 'in ' requires character as left operand

[Dieter Maurer]

Benjamin Eastwood writes:
 > We have made some progress on this. I called in the resident Python guru 
 > (he's been at it a whole week...) and we had a look at the script. We 
 > modified it with a "Try" statement as follows:
 > 
 > for p in self.ac_inherited_permissions(1):
 >              name, value = p[:2]
 >              p=Permission(name,value,self)
 >              roles=p.getRoles(default=[])
 >              try:
 >                  d={'name': name,
 >                     'acquire': type(roles) is ListType and 'CHECKED' 
 > or '',
 >                     'roles': map(
 >                         lambda ir, roles=roles, valid=valid, ip=ip:
 >                         {
 >                             'name': "p%dr%d" % (ip,ir),
 >                             'checked': (valid[ir] in roles) and 'CHECKED' 
 > or '',
 >                             },
 >                         indexes)
 >                     }
 >              except:
 >                  continue
 >              ip=ip+1
 >              result.append(d)
 >          return result
 > 
 > Basically trying the thing that has been hanging, but continuing on 
 > exceptions. So for every chunk of data in the database that works, it 
 > works, but if its not working, it doesn't halt the process. I still 
 > don't see the Role I created in the list for new users, but I can now 
 > get to the security screens without it hanging up on that error. We 
 > think the bogus data is still there, but we don't care about it as much.
There is a single "in" in this code fragment. It is in "valid[ir] in roles".
This means, one of the "roles" is a string and not a sequence of strings
(as it should be).

    Add "import sys; print >> sys.stderr, roles, name" before your "continue"
    in the "except" clause.

    Then look at the output (you should run Zope in a terminal window
    to see the output; alternatively, you can also output into a file).

 > The question no becomes: What are the implications of this modification? 
Unrestricted "try: ... except: ..." are very bad style.
They can easily hide errors that should be manifest early in the
development cycle.

 > the system works, as far as we can tell, but we are concerned that we 
 > may have hosed something up but good further down the road.
Good, that you do not yet feel well!

  You should add the above print and find the true reason for
  this behaviour. After that, you remove the "try: ... except: ..."
  again.


Dieter