Hi Thomas > I would also like to ensure that there will be no namespace conflicts in > the python wrapper. Here is a brief explanation: > Imagine there's a object, let's say A, that is a member of two different > OCC packages. For instance, let's assume there exist: > > BRepPrimAPI_A > and > gp_A > > With the replacement of '_' with '.', this will become, in python: > BRepPrimAPI.A > gp.A > > Let's now imagine that someone do the following: > from OCC.BRepPrimAPI import * > from OCC.gp import * > > Then an error will be raised since A is in defined in the 2 namespaces. > I don't want that the *risk* of such an error is possible (reliability > is the priority for now). > > This is an issue that Python programmers should be able to deal with, as many 3rd party modules, and even standard modules, contain classes/functions with identical names. The usual way to deal with this is of course by using package name prefixes (and not * imports).
As an example, this comes up a lot when using numpy, as it has unary functions like abs, min, max, sum, etc. that shadow the built-ins of the same name. As you said, prominent best practices guidelines should help. - Frank _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
