Some time ago I read something about how classes are sometimes thinly veiled globals. I can't remember if this was agrued in general or specific to python.Either way, when you look around the web for examples you'll find a lot of small programs that are basically just a single class, instantiating that class and then running it. Now I notice myself doing pretty much the same. My current project so far involves a calculation and GUI for that calculation. They are being developed in separate files, they're not connected yet. I imagine keeping them separate and later on import the calculation into the GUI file.Since separate files have separate namespaces anyway so I'm wondering what the point is of single class programs (or program files) like that. You might as well make everything global to the file and use functional programming instead of OOP. self.bla would just become a global variable. Obviously you shouldn't because everyone says so, so I must be missing something. Thoughts?

Well, structuring things into classes makes them more re-usable (in theory, anyway). You could use that class on another project simply by importing it, without having to copy it around (and worry about whether you've copied everything you need). Even if it's only one class now, the program may grow as functionality is added, and people are doing things "properly" from the start. Sometimes it's just a force of habit -- whenever you want to implement some bit of functionality, you immediately structure it as a class In some languages, everything has to be inside a class -- even when writng "Hello, World!", you need to write a class; people coming from these backgrounds are ofter more comfortable with sticking everything in a class. In some cases, it's because people aren't doing things propertly -- they're cramming everything into one class, when really, they probably need several.

The "thinly veiled globals" comment is probably talking about people just using classes as "structs" -- basically just groupling a bunch of value together, but then just passing these classes around in global functions, rather than implementing the functionality in the class' methods as OO practice dictates.

u might as well make everything global to the file and use functional programming instead of OOP. self.bla would just become a global variable. Obviously you shouldn't because everyone says so, so I must be missing something. Thoughts?

I originally did that when i first started programming. I asked myself why would someone make a program with essentially one class when they're not importing that class... it just makes more typing, more complex, etc. Now i put almost everything in a class to start with, and if it needs it, i pull it out of a class and make it a global function for example.

There are a few reasons why i have switch my method of programming. For one, I got sick of rewriting my code from globals to classes, as it got more complex, classes made it more simple. This is something that you dont really understand untill it happens to you, (over and over and over again).

I originally started using classes more when it gave me a simple method of sending a variable to and from multiple functions. At that point it was worth it to me just to go ahead and use classes so i didnt have to keep creating local variables in the functions, return them, and reassign them back to the original value. And global keyword i just never would use, it created a lot of unexpected results. It was a lot more simple to just assign a class variable and have one of its methods change it, no arguments sent it, no local variable, no returning for just that, just one simple line in hte method.

And then there is of course OOP. Thats a whole explanation in itself. There are a lot of times, where i wrote code, had to rewrite it to a class, because i decided to import it to other code. I just got sick of converting everything to class, so i just start out a program, no matter how small, as a class, and then if it seems more plausable, to remove it and make a global function out of it or split it into multiple classes, and subclasses if necessary. At this pointi can think somewhat ahead, and say "OK, i need this and this, which there are going to be an unkown amount of objects, which in turn means i need to create a class to create X number of instances, this class would be better suited to be a subclass of that class, etc.." Anything other than a class wouldnt make sense.

I was recently talking to someone that did just this (using classes as structs), with the intent of then importing the whole module with a star import. His argument was that by putting them in classes like this the damage to the name space was greatly diminished. I personally think it's horrid.

Thanks for your responses.I'll need to do myself a favour and break up the singleton classes before growing them further.Interestingly, though a different thing than the point I was trying to make, the official documentation mentions using classes as structs in a positive way, though you should probably use it sparingly.http://docs.python.org/2/tutorial/class ... s-and-ends