re: Does edu-sig extend to Jython
Jason writes -
An excellent use of Jython is to provide CLI interface for Phil Burke's remarkable 'Jsyn' - Java Audio Synthesis API.
From my own experience - my exploration of Jpython led naturally into an exploration of Java. At some point
As a general statement, obviously a beauty of Jython is the ability to access Java libraries and apps from Python. But certainly there is a "learning to program" aspect in addition.. the transition to writing pure Java came easily. The fact that I ended up returning to CPython almost surprised me. But it happens that VPython provided me with most of the 3d graphics capabilities I needed and had been looking to Java libraries to provide, and that I "think better" in Python - partly because it feel more finite and with less "magic" to it. What I miss most about Java, though, is one particular brand of magic - method overloading.
From the user prospective, for the kind of thing I am doing, it greatly simplified things.
For example, I could provide for a class taking two arguments of different type to accept the arguments in either order. In Python I need to either use named argments, or handle it on initialization in ways that get to be complex, or use separate classes, or expect my user to learn or reference the acceptable order of argmuents. So far I have put the burden of the user. Since the only very active user happens to be me - it works out well enough. Probably less acceptable for this kind of app if it were to have a wider user base - especially where the novice is the intended audience. Advice being welcomed on this issue. Art
[Arthur]
What I miss most about Java, though, is one particular brand of magic - method overloading.
[snip]
Advice being welcomed on this issue.
Could you post an actual code example of what you are trying to accomplish? If so, we might be able to come up with some alternatives. But I can't think of a solution without having a bit more detail to think about. -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------
Could you post an actual code example of what you are trying to accomplish? If so, we might be able to come up with some alternatives. But I can't
Patrick writes - think
of a solution without having a bit more detail to think about.
Well say I have a Point class which basically defines a drawing method, and keyword args like "color", and "pointsize" to control appearance. I am working in 3d space. A point defined as an intersection can be defined - let's say - by a plane and a line (or a line and a plane) or two lines (if the lines are coplanar). Where I am now in Python is two separate classes: PlaneIntersection(plane, line, **kw) #argument order therefore significant and LineIntersection(line,line,**kw) In Java, Intesection will behave on the basis of the signature of constructor: I can do something significantly more verbose, but effectively akin to: Intersection(Point): def __init__(*args,**kws): Point.__init__(**kw) (initialize class attributes here) def update(self): (test for existence of intersection and update position of point here) and so where "plane" is a Plane instance "line" is a Line instance Intersection(plane,line) Intesection(line,plane) Intersection(line,line) could all work appropriately without too much todo. Now I think I understand it is mostly Python's dynamic nature that makes this kind of facility difficult (impossible?) to implement as a built_in language feature. And I think I understand the possiblities, at least in general, of a lot of isinstance or type testing of *args - but its ugly, and error-prone - at least, that is, up until the point at which the rest of the design is sufficiently stabilized so that I know *exactly* what it is I want to be testing for and am not expecting any more changes to be coming down the pike. Seems to be the nature of my approach, that I never quite get to that point. So, I am beginning to try to digest the meaning and significance of "multimethods" - for which there are Python modules. I guess then my question, which I am pursuing, is what are multimethods, and how might they relate to the issue I am trying to deal with? Art
[Arthur]
[example snipped]
Now I think I understand it is mostly Python's dynamic nature that makes this kind of facility difficult (impossible?) to implement as a built_in language feature.
Yes and no. It certainly isn't Python's default mode of operation to care too much about the type of an object, versus what an object is capable of doing.
And I think I understand the possiblities, at least in general, of a lot of isinstance or type testing of *args - but its ugly, and error-prone - at least, that is, up until the point at which the rest of the design is sufficiently stabilized so that I know *exactly* what it is I want to be testing for and am not expecting any more changes to be coming down the pike. Seems to be the nature of my approach, that I never quite get to that point.
Checking via isinstance() shouldn't be too difficult. But it may not even be necessary.
So, I am beginning to try to digest the meaning and significance of "multimethods" - for which there are Python modules.
I found one at http://www.sff.net/people/neelk/open-source/Multimethod.py. Is that the same one you are talking about?
I guess then my question, which I am pursuing, is what are multimethods, and how might they relate to the issue I am trying to deal with?
Multimethods appear to be exactly what you are asking for. But I'm not sure they are the right thing to be asking for, if you know what I mean. :-) Let's look at your example of an Intersection constructor and the variations you want to support: Intersection(plane,line) Intersection(line,plane) Intersection(line,line) What I'd ask is why do you need to know the types of the two parameters? At what point does it matter? What method(s) of Intersection need to function differently in each of the three cases? I think we need to see more code to figure out whether this can't be handled without too much regard for object types. And even if some type checking needed to take place, multimethods seem like overkill to me. -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------
Patrick writes -
Checking via isinstance() shouldn't be too difficult. But it may not even benecessary.
No. And would work fine, I'm sure, if I wasn't doing as much experimentation and on the fly kind of stuff as I go. Even if a bit messy, at least I know I don't need to worry about this kind of thing as a performance issue of significance, if I can limit the isinstance checking to the initialization routine. I *am* sensitive to trying to keep that kind of thing out of any update cycle where possible, as the app is graphical and dynamic and performance can be an issue. Perhaps I am just being somewhat lazy in my approach - and I need to be doing more of this upfront as I go along.
So, I am beginning to try to digest the meaning and significance of "multimethods" - for which there are Python modules.
I found one at http://www.sff.net/people/neelk/open-source/Multimethod.py. Is that the same one you are talking about?
And one at: http://bent-arrow.com/python which I'm thinking is more recent and under more active development - but I'm not sure.
Multimethods appear to be exactly what you are asking for. But I'm not sure they are the right thing to be asking for, if you know what I mean. :-)
Let's look at your example of an Intersection constructor and the variations you want to support:
Intersection(plane,line) Intersection(line,plane) Intersection(line,line)
What I'd ask is why do you need to know the types of the two parameters? At what point does it matter? What method(s) of Intersection need to function differently in each of the three cases?
I think we need to see more code to figure out whether this can't be handled without too much regard for object types. And even if some type checking needed to take place, multimethods seem like overkill to me.
Well, I am senstive to taking the discussion too far off topic to edu-sig - though I do have every intention of doing my best to pick your brain off list. Art
Arthur, Don't be too quick to take this off-list. While your situation is pretty specific, the general case of "why doesn't Python support feature X of language Y" seems to be appropriate here. There are several possible answers, all valuable in an educational context: 1) It does support X, but the python idiom looks like X() 2) X isn't needed because of python feature Z 3) Python doesn't support X because X is a bad idea for such and such a reason 4) Python doesn't support X, but you can do Z to simulate it etc. In your case, if both Line and Point have methods getHalfIntersection(), could you then have: def intersection(first, second): return first.getHalfIntersection() * second.getHalfIntersection() where "*" is replace with the real operation or set of operations needed and getHalfIntersection is replaced with whatever is specific to lines and/or points? --Dethe
[Dethe Elza]
In your case, if both Line and Point have methods getHalfIntersection(), could you then have:
def intersection(first, second): return first.getHalfIntersection() * second.getHalfIntersection()
where "*" is replace with the real operation or set of operations needed and getHalfIntersection is replaced with whatever is specific to lines and/or points?
Good point. Here is another very simple (and contrived) example as further support of your point:
def dup(first, second): ... return first * second ... dup(3, "this") 'thisthisthis' dup("this", 3) 'thisthisthis'
-- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------
participants (3)
-
Arthur -
Dethe Elza -
Patrick K. O'Brien