*Naming Conventions*

[Bruno Desthuilliers]

Ninereeds a écrit :
> Google Groups appears to have thrown away my original reply, so sorry
> if this appears twice...
> 
> On Jun 4, 9:51 pm, "bruno.desthuilli... at gmail.com"
> <bruno.desthuilli... at gmail.com> 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.

The fact that a bad practice is a common practice is by no mean an 
excuse for promoting this bad practice.

FWIW, Python as a very strong philosophy when it comes to readability, 
and I think it's the first time I see such a naming horror in Python.

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

Because that's part of the commonly admitted definition in the context ?

In a dict, it's named a 'key', not an index. And the idiomatic shortcut 
is 'k', not 'i'.


(snip)

>> 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.

Ah, the good old 'I can write basic in any language' syndrom...

> 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.

I do not agree here, but that's another point. The problem is that you 
are advertising a totally non-pythonic convention on c.l.py. Your post 
will be archived for years, and some newbie may find it and follow your 
bad advises. Please keep such advises for where they are appropriate.

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

Never seen such a thing in 7 years of Python programming, and believe me 
I've read a *lot* of Python code.

>> 1/ parameters names *are* local
> 
> As they are in C and C++. 

The relation between the name and the named object are somewhat 
different in Python.

>> 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,

For a somewhat different definition of "short". A "short" C functions is 
commonly tens of lines long - which, by Python standards, starts to 
become a "too long" function.

>> 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 

Then you beat me !-)
(started with 1.5.2)

> 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.

class SomeClass(object):
   @apply
   def some_property():
     def fget(self):
       return self._somevalue
     def fset(self, newvalue):
       self._somevalue = newvalue
     return property(**locals())

Yes, true, the getter and the setter are named. But here, you don't even 
have to worry a millisecond about how to name them.

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

So am I.

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

'second' by usage frequency or by learning order ?

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

"never" ? Python stole almost anything - naming convention included - 
from other languages. It's not a matter of "purity",  it's a matter of 
filtering what makes sens and what doesn't.

> 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.

See my comments above. If these conventions are totally alien to Python 
(and have already been abandonned/rejected by people with similar 
background as yours - strange enough, a lot of people here are C, C++ or 
Java coders too), then as far as I'm concerned, yes, you are wrong to 
advertise them here. Call me a purist if you want... (and please don't 
take my remarks as a personal offense - it's just that I happen to be 
have *very* strong opinions on some points).