[Tutor] Dynamic creation of class instances...

[alan.gauld@bt.com]

> I'm one of the folks who asked a question along the lines of 
> dynamic class creation. 

Thanks for replying.

> I think this misconception comes from the examples of classes 
> given in a lot of texts. 

That's what I figured must be wrong but I can't quite see how. 
The Python OOP intros are very similar to the Delphi/C++/Smalltalk 
intros I've seen but for somer reason its not an issue. Thinking 
about it the *requirement* to create variable names before using 
them in those languages probably is the reason.

> The examples given in most of the introductory 
> texts are fairly shallow and leave the impression to newbies 
> like me that a class is something you define generically so 
> that you can create specific instances of it at runtime. 

Which is true.

> So, I define a generic "snake" class, and then the user 
> can specify more details about his snake named "Slytherin" 
> and we'll save that as a new instance of the class at runtime. 

Which is also fine. It seems that the problem lies in the beginner 
feeling some need to name the *variable* that he uses to reference 
the new snake with the same name that is stored as an *attribute* 
of the snake. Now why would that be?

> account class, and each user will create his own instance of the bank 
> account at runtime. This was my concept for a while, and I'm only now 
> starting to move beyond it. 

Not sure what you mean by move beyond it. Its absolutely correct!

> As I learn more about classes it seems that the programs / 
> scripts that I have been writing are just too simplistic to really use 
> classes. 

That may well be the case. I deliberately left OO as an advanced 
topic because I didn't want newbies trying to walk before they 
could run!


> that they would be very useful in a larger project, but for my dinky 
> 100-line codes, it just seems that classes are not quite as practical.

100 lines is probably about where they do start to be useful but for
10-50 lines of code programs I hardly ever define classes.

> I think OOP was one of my first hang-ups with a lot of the Tkinter 
> tutorials, too. Most of the tutorials made their GUI programs using 
> classes, but only had one instance of the class. 

Having one instance is fine. But in GUI land using classes from 
the beginning is probably a good idea since it does lead to a 
more organised way of working that helps a lot when you get to 
bigger projects. And in GUI bigger is anything beyond trivial!

> that's an improvement. I understand how a Label() is a subclass of a 
> Widget(), but I don't understand why I have to create a class 
> just to make a GUI. 

Its the mental model concept. Your GUI consists of a window.
A window is an object. Therefore define the window as a class 
that is used as a container for the other widgets inside it.

> I guess that's why I wrote my own tutorial without 
> using classes for Tkinter.

Thats how raw Tk works too but it can get cluttered very quickly. 
Thats why my Tkinter intro starts off procedurally but quickly 
introduces classes. 

> I guess my suggestion, then, is to work on the introductions 
> to OOP and classes. 

Yep, I think so. The question is what aspect will change the 
perception that objects need to be named the same as their 
attributes....?
 
> realize that I can be a cool programmer even if I just use functional 
> programming most of the time. I like that. I grok functional 
> programming.

Hmm, I suspect you mean procedural programming (or imperative programming)
Functional programming is very cool but if you are using Tkinter 
you almost certainly aint using FP :-) But splitting hairs on 
terminology aside, you are right. Imperative programming was the 
main style for over 30 years and many cool systems are still 
written like that(Linux say...)

> the dark side via the exec() function. This function is not 
> really covered in beginning tutorials 

Thats why I am puzzled as to how so many pick up on it.
Virtually non of the intros (web or paper) mention exec().

> Well, those are my thoughts. Hopefully they're worth the paper their 
> printed on.

Indeed, and the bandwidth they consume.
Thanks for sharing them.

Alan g.
Author of the 'Learning to Program' web site
http://www.freenetpages.co.uk/hp/alan.gauld