Re: variable declaration

From: Thomas Bartkus (tom_at_dtsam.com)
Date: 02/01/05 

Date: Tue, 1 Feb 2005 11:50:30 -0600

"Steve Holden" <steve@holdenweb.com> wrote in message
news:41FFAE20.7030802@holdenweb.com...
> Thomas Bartkus wrote:
>
> > "Carl Banks" <invalidemail@aerojockey.com> wrote in message
> > news:1107205410.367521.50490@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

Relevant Pages

  • Re: Accessing next/prev element while for looping
    ... > The python way is much more succinct. ... > previous or the next element in the array before continuing iterating. ... > incredibly silly given that python lists under the hood are linked ... the iterator used by the for loop, not the list it is iterating over. ...
    (comp.lang.python)
  • Re: Vector or List
    ... > I'm fairly new to the STL and i was wondering when was the best situations ... to elements other than iterating over them ... For lists, ... I'm Schobi at suespammers dot org ...
    (microsoft.public.vc.stl)
  • Re: Iterator Class?
    ... > there is a significant performace penalty when using getfor long Lists. ... > It appears as though getinsists on iterating from the beginning of the ... > list to arrive at the desired element. ... the profiler has never complained about iterating over a 10 ...
    (comp.lang.java.help)
  • Re: Iterator Class?
    ... > there is a significant performace penalty when using getfor long Lists. ... > It appears as though getinsists on iterating from the beginning of the ... > list to arrive at the desired element. ... the profiler has never complained about iterating over a 10 ...
    (comp.lang.java.programmer)