Do you have any hint about the "design of an API in a code-completion friendly way"? I guess a "code-completion friendly way" deals with code-completion compliancy with most famous python IDE (Eclipse/pydev - IPython etc.). I'm not aware of such issues and I would appreciate any further information.
BTW, is pythonOCC code-completion friendly in your opinion? Thomas 2010/12/29 Patrick Janssen <patr...@janssen.name> > I am OK with Python - it has many other plus points (I don't really want to > start a python versus x discussion). I just think that, wherever possible, > the python HLA needs to be designs in a code-completion friendly way. > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > > On 28 December 2010 21:01, Cowdens <dave.cow...@gmail.com> wrote: > >> i agree that code completion is a big deal. I use python and java in my >> day job, and though java is very verbose and has many issues, the code >> completion and strong typing of java makes writing code much faster. python >> definitely lacks ides as good as java has. >> >> >> ------------------------------ >> *From:* pythonocc-users-boun...@gna.org [mailto: >> pythonocc-users-boun...@gna.org] *On Behalf Of *Patrick Janssen >> *Sent:* Monday, December 27, 2010 10:52 PM >> >> *To:* pythonOCC users mailing list. >> *Subject:* Re: [Pythonocc-users] Re : Anyone seen this? (Dave Cowden) >> >> Hi all, >> >> This discussion is very interesting - I also made a start with PythonOCC, >> and somewhere along the way I got distracted by other things - partly >> because I found it hard to get started with PythonOCC. An HLA would be >> great! >> >> I have one thought I would like to add to the pot at this point... In >> order to make the HLA learning curve as smooth as possible, code completion >> is really important. But I have found that this is quite hard in python. I >> previously worked on a python api for Rhino ( >> http://code.google.com/p/design-automation/). The rhino COM api is a >> functional api - so you cannot script with objects. I found this very >> unsatisfactory, so instead I created an OO wrapper in python. As I got >> deeper into it, I kept hitting problems to do with code completion - I >> avoided as much as possible any dynamic typing, and managed to get code >> completion working in most places. But I found that it is important to think >> about code completion from the start. >> >> The problem of couse is that this is to some extent dependent on the IDE >> you are using - I was using pydev. So pydev will try to analyze the return >> type of functions and methods, so if in the HLA you create a function that >> returns a particular object, then the user should be able to get code >> completion to work on that object. However... there are still many cases >> where problems will crop up. >> >> For example, Dave wrote >> >> > i can perform the union of a two objects, creating a third one, and >> > convieniently return the resulting object for further manipulation >> >> A union may return one entity or (if the inputs do not intersect) more >> than one entity. This means that the HLA (i.e. the function or method being >> used) will have to return a list, which means that the user will not get >> code completion working on the entities in that list. If the user wants code >> completion, they will then have to use 'assert isinstance()' on the entities >> in the list. >> >> (As far as I know, there is no better way round this... any suggestions) >> >> Patrick >> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> >> >> On 27 December 2010 23:12, Dave Cowden <dave.cow...@gmail.com> wrote: >> >>> Hi, Thomas: >>> >>> I have one other suggestion also, coming from the 'agile' point of view. >>> the HLA is a huge and daunting task-- and thus the reason any discussions >>> quickly become large. I would recommend that a scope of work be decided >>> that is managable and allows producing something that we can get experience >>> with, rather than attempting to drive any particular approach ( top-down or >>> bottom up ) for the entire scope of the HLA. >>> >>> For example, perhaps we could agree that although the HLA contains much >>> scope, the scope that is most needed and straightforward is the creation of >>> primitives and basic CSG operations. The rationale would be that these are >>> the first operations new users are likely to perform, and are thus a good >>> starting point. Explicitly _out_ of scope would then be considerations of >>> parametrics, assemblies, fancy curves, multi-process coordination of >>> entities, etc. >>> >>> The best way I see to define this scope would be for you to approve the >>> user stories that the first release supports. For example: >>> >>> * "as a user of the HLA, i can programmatically create a sphere by >>> specifying its diameter and center point in space" >>> >>> * "as a user of the HLA, i can translate an object that has been created >>> without creating another variable reference. Preferably, the creation and >>> translation are accomplished in a single line" >>> >>> * ".... i can perform the union of a two objects, creating a third one, >>> and convieniently return the resulting object for further manipulation" >>> >>> Presumably these user stories would become test cases or suites for the >>> HLA. >>> >>> Something we could reach consensus on and release, however small in >>> scope, would be better than spending too long on discussions attempting to >>> consider the entire scope. I think having something conceptually simple >>> that we can iterate from would be very beneficial to coming up with an API >>> that works well. We are certain to find that we must re-work some of these >>> initial implementations to provide later functionality, but as long as the >>> test cases and user stories match well, this effort will be managable. >>> >>> >>> On Mon, Dec 27, 2010 at 8:07 AM, Thomas Paviot <tpav...@gmail.com>wrote: >>> >>>> Hi, >>>> >>>> Regarding the second point (basic primitives such as point, line, circle >>>> etc. or other entities like coord_sys, group etc.), this is exactly what >>>> we're thinking about for the 'High Level API' (HLA) for pythonOCC. In my >>>> opinion, it is the most important part of the pythonOCC project, since we >>>> all agree that the OCC library is too granular in order to be easily, >>>> quickly and efficiently deployed. >>>> >>>> On the other hand, this could solve one of the major issue of the >>>> pythonOCC project : the lack of documentation and/or >>>> tutorials/howtos/getting started. As it is currently designed (a python >>>> wrapper for the OCC library), writing doc for pythonOCC is the same thing >>>> as >>>> writing docs for the OCC project. It is clearly not our intent, and out of >>>> our skills/free time/etc. We are convinced that the use of both python and >>>> a >>>> HLA can really add value the OCC modeling kernel. Our documentation efforts >>>> would then focus on the HLA. >>>> >>>> However, the scope of this HLA has to be explicit and clearly delimited, >>>> and the semantics of the basic constructs must be shared among the >>>> pythonocc >>>> users or related projects. For instance, in the pycado project, you defined >>>> a 'group' entity. According to what I read in your code, the 'group' >>>> contains a set of basic operations/instance creation. In my opinion, this >>>> entity is not really a 'group' but rather an 'ordered set' since you cannot >>>> inverse the order of the elements of the group. It's however a good idea, >>>> but it has to be made explicit in order to avoid ambiguities in the use of >>>> this entity. I would like to work about that (a Platform Independent >>>> Model-PIM) before thinking about the implementation issues and the >>>> underlying technologies (python packages/modules, pycado or something else >>>> scripts, SOA and webservices, MOM etc.), that is to say before designing a >>>> set of Platform Specific Models (PSM) that would share a >>>> consistent,complete >>>> and extensible semantics (a top-down approach). >>>> >>>> I will post a new entry in the coming days, to sum up the exchanges >>>> related to the "have you seen this" thread and suggest a way/plan to let >>>> everybody interested in this work contribute the development of the HLA >>>> (the >>>> dual bottom-up approach). >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> 2010/12/23 julien blanchard <julien...@yahoo.fr> >>>> >>>> Hi, >>>>> >>>>> The layer above python was matching the best with our goals, in fact, I >>>>> see two >>>>> main parts in our project: >>>>> - the "IDE part" providing an optimized syntax for CAD and an efficient >>>>> graphical visualization (by updating only components being modified in >>>>> the >>>>> script since last refresh) >>>>> - the high level API written in pure python. This API should be used >>>>> both in >>>>> python project and pycado projects. >>>>> For now, the API contains the following primitives (can have several >>>>> "constructors"): >>>>> coord_sys (coordinate system), point, line, circle, vector, surface, >>>>> solid, >>>>> group (a group can join any primitive) >>>>> >>>>> Julien. >>>>> >>>>> ----- Message d'origine ---- >>>>> De : Dave Cowden <dave.cow...@gmail.com> >>>>> À : pythonOCC users mailing list. <pythonocc-users@gna.org> >>>>> Envoyé le : Mer 22 décembre 2010, 19h 35min 20s >>>>> Objet : Re: [Pythonocc-users] Re : Anyone seen this? (Dave Cowden) >>>>> >>>>> Hi, >>>>> >>>>> I am not a fan of pre-processors and scripts that are not pure python. >>>>> I think that such an architecture is unnecessary in a dynamic >>>>> language like python or javascript. Is it not possible to accomplish >>>>> the abstractions without pre-proccessing or another layer of syntax >>>>> above python? >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> > > _______________________________________________ > 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
