variable declaration

Thomas Bartkus tom at dtsam.com
Tue Feb 1 12:50:30 EST 2005


"Steve Holden" <steve at holdenweb.com> wrote in message
news:41FFAE20.7030802 at holdenweb.com...
> Thomas Bartkus wrote:
>
> > "Carl Banks" <invalidemail at aerojockey.com> wrote in message
> > news:1107205410.367521.50490 at f14g2000cwb.googlegroups.com...
> > <snip>
> >
> >>How common is it for a local variable to be bound in
> >>more than one place within a function?
> >
> >
> > How common?  It shouldn't happen at all and that was the point.
>
> This seems a little excessive to me. Sample use case:
>
> for something in lst:
>    if type(something) != type(()):
>      something = tuple(something)

Hhhmmh!
I presume you are going through the list and want to gaurantee that every
item you encounter is a tuple!  So if it ain't - you just re-declare
"something" to be a tuple. What was formerly a single string, integer,
whathaveyou is now a tuple *containing* a single string, integer,
whathaveyou.

Do you do it that way because you can? Or  because you must?
   And
If the former - is it a good idea?
OR did I just miss your codes intent completely?

My first inclination would be to create a new variable (type = tuple) and
accept (or typecast) each "something" into it as required. The notion that
you just morph "something" still seems rather abhorrent. It hadn't occurred
to me that iterating through a list like that means the iterater "something"
might need to constantly morph into a different type according to a lists
possibly eclectic contents.

It might explain why the interpreter is incapable of enforcing a type.  It
would forbid iterating through lists containing a mix of different types.
EXCEPT- I must note, that other languages manage to pull off exactly such a
trick with a variant type. When you need to pull off a feat such as this,
you declare a variant type where the rules are relaxed *for that situation
only* and there is no need to toss the baby out with the bathwater.

Thomas Bartkus





More information about the Python-list mailing list