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
