[Tutor] going big (in terms of code base)

[Rance Hall]

On Mon, Nov 14, 2011 at 5:01 PM, Wayne Werner <waynejwerner at gmail.com> wrote:
> On Mon, Nov 14, 2011 at 2:49 PM, Rance Hall <ranceh at gmail.com> wrote:

<snip>

>>
>> GUIs add a lot of code bloat and lots of chances for bugs that have
>> nothing to do with the logic of your program.
>
> I'm not sure that I would entirely agree with this statement. I think that
> GUIs definitely increase the likelihood of code bloat, they don't
> necessarily create it. Bloat is unnecessary cruft that could (and should) be
> removed from your program. If you want a graphical interface it's very
> difficult to do that without a nice framework ;)
>

Yea, you are right.  I didn't say that well.  I think we were thinking
the same thing, but you said it better than I did.

>>
>> I'm looking for a way to manage large projects (large in terms of code
>> size)
>>
>> There are lots of new concepts to grasp here: From basic GUI stuff
>> like event handlers to understanding class layout and what things go
>> in this class and what things go in that one.
>>
>> Before proceeding I need to understand how best to break up a large
>> file into several smaller files and not break anything.
>>
>> I assume that "import" will be part of the solution but it only
>> "imports" complete python modules.  Much different than a php include
>> for short code snippets.
>
> Modules are definitely what you're looking for - but you can use modules in
> a strictly procedural sense. Heck, if you wanted to make some pretty
> un-Pythonic code you could throw imports all over your program in a very
> strictly procedural fashion. But don't do that.
>
>>
>> I'm guessing that means I have to learn how to create my own modules
>> as well.  And then how to manage them.
>>
>
> Yes indeed. If you're planning to do a lot of things with modules, and
> trying to deploy them to other people, I'd highly recommend learning
> virtualenv - it will save you a lot of headaches in the long run.
>

Thanks for this, I looked it up, and it at least looks like something
I could make use of.

<snip>

>>
>> This makes sense in terms of being able to go back and fix something
>> later and know where it is to find it.
>>
>> What I would like to do is create a basic app framework that I can
>> use/reuse on future projects.
>>
>
> Depending on what you need, this may be premature optimization because there
> already exists basic frameworks (like Tkinter).
> If you find that there are a lot of duplication/customization things that
> you're doing, then it makes sense to automate that and create some type of
> framework... but in the several Tkinter programs that I've created I've
> never said "Huh. This is just clunky, I wish I had X". Well, except for the
> H/VBoxes from GTK - but I created my own wrappers around the Frame class and
> got exactly what I wanted.

I think perhaps we are talking past each other here.  I'm thinking a
sort of skeleton directory that already has the basic code to create a
basic main window, with a menubar and status message box at the
bottom.  That includes basic functions of db connectivity.  Sort of
like a template in a larger IDE.

>>
>> What else to I need to know about to make my idea a reality?  In what
>> order would you suggest I learn these things so I can interconnect
>> them properly.  For example. OOP before tkinter?
>
> I'm not sure that OOP or Tkinter would make learning one or the other any
> easier, but I suspect that if there is a best order that OOP might be on the
> better side. But then again, it might not be necessary. Even though I've
> written classes for my programs it's hardly required, but I do like to think
> that it makes some things easier.

Relearning the way I think in terms of being a coder certainly does
not qualify under "easier," but if I'm to write code that's
maintainable for the long term then I need to switch to OOP

> Actually, that's pretty much my criteria for using classes or anything else.
> "Will it make this problem easier?" is the question that I ask myself. In
> the case of some program hitting a database, maybe I have a table of
> "people" and it stores the people that I know. So maybe I'll make a People
> class that has the following attributes:
> firstname
> lastname
> phone
> email
> address

> And since in my mind, real people already have those things, it's easier for
> me to think of myself as:
> wayne = People()
> wayne.firstname = "Wayne"
> wayne.lastname = "Werner"
> wayne.phone = "555-555-5555"
> wayne.email = "waynejwerner (at) gmail <dot> com"
> wayne.address = "The Castle Arrrrgggh!"
> than to think of myself as:
> ("Wayne", "Werner", "555-555-5555", "waynejwerner (at) gmail <dot> com",
> "The Castle Arrrrrggggh!")


> Plus if I'm passing myself to a function:
> def reverse_lastname(person):
>     person.lastname = person.lastname[::-1]
> it's a lot easier to tell what person.lastname means, than person[1]. If I
> was writing the procedural code, I'd honestly probably write a function
> get_lastname(person) or something similar.

> If you think that it will be easier for you to maintain your programs using
> the OOP-paradigm, go ahead and learn it. But you are also perfectly capable
> of creating a procedural program using modules and Tkinter without ever
> writing a class definition. Of course, someone else who ends out maintaining
> your program might not feel that way ;)

This is my chief interest in OOP in a nutshell.  If I take the time to
learn OOP then it may take longer and be "harder" (at least for
awhile) in the beginning, but changes and long term maintenance should
be much, much easier.

If I reconsider your Person example and entertain a request to
restructure the "address" to "city", "state", "zip" for US addresses
is something that previously has been very difficult.  where in OOP
seems to make that change very easily.

This is where I'm hoping to gain from OOP.

Rance