Python 3 offers standard for these. I agree it could be interesting to add this in the SWIGging...
On Mon, Jan 3, 2011 at 7:48 PM, Henrik Rudstrøm <hrudst...@googlemail.com>wrote: > 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 > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
