Hi Jelle
What you are talking about is *not* renaming - it is simply changing the
way OCC is imported in the examples. I think you are the one who is
confused ;-)
We all seem to agree (including Thomas) that on top of the import
changes, the *only* renaming we want is to remove the package
name+underscore from all *class* names, e.g.:
from OCC import BRep
bb = BRep.BRep_Builder() --becomes--> bb = BRep.Builder()
The "BRep_" part is redundant, and is only used by OCC as a kind-of
package naming scheme. In Python we have "real" packages, and in C++
nowadays they would probably have used namespaces. We are certainly
*not* advocating any method renaming, or case changes in class names.
For what it's worth, I was initially against this idea, but have thought
about it a lot over the last few days and am now convinced that we
should make this change.
- Frank
Jelle Feringa wrote:
Hi Bryan,
My feeling is that the discussion is getting a little out of control;
the renaming we have in mind isn't a big deal really.
As far as I'm concerned there is only one option that is worth
considering ( renaming classes / methods is _not_ acceptable )
Which is moving from `from OCC.BRep import * -> from OCC import BRep`.
That's all there is to it.
Changing methods would turn the documentation into a heap of garbage,
so that's *really* not acceptable.
However, it is fruitful as a community to discuss these in-depth, and
I thank you all for your ideas.
I hope that in the not too distant future, the Level2 api ( the
pythonic API we're working on, think of Topology.py as an example )
will become the dominant API for pythonOCC. Where increasingly, one
has to use the Level1 api less and less often. A syntactic difference
between Level1 and Level2 therefore is a useful idea.
This way you will be informed at what level you're working. Level1
would follow OCC's CamelCaps, where Level2 will follow python coding
standards ( lower_case_with_underscores_method_calls, see http://www.python.org/dev/peps/pep-0008/
).
Regarding lazy imports; we've thought about this too, but I don't
think its a good idea.
To be able to work well with pythonOCC ( anything that has tens of
thousands of methods really ), IDE support ( happy to hear your a
Pydev fan too ;') is critical.
Adding lazy imports is another firewall that very well might hinder
IDE support ( it would break in Pydev ) so I'm not much in favor of
that.
Thomas just informed me that the ( pretty trivial ) renaming mentioned
above would take him just 4 or 5 lines of code in the wrapping
mechanism.
I hope you can follow and agree with our reasoning here.
( I continue to be amazed with your Traits work Bryan ;')
Cheers,
-jelle
On Apr 29, 2009, at 10:51 AM, Bryan Cole wrote:
Thankyou everyone for the feedback.
After the interesting discussion, and Thomas' encouragement in
particular, I'll work on this. It may be a week or two before I have
any
results to show (I'm anticipating a particularly busy week, so OCC
work
is confined to my spare time).
Regarding the question of python lazy imports and naming conflicts,
I am
sure conflicts would occur. For example:
gp_Circle vs. Geom_Circle
However, I understand that it is standard python practice to avoid
lazy
imports (I certainly do) except in limited circumstances such as an
interactive terminal session. Really, we are removing the need for
lazy
imports: the correct and simplest way to distinguish the two Circle
classes is by their package prefix i.e. gp.Circle() vs
Geom.Circle(). We
should certainly make this clear in the docs for the benefit of new
python users. I expect experienced python programmers will follow best
practice by default. You also gain a little more flexibility this way,
since python allows you to rename modules on import i.e.
from OCC import gp, Geom as G
c1 = gp.Circle()
c2 = G.Circle()
Raising a warning or exception to prevent import * seems slightly
draconian, although this wouldn't inconvenience me personally.
cheers,
Bryan C
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
