On Jun 4, 9:51 pm, "bruno.desthuilli@gmail.com"

In practice, I believe most programmers associate those short names
with pretty much any loop

variable, irrespective of data type, based primarily on the simple
fact that it's looping

over a set of values whose meaning is obvious from context. That
declaration is made after

decades of working with other peoples code as well as my own.

Don't believe me? Take a look at some code that uses C++ iterators,
for example, or some C

code that uses pointers as iterators, or some Ada code that loops over
an enumerated type,

etc etc. It won't find you long to realise that 'i' and 'j' are very
common names for those

too.

I've seen 'i' used in "iterations" over lists in Scheme, OCaml and
Haskell, whether done

using tail recursion or list comprehensions or whatever. 'x' is more
common, as with 'x:xs'

patterns used to pick the head 'x' from a list in OCaml or Haskell,
but then 'x' looks

scarily like an ordinate we can't have that ;-)

Anyway, why should 'indexes' always be numeric...

which answer in the validList you are looking for. It may well even be
a numeric index (or

some other kind of key), from what we can see in the example.

"item" says nothing that "i" does not. If nothing else, you could
always say that 'i' is

short for 'item' or 'id' or whatever.

with many different language. You don't always keep them neatly
compartmentalised in your

head. Habits can be very strong, and there is not always any strong
reason to try to break

them. Which is why you will still occasionally see 'm' prefixes in
Python code.

Actually, in *my* Python code you're still more likely to see
'f' (standing for field)

prefixes - a convention I adopted in C++ at a time when I thought 'm'
better suited macros,

and when I'd never yet seen the 'm' for member prefix since most C++
code I'd seen still used

the Hungarian conventions. It's a bad habit that I still haven't fully
broken.

too...

  int factorial (int p)
  {
    int l = 1;
    while (p > 1)  {  l *= p;  p--;  }
    return l;
  }

  def factorial (p) :
    l = 1
    while p > 1 : l *= p; p -= 1
    return l

Updating parameters when you could just as easily update locals is of
course bad style in

either language - and some would say that any updating of parameters
is bad style - but the

point is that C and Python do the same thing.

This example does illustrate another useful fact about the 'l' and 'p'
prefixes - there are

times when the prefix is all you need to specify the whole name, since
there really is

nothing else that can be usefully be said.

times when a convention that distinguishes the two kinds of names
without needing to think up

distinct names is convenient. I wasn't suggesting that this convention
should be universally

adopted in Python or that it was relevant to Thorstens example even -
but it is common in

many languages (not just C++), and it does sometimes help resolve the

how-can-I-give-these-meaningfully-different-names issue.

1.4 and I am perfectly aware of properties in Python, as I am in other
languages. I am aware,

for example, that they are relatively new additions to the language,
that they are not used

in a lot of code, and that you still need named getter and setter
functions to redirect the

property access to even if these names are only referred to in the
property definition.

All of which is mostly besides the point. More and more programmers
are multilingual these

days, and scripting languages such as Python are more likely second
languages than first.

Having a hard rule that conventions from one language should never
leak into another, and

that Python code should be somehow 'pure', is pointless, particularly
when those conventions

are common in many languages. Thorsten was having difficulty in
finding distinct names, and I

described a common naming convention that is often useful for this. I
don't think I was wrong