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

[Wayne Werner]

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

> <snip>So far Ive been a very procedural based coder.  Ive not cared much
> for Object Oriented stuff because I didn't learn to think/program that
> way.  (think Fortran/Pascal, etc)
>

There's always room for growth! I think that if you can understand
programming in general, starting to learn OOP isn't that much of a stretch
- but it is still a stretch. And since you've been using Python, I think
that gives you a leg up because everything you've been using are objects,
even if they allow you to ignore their object-ness most of the time.


> 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 ;)


>
> 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.


> The hard part I'm struggling with at this point is understanding what
> python calls the things I need to understand.
>

That's something we're fairly good at, and probably more than happy to
point you in the direction of. If you can say "I need a thingy that does
this other thing", there's probably someone here who knows what you need.


>
> 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.

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.

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 ;)

Good luck!
-Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20111114/1cf0c392/attachment-0001.html>