> Very interesting post actually. I worked all the day with Jelle for
> the
> PDE2009 presentation and read with attention this discussion. Here
> is my
> answer in 3 points:
>
> 1. I'm ok with the idea
> To be honest, I already thought about the class renaming a few months
> ago. I always had a problem with the expression, for instance:
> BRepPrimAPI.BRepPrimAPI_MakeBox(...)
>
> That does not sound very pythonic and creates a redundancy over C++
> code: in C++, you have only:
> #include <BRepPrimAPI.hxx>
> BRepPrimAPI_MakeBox(...)
>
> So, if we have something, in python, that can be written:
> BRepPrimAPI.MakeBox(...)
> I don't think that the python wrapper breaks the 'not written rule'
> that
> says that the python code has to be as close as possible to the C++
> code. It's just the replacement of a '_' with a '.'
>
> I'm then pretty convinced about that. It's just something I didnot
> take
> time to implement since I never considered it as 'critical' or as a
> 'priority'. It's something relevant to the API 'polish', and more
> serious issues had to be solve first. It seems to be a request from
> those who contributed to this post: so if someone wants to go into the
> development, Bryan for instance, well, let's go.
>
> __But__: imagine a pythonOCC user do:
> from OCC.BRepPrimAPI import *
> MakeBox(...)
> The code will quickly be unreadbable (from which module comes the
> MakeBox object)?
Uhuh... keep it simple: lets just get rid of the double
BrepPrimAPI.BrepPrimAPI_*
Lets not make it *any* more difficult than it should be.
Its a trivial renaming issue and easy to implement, while solving what
it should be solving.
I think its also been exhaustively debated.
> 2.Two things to check before going on
> Before this is commited to the subversion repository, I would like
> however to know where does this naming convention (OpenCascade I mean)
> comes from? why doesn't OpenCascade API use C++ namespaces? Certainly
> have to post a message on the OCC forum.
>
> 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).
>
> 3. Howto implement?
> - use the %rename SWIG directive
> - in the SWIG_generator.py script, just insert a few
> class_name.split('_')
>
> In my opinion, there should not have more than from 5 to 10 lines to
> add
> to the generator script. A good exercise actually for someone who
> wants
> to dive in the SWIG stuff.
>
> Conclusion:
> At last, I repeat the most important points (according to me):
> - reliability is the priority (a),
> - ensure that this improvement does not add any ambiguity (see the
> MakeBox example above) (b).
>
> (a) is an absolute priority
> (b) should be overcame if this new naming convention comes with strong
> recommandations/best practices.
Thomas, the Level1 API ***has*** to follow the C++ API.
The proposed change does that.
Any other additional complexification is simply destructive.
For instance, this is what TVTK does ( changing C++ method names ) and
its the _only_ part of TVTK that I consider a design mistake.
Lets not repeat those.
-jelle
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
