Sunburned Surveyor a écrit : > On Oct 22, 11:47 am, Bruno Desthuilliers > <[EMAIL PROTECTED]> wrote: (snip) >
> Bruno wrote: "You don't need these getters and setters. Python has > support for > computed attributes (look for 'property'), so until you need to > control > access, a plain attribute is all you need." > > So I don't use getters, setters, and the property() function Actually, it's a class. But anyway... > unless I > need to control how a property is accessed. Is this correct? It is. The default is to use a plain attribute unless you already know you need a computed one. Also, properties are just one example use of the descriptor protocol, which you can use to define your own 'smart properties' (it's a common idioms for ORMs and like). > Bruno wrote: "And I seriously doubt that methods like 'eat_maiden' or > 'fight_knight' > will survive the first design round... " > > I'm not really designing an RPG. I was jsut trying to come up with a > simple example. I think I did guess this - but nonetheless, it looked to much like a bad example of OO design to me. > What you said about inheriting from a base class like > Character makes sense. I am curious thought, what sounds wrong with > methods like "eatMaiden" and "fightKnight". Are you thinking they > should have been something like "eatCharacter" and "fightCharacter" > instead? Looks somehow better. Now what about 'eat' and 'fight' ?-) > I only ask because I am trying to learn how to write well > designed Python code. :] It's not really Python-specific - it's about not hard-wiring what should be generic. > Bruno wrote: "I don't need nor want such a docstring in my code, > thanks." Fact is that I don't really like all those XXXdoc systems. But mostly, it's because, as other pointed out, no docstring is better than this template code. > I guess epydoc isn't for everyone? :] Maybe I like it because it > reminds me of Javadoc. It seemed useful to me because it helped define > a "protocol" that could be followed for proper use of an object. Which is certainly a sensible concern. Now as far as I'm concerned, a listing of arguments names and type is not the best approach. Good naming, textual explanations and code examples are IMHO better. > Maybe > I am trying to replace Java's static typing system with source code > comments? Documenting what 'kind' of objects your function waits for and/or returns - and/or what's the function's intent - is certainly not a bad idea in itself. But you don't necessarily needs that much formalism. Most of the time, the source code is readable enough for those who want/need a very formal and *exact* definition of the function !-) > Bruno wrote: "Don't take it bad - there are languages that requires so > much > boilerplate that without code-generators, productivity tends to drop > near zero. But that's not the case with Python." > > This thread is helping me to realize this. Then welcome onboard !-) > I suppose the only thing my > generator would be good for is the doc comments, and it doesn't sound > like most of you would want those anyways. Indeed. Another point is that, when it comes to 'boilerplate reduction', Python has far more to offer than textual code generation. Using a combination of custom descriptors, decorators, metaclasses and closures (and of course more common patterns like the template method...), you can abstract out pretty much of the 'plumbing' *without* any textual source-code generation. You may want to have a look at Elixir (an ActiveRecord inspired tiny declarative layer above SQLAlchemy) or FormEncode (a validation/conversion package) to see what I mean. > Thanks for the feedback. Thanks for reading the feedback !-) -- http://mail.python.org/mailman/listinfo/python-list
