Automatic Generation of Python Class Files

[Bruno Desthuilliers]

Sunburned Surveyor a écrit :
> On Oct 22, 11:47 am, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> 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 !-)