Dear All,
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)?
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.
Best Regards,
Thomas
Arthur Magill a écrit :
> Excellent, I admire your flexibility ;-)
>
> The only person we need to convince now is Thomas.
>
>
> Frank Conradie wrote:
>
>> OK, I've thought about this again and we've discussed it here, and we
>> agree with the proposed change. As Bryan said it's really just a change
>> from an underscore to a dot, which makes perfect sense in the Python
>> world. In fact, I now think this is a rather vital change that should be
>> made as soon as possible.
>>
>> Also, converting our current code will be trivial, so we're not worried
>> about that aspect of it.
>>
>> +1
>>
>> Arthur Magill wrote:
>>
>>>> For example:
>>>>
>>>> OCC.BRep.BRep_Builder() -> OCC.BRep.Builder()
>>>> OCC.BRepPrimAPI.BRepPrimAPI_MakeBox() -> OCC.BRepPrimAPI.MakeBox()
>>>> OCC.Geom.Handle_Geom_Circle() -> OCC.Geom.Handle_Circle()
>>>> OCC.Geom.Geom_Circle() -> OCC.Geom.Circle()
>>>> OCC.gp.gp_Pnt() -> OCC.gp.Pnt()
>>>>
>>>>
>>> That's what I understood :-)
>>>
>>>
>>>
>>>> I don't regard this as a deviation of from the C++ API. Ultimately, it's
>>>> a consistent translation from "_" (C++ API) to "." (python API).
>>>>
>>>>
>>> I think it's a minor deviation - one that is entirely acceptable.
>>>
>>> As Jelle said:
>>>
>>> > Its *absolutely* an important issue that the SWIG wrappers ( Level1 )
>>> > feel like the C++ api, you're absolutely right.
>>>
>>> This change is obvious and small enough that we'll still be 'true' to
>>> the original API.
>>>
>>>
>>>
>>>> It's because of the importance of API stability that I want to make this
>>>> proposal now (maybe it's already too late. That's why I'm asking).
>>>>
>>>>
>>>>
>>> It's fair to expect anything below 0.5 (or some other arbitrary low
>>> number) to be a little unstable. Thus far, I don't think any of us have
>>> managed to write anything big enough that this change would be a serious
>>> PITA (or maybe I'm wrong...).
>>>
>>>
>>>
>>>> I'm grateful for the feedback on this. I don't want to spend time on a
>>>> patch which will ultimately be unacceptable to the rest of the pythonOCC
>>>> devs/users.
>>>>
>>>>
>>> If you've got the time/knowledge, I'd like to see this change.
>>>
>>> A
>>>
>>>
>>>
>
>
> _______________________________________________
> 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
