Frank Conradie a écrit : > Hi Jelle Hi Frank,
> > 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() I certainly was not clear or I misunderstood something. In a few words: * I understand 'class renaming' as the same as Frank: from OCC import BRep bb = BRep.BRep_Builder() --becomes--> bb = BRep.Builder() * To do that, it's necessary to rename the classes in the SWIG files (.i). This change may require about from 4 or 5 to 10 lines of additional code in the SWIG_generator.py script. When the change is made, the only modification to do in samples is to replace all underscores '_' with points '.' and that's it. Thomas > > 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 > _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
