Google Groups appears to have thrown away my original reply, so sorry
if this appears twice...
On Jun 4, 9:51 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> 'i' and 'j' are the canonical names for for loops indices in languages
> that don't support proper iteration over a sequence. Using them for
> the iteration variable of a Python for loop (which is really a
> 'foreach' loop) would be at best confusing.
Without wanting to start a religious war, I disagree.
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...
> > for i in validanswers:
> > if myAnswers.current in myAnswers.validList [i]:
> > MyOptions['style'] = i
>
> And this is *exactly* what one should not do in Python. If you want a
> generic name here, use 'item' instead.
In this code, 'i' is appears to be just an answer identifier. It is
used to identify for
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.
> since the use of 'self' is mandatoy.
That is true, making 'm' prefixes pointless in Python, but that's what
comes from working
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.
> 1/ parameters names *are* local
As they are in C and C++. Not just in terms of scoping, but in terms
of being local variables
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.
> 2/ pythonic methods and functions tends to be short, so you usually
> know which names are params.
Well written functions and methods in any language tend to be short,
but even so, there are
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.
> Python has a pretty good support for computed attributes (look for
> 'property'), so you don't need explicit getters/setters.
I may not use Python as my first and only language, but I have been
using it since version
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
to do that.
--
http://mail.python.org/mailman/listinfo/python-list
