Hi Thomas, I am afraid that I am not an expert on this - I just did it by trial and error. I was hoping that there might be others with a better understanding of how code completion works. Apart from avoiding dynamic typing wherever possible, I don't have any simple suggestions. Along the way, I hit some problems - for example http://sourceforge.net/tracker/?func=detail&atid=577329&aid=2858499&group_id=85796 (I am not sure if that has now been fixed). And I just tried to work round these kinds of problems as best I could.
Patrick :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: On 29 December 2010 21:24, Thomas Paviot <tpav...@gmail.com> wrote: > 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
