On Thu, 26 Jul 2001, Chris Withers wrote:

Can someoen explain lines 138 to 153 of FindHomes.py to me?

Is it documented anywhere?

Don't remember reading it anywhere. I can explain to you what the python code is doing, but I haven't actually tried to use it, so my explanation could have bugs (caveat emptor!): First, it picks up the value of the PRODUCTS_PATH environment variable (you knew that <grin>.) Then it checks to see if that value contains python style variable interpolations, and if so, it does the interpolations. This means PRODUCTS_PATH could be something like PRODUCTS_PATH="%(PRODUCTS_PATH)s /some/other/path" or PRODUCTS_PATH="%(SOFTWARE_PRODUCTS)s /some/path %(INSTANCE_PRODUCTS)s" where %(INSTANCE_PRODUCTS)s will be replaced by the path to the Products directory in INSTANCE_HOME, %(SOFTWARE_PRODUCTS)s will be replaced by a list containing the path to the Product directory from SOFTWARE_HOME (Python itself sets the initial value of this when Products is imported), and %(PRODUCTS_PATH)s is effecively a shorthand for %(INSTANCE_PRODUCTS)s %(SOFTWARE_PRODUCTS)s, as modified by the setting of the DISALLOW_LOCAL_PRODUCTS variable. Once this interpolation is done (if needed), the existing Products.__path__ list is emptied, the new products directory list is filtered to eliminate null elements, and then each element is checked to see if it is a directory and is added to the Products.__path__ list if it is. The end result of all this is that by using the PRODUCTS_PATH environment variable, you get to influence/add to the product search order, without having to hardcode the internal (SOFTWARE_HOME) Products path or the path to the INSTANCE_HOME Products directory. Note that if you use %(INSTANCE_PRODUCTS)s in your PRODUCTS_PATH string, that this will *override* the setting of the DISALLOW_LOCAL_PRODUCTS environment variable (ie: if INSTANCE_PRODUCTS appears in PRODUCTS_PATH, it gets used regardless of the setting of DISALLOW_LOCAL_PRODUCTS.) This could be a bug, or a design feature, and I can't decide which I think it should be <grin>. I'm leaning toward bug, though, in which case an 'else: ip = ""' would be an easy fix. FindHomes.py is hotpatching the python-computed value of Products.__path__, which is marked in the 2.0 PQR as a R/O variable, so I'm *real* suspicious of this in design terms. On the other hand, the PQR also lists it as 'string/undefined', and I've checked and it is a list in 1.5.2, 2.0, and 2.1, so maybe the PQR is also wrong about the R/O. (I learned something about python in writing this up: I definately did *not* expect 'del ppath[:]' to empty Products.__path__, since I'm used to using the [:] syntax to 'clone' (copy) a list. On the other hand, I did guess immediatly what the code was doing, it just surprised me that it worked, and it surprised me that it surprised me, since I usually find Python very consistent and intuitive. The docs do say that deleting a slice is "in general equivalent to assignment of an empty slice of the right type", so I guess really it *is* consistent...well learn something new every day...) --RDM