Hey, wait! What if, better still, all of the types were declared with the parameters in the definition, so you can always tell what it is? Oh wait, that's java :)
Just kidding, I like python and java, but it amuses me a little. invariably people end up want all the syntax candy of a strongly typed language, but not enough to have to type the extra stuff. I'm one of the offenders: I whine about verbosity when writing java, and I whine about bad ides writing python. On 1/3/11, jelle feringa <jelleferi...@gmail.com> wrote: > 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 >> >> > -- Sent from my mobile device _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
