On Oct 22, 11:47 am, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Sunburned Surveyor a écrit : > > > On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > (snip) > >>I can't think of a single reason why you would ever want to do this, > >>since your "list of method and property names" would be just as > >>verbose as just typing the actual python code. > > >>Auto generated documentation stubs are considered harmful because they > >>take the place of real documentation.- Hide quoted text - > > (snip) > > > I don't think I understand how this would be the same amount of > > typing. > > For any well-designed, non-trivial code, my guess is that your solution > will end up needed *at least* as much typing. Trivial code doesn't of > course need any kind of code generation - doing it directly will be > faster anyway. I won't of course talk about badly-designed code... > > > Consider the following example that would generate a Monster > > class file from an input text file (I only did one property and method > > in generated class file.): > > > Contents of input text file: > > > [Name] > > Fire Breathing Dragon > > Why do you put spaces in the name ? > > > [Properties] > > Strength > > Scariness > > Endurance > > > [Methods] > > eatMaiden argMaiden > > fightKnight argKnight > > > Generated Python Class File: > > > def class FireBreathingDragon: > > should be: > > class FireBreathingDragon(object): > > > def getStrength(self): > > 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. IOW: > > class FireBreathingDragon(object): > def __init__(self, strength): > self.strength = strength > > def eat_maiden(self, maiden): > raise NotImplementedError > > <ot>following pep08 (coding style) might be a good idea</ot> > > Now if you're doing RPG, there will certainly be some mandatory > attributes for all characters, both players and non-players - IOW, > things like strength, endurance etc belong to a base 'Character' class. > And I seriously doubt that methods like 'eat_maiden' or 'fight_knight' > will survive the first design round... But anyway, a somewhat more > realistic example would look like: > > from MyRPG import NonPlayerCharacter, FireBreather > > class FireBreathingDragon(NonPlayerCharacter, FireBreather): > def __init__(self, *args, **kw): > super(FireBreathingDragon, self).__init__(*args, **kw) > # other class-specific code here, else might as well > # just skip the initializer > > def eat_maiden(self, maiden): > # code here > > def fight_knight(self, knight): > # code here > > Sorry, but I don't see the benefit of your code-generator here. > > > """ > > Docstring goes here. > > > @return > > @rtype > > """ > > I don't need nor want such a docstring in my code, thanks. > > 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.
Bruno wrote: "Why do you put spaces in the name ?" I made a mistake here. 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 unless I need to control how a property is accessed. Is this correct? 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. 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? I only ask because I am trying to learn how to write well designed Python code. :] Bruno wrote: "I don't need nor want such a docstring in my code, thanks." 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. Maybe I am trying to replace Java's static typing system with source code comments? 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. 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. Thanks for the feedback. Scott Huey
-- http://mail.python.org/mailman/listinfo/python-list
