Troubles with global variables

[Jeff Shannon]

Jeremy Whetzel wrote:

> I've been playing around with the code, and I have a couple of
> questions.
>
> First, with the dictionary having tuples, the items in the
> tuples cannot be reassigned. (which is the error I receive when I try to
> change an option)  If I change the tuples to lists, I then receive an
> error saying "TypeError: not enough arguments for format string".  (I
> think I got this one figured out by putting (item[0],item[1],item[2])
> instead of just 'item' on the string formatting line.  What would _you_
> do to change this?  (ie, did I hit close to the mark?)

I *knew* I should've tested that code before I posted it.  :)  Yes, you can solve
it that way, or just use tuple(item) as Tim Hochberg suggested.

>
> Also, I've noticed that when the menu prints, it tends to print the menu
> listing in alphabetical order of the keys in menudict.  Is there a way
> to change this behavior?
>
> One last thing, and this was something I didn't address earlier, but
> having the 'enc' variable is something I need later in the program.  I
> know I could use menudict['E'][2], but that feels cumbersome to type out
> each place I need it.  How would you approach this?
>
> I really appreciate your help, and your suggestions have been great.

Hm.  To be honest, I'd approach this whole thing from an object-oriented
viewpoint, instead of the procedural one you're using, so it would end up looking
quite a bit different.  And much of the design would end up depending on just
*how* everything else is being used.  Making a few wild guesses based on the
names you're using (hopefully you can follow the logic I'm using and apply it to
your *real* problem <wink>) ... Say you're trying to encode a data file into some
other format, and you want to be able to select the type of format (the encoder)
and the sampling bitrate to use.  I would have an object representing a generic
encoder, which would have an member variable for the bitrate, and methods to take
in a data stream and output a new (encoded) data stream/file.  I would then make
subclasses of this generic encoder, one for each specific type of encoder I
wanted to use.  These subclasses would override the output function to create the
proper type of file.  Now, your encoding type, which you're currently storing in
your 'enc' variable, is defined by the class of your encoder, but you probably
won't *need* to worry about it elsewhere in the program, because the encoder will
know, on its own, how to behave properly for its type of encoding.  Then,
selecting a new encoder from your menu would create a new encoder object, freeing
the old one.  The menu function would have to query the current encoder object to
find out what type it is, and what its bitrate is--there'd probably be a method
or three in the encoder class to provide this information.  All in all, the
architecture would be *quite* different from what you're working with, so it's
hard to provide specific code without having a better idea if I'm even on the
right track.  :)  And of course, not everyone is fond of object-oriented
programming, so this approach may not even be suitable for you--it does require a
big change in perspective.  If you *are* interested in it, there's lots of
guidelines and tutorials about OOP available on the web.

Hopefully this hasn't totally confused you now.  :)  And of course, Python works
quite well for either object-oriented or procedural styles.

Jeff Shannon
Technician/Programmer
Credit International