Behalf Of Arthur
But I am certainly convinced that the freedom to make mistakes is unassailable as part of a learning process. And therefore conclude that programming in the style that Python allows is an unassailable and under-utilized educational resource.
Clarifying what I mean here, and asking some real questions at the same time. No, I don't think writing code in Python is so free as to be more subject to the problems of programmer error, but that's OK because it is good for learning. What I do mean perhaps goes back to the discussion of properties and the Uniform Access Principle. There are languages that believe so strongly in the importance of the UAP, that it is imposed within the design of the language - from what I see Ruby and Eiffel offering the strictest implementations. But if one were to be learning programming from, say Ruby, it seems to me that there are at least two things that it will be near impossible to discover: 1) The basis for a conclusion that the Uniform Access Principle should be considered an inviolate principle. 2) The basis for a conclusion that it should not be. Because one cannot explore the possibilities (and problems) of working both within and outside of it. The Python environment - providing properties as a convenience for exploring the possibilities of working within it, and the ability to ignore them for exploring the possibilities of working without - seems optimum. For learners/explorers - for sure. But I would expect for fully grown-up programmers as all. That being said - still not getting the UAP thing. Which seems to be saying that distinguishing between assigned attributes and methods that do not take parameters is an implementation detail, and hiding it, benefits (is essential to) API design flexibility - via a decoupling. But why is distinguishing between methods that do and do not take parameters any more justified, and isn't doing so its own kind of violation of a principle of decoupling. None of this questioning coming from the abstract realm - because I am exploring in a language that does inhibit exploration. If anyone is still reading... One of the cases in which I used properties and thought I had it right - on the getting of a vector I wanted the return, for purposed of drawing, to be constrained to some MAX value, which is a module level constant. So I had a method that would return a constrained vector, and since the vector itself was a plain attribute, it felt right to flatten this constrained version of a vector via a property. Now I find there are advantages to having the MAX value be sensitive to certain conditions of the caller. And I want the caller to call the method with a MAX value that is appropriate to its needs. So I have no choice but to de-propertize the method. In the case of Kirby's Triangle angle, might it be wise to avoid the possibility of exploding any spacecraft, and insist that a contract be formed with the caller so that the caller must specify whether they are expecting the return value in radians or degrees? Seems maybe yes. But that requires a parameter, though changes nothing else about what the angle is in relation to the Triangle. So the UAP is not getting through here. Art