Code completion is quite variable in my opinion, especially return types of
functions... in pydev it is possible to specifiy the argument/return types in
de docstring so that pydev recognizes and completes them:
def somemethod(a, b):
'''
@param a: list
@param b: SomeClass
@rtype: OtherClass
'''
Not sure how that works in other ide's and whether these are python standards
or pydev standards.
On Jan 3, 2011, at 2:10 AM, Patrick Janssen wrote:
> 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
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
