> from OCC import BRep
> bb = BRep.BRep_Builder() --becomes--> bb = BRep.Builder()
Hmmm...
Perhaps Frank is right.
Its closing in on me too ;')
Yep, why not go for it.
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org
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 *
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
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.BR
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 questio
On Apr 28, 2009, at 2:42 PM, Thomas Paviot wrote:
>>> __But__: imagine a pythonOCC user do:
>>> from OCC.BRepPrimAPI import *
>>> MakeBox(...)
>>> The code will quickly be unreadbable (from which module comes the
>>> MakeBox object)?
>>
>> I'm not enough of a python user to know if this is a real
> 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
I'm no big python expert, but I think importing * is something you normally
do only when you are somewhere where you're very confortable, no? Like
importing a module you wrote yourself, or you know perfectly... I must
confess I never did it with pythonOCC because there are so many things in
each mo
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_
Arthur Magill a écrit :
> Hi Thomas,
>
Hi Arthur,
> Glad you're happy with the idea.
>
>
>> 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?
Hi Thomas,
Glad you're happy with the idea.
> 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? Certain
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 probl
+1 too!
Yorik
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
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, whi
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 soo
> 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 understoo
Hi Bryan
I must admit that I am not convinced of my own opinion regarding this
;-) My initial instinct when I first used pythonocc was exactly the
same as what you propose below, i.e. it felt really silly to be
repeating the package part in the class name.
Yet, I now have this nagging feeli
As a new user, I vote against having multiple levels of wrapper. I
don't want to have to choose between an elegant API and a complete
API. I also vote against abbreviating the crap out of name spaces and
embedding them into class names. If there's a way to avoid either
(i.e. a mostly aut
On Tue, 2009-04-28 at 17:40 +0200, Jelle Feringa wrote:
> > Oh, I thought the idea was to remove the "BRep_" part of the class
> > names. Sorry if I misunderstood!
> > - Frank
>
> No worries, that would be silly ;')
> Just going from `from OCC.BRep import *` -> `from OCC import BRep`
Uh Oh. Thi
> Oh, I thought the idea was to remove the "BRep_" part of the class
> names. Sorry if I misunderstood!
> - Frank
No worries, that would be silly ;')
Just going from `from OCC.BRep import *` -> `from OCC import BRep`
-jelle
___
Pythonocc-users mailin
I think most importantly the lowest level wrappers should exactly match
its C++ counterparts, i.e. the exact same class names, method names,
etc. On a higher "pythonic" level, one can obviously do a lot more, but
that's why there is going to be a "level 2", is it not.
Does anybody know why/how OCC
-1
Bryan Cole wrote:
I know IDE's are sensitive topics and an a very personal issue, but
from my experience Pydev is topnotch.
It also provides excellent support when importing with a wildcard
( which is what we do all the time ;')
I too am a pydev user. OK, the auto_completion issues
> I like your suggestion. It makes the code more compact (which seems
> like
> a pythonic kind of idea) and less redundant. I think it makes code
> more
> readable too. The only drawback I see is that it departs pythonOCC
> code
> further from straight C++.
I don't see how Arthur?
We're not
> I too am a pydev user. OK, the auto_completion issues isn't a problem
> when using wildcard imports, but this effectively forces us to use
> wildcard imports which is ... unpythonic!
True. Can't argue against that.
>> Doing the namespaces differently is non trivial,
>
> I'm not proposing to cha
Hi Bryan,
I like your suggestion. It makes the code more compact (which seems like
a pythonic kind of idea) and less redundant. I think it makes code more
readable too. The only drawback I see is that it departs pythonOCC code
further from straight C++. I don't think this as such a big issue, b
>
> I know IDE's are sensitive topics and an a very personal issue, but
> from my experience Pydev is topnotch.
> It also provides excellent support when importing with a wildcard
> ( which is what we do all the time ;')
I too am a pydev user. OK, the auto_completion issues isn't a problem
w
> I'm not sure if this has been debated previously, but I would very
> much
> like the pythonOCC wrappers to rename OCC class so as to remove the
> package prefix from the name.
>
> I am not fond of the lazy import syntax i.e.
>
>from OCC.BRep import *
>blah = BRep_Builder(...)
>
Hi All,
I'm not sure if this has been debated previously, but I would very much
like the pythonOCC wrappers to rename OCC class so as to remove the
package prefix from the name.
I am not fond of the lazy import syntax i.e.
from OCC.BRep import *
blah = BRep_Builder(...)
28 matches
Mail list logo
