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
