[Edu-sig] "Model syntax changed" (was Design Patterns)
>Suppose you'd already published a Triangle class API and then discovered >you needed more dynamism. The property feature lets you sneak in some >methods without changing the already-published API and breaking client >code. >A lot of these lessons about robust software development come from group or >community efforts. Some aspects of Python maybe don't much excite you >because you're primarily a solo coder (as am I much of the time). Not claiming this is directly counter to the above, but it is interesting in this context to look at something happening on the ground, re: Django "Model syntax changed" http://www.djangoproject.com/weblog/2005/aug/25/modelsyntax/ """ This is the first really big community-driven improvement to Django, and it's been awesome to see it come to fruition. Thanks, guys! """ Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Python is not Java
Yeah for naivety! In the pretty widely discussed article: "Python Is Not Java" http://dirtsimple.org/2004/12/python-is-not-java.html """ Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well. In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. """ Guido's example for properties in the "classic" "Unifying types and classes in Python 2.2" Begins to shed some light for me on the Pythonic use case for properties - when something quite specific needs to be triggered by an access to or attempt to set what is otherwise a regular attribute - in this case a constraint on setting x. http://www.python.org/2.2.2/descrintro.html#property class C(object): def __init__(self): self.__x = 0 def getx(self): return self.__x def setx(self, x): if x < 0: x = 0 self.__x = x x = property(getx, setx) I'm quite OK with properties - with this narrowly defined use case in mind. Anyway -*I* feel like this discussion led me somewhere. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
Kirby Urner wrote: >>So I find that rejecting it as naïve is fundamentally unresponsive. >>Art > > However in this case I don't think your views were rejected as naïve. On > the contrary, your views permeated a sophisticated discussion of use cases, > and design patterns more generally (s'been a rich thread) plus Scott sort of > liked your using () to connote dynamism (I didn't). This is close to what I meant. I dislike properties that don't behave as if they were attributes. That is, I'd like two accesses to the same property of a particular object to return the same value until the object has been "changed," and I don't like read access to a property to be a "real" change. There are three exceptions I allow in my personal aesthetic: * debugging code: All's fair for this case. Properties are _golden_ for allowing tracking things into a lot of code without changing that code. * instrumentation: Measurements can be accumulated about behavior, but shouldn't interact with normal operation. * performance:Achieving the same results with different performance is often the whole point of systems programming style programming. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Scott David Daniels > > This is close to what I meant. I dislike properties that don't behave > as if they were attributes. Not exactly sure what that means. Seems there is a lot to this topic. I get to the fact that there is a Uniform Access Principle - with some authority behind it. """ The Uniform Access Principle, as published in Bertrand Meyer's Object-Oriented Software Construction, states that "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." It is described further with "Although it may at first appear just to address a notational issue, the Uniform Access principle is in fact a design rule which influences many aspects of object-oriented design and the supporting notation. It follows from the Continuity criterion; you may also view it as a special case of Information Hiding." """ I guess I am intuitively anti-Meyerist. And am hoping he is quite wrong in the assessment that "information hiding" is a base requirement for information science. ;) Kirby seems comfortable in the Meyerist camp. But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python sentiments. So am having trouble with my Meyerist Python friend's stance. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
> Kirby seems comfortable in the Meyerist camp. > I think you might be reading something too sinister into "information hiding" and are therefore against it. The brutal real world truth is the client wants an API that works today, but will complain if it doesn't deliver tomorrow, even if specs shift in the mean time. A lot of programming arises from this dual use: freedom to use now, freedom to change it under the hood later. Properties help insert a layer between mutable programmer code and a slick API that clients like and want to keep using. It's a matter of keeping a favorite notation relatively static, thereby insulating users from messy inner details. That's *one* meaning of information hiding, and I think a benign one. My world assumes you have access to source code. Information hiding is relative to something. If you have no source code at all, then it's all hidden, and so what's the point of even talking about what's hidden or not? > But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python > sentiments. So am having trouble with my Meyerist Python friend's stance. > > Art I think you're espousing an open source ethic, but maybe confuse the purpose of properties with something "information hiding" needn't mean. It could just mean a notational integrity that insulates programmers from other programmers. It's like wearing business suits or casual dress. We don't want to keep adjusting our eyeballs from one freakazoid API to another. Just give us a uniform integrated control panel please, and do your behind the scenes work behind the scenes (but let us peek if we get curious). Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
