naming convention for scalars, lists, dictionaries ...

[beliavsky]

Since Python does not have declarations, I wonder if people think it is
good to name function arguments according to the type of data structure
expected, with names like "xlist" or "xdict".

 

[Skip Montanaro]

beliavsky> Since Python does not have declarations, I wonder if people
beliavsky> think it is good to name function arguments according to the
beliavsky> type of data structure expected, with names like "xlist" or
beliavsky> "xdict".

In general, no. I think variable names should reflect what they are naming,
not their types.

Skip

 

[Steven Bethard]

Since Python does not have declarations, I wonder if people think it is
good to name function arguments according to the type of data structure
expected, with names like "xlist" or "xdict".

In general, I find that naming collections for their contents is much
more useful than some abbreviated type prefix. However, while I don't
name objects by their type, I do tend to name iterables with plurals
(e.g. "words", "feature_indices", "events", etc.) and I typically suffix
mapping types with "map" (e.g. "word_index_map", "event_relation_map",
"prime_factor_map", etc.)

STeVe

 

[Jack Diederich]

In general, I find that naming collections for their contents is much
more useful than some abbreviated type prefix. However, while I don't
name objects by their type, I do tend to name iterables with plurals
(e.g. "words", "feature_indices", "events", etc.) and I typically suffix
mapping types with "map" (e.g. "word_index_map", "event_relation_map",
"prime_factor_map", etc.)

Ditto for me, plural implies list and singular implies instance,
for (contact) in contacts:
# do something with contact

But I tend to name dictionaries as "key_to_value" as in
"email_to_contact" or "ip_to_hostname."

for (email) in emails:
contact = email_to_contact
# do something with contact

It may seem verbose but I can type much faster than I can think and
it makes reading even forgotten code a breeze.

-Jack

 

[Jack Diederich]

May I ask why you place the parenthesis in the for statement?

I like the tuple-ness feel of it and frequently unpack multiple
values in for loops. I also like the visual feel, it makes it
easy to see what is being unpacked and what is the source.

"for (one, two, three) in somelist:"
versus
"for one, two, three in sometlist:"

Even with a colorizing editor (emacs) I find the first version
easier to read. YMMV.

-Jack

 

[Just]

I like the tuple-ness feel of it and frequently unpack multiple
values in for loops. I also like the visual feel, it makes it
easy to see what is being unpacked and what is the source.

"for (one, two, three) in somelist:"
versus
"for one, two, three in sometlist:"

Even with a colorizing editor (emacs) I find the first version
easier to read. YMMV.

But you're using it for _single_ values. That's like writing

(val) = someFunction(...)

Just

 

[Benji York]

Ditto for me, plural implies list and singular implies instance,
for (contact) in contacts:
# do something with contact

May I ask why you place the parenthesis in the for statement?

 

[Jack Diederich]

But you're using it for _single_ values. That's like writing

(val) = someFunction(...)

Your Milage May^H^H^HDoes Vary *wink*
A quick grep of my source shows zero unparenthesized for loops,
266 with multiple unpacks and 492 iterating over single values.
Actually a bit closer to even, 96 are 'for (i) in range(len(l)):'
that were written before enumerate() came about.

I just always use parenthesis in for loops and when creating/upacking
tuples. I find it easier to read, except in the '(var) = func()' case.
Other people never use them. *shrug* I find this impossible to get
worked up about. What other people do in the privacy of their own
codebase doesn't bother me one bit.

My $0.01 bits,

-Jack

 

[Paul Boddie]

Since Python does not have declarations, I wonder if people think it is
good to name function arguments according to the type of data structure
expected, with names like "xlist" or "xdict".

Your suggestion coincides partly with a mechanism I developed recently
for my libxml2dom package. The normal libxml2dom package puts a
DOM-style wrapper around the existing Python wrapper objects -
something that Python's dynamic features accomplish easily - but this
incurs a major performance cost. Given that a low-level API
(libxml2mod) exists and provides a means to exchange fairly simple
and/or opaque objects with the library, I wondered if I couldn't just
write a code transformer which takes DOM-like code and emits code to
use the low-level API. For example:

element.childNodes -> libxml2mod.children(element)

The challenge, as you've noted with your mention of declarations, is
to find out whether a particular name refers to an object of a
suitable type for the kind of transformations I have in mind.
(Alternatively, one could just guess that "childNodes" is a DOM-style
attribute and do the transformation, possibly leading to mistaken
transformations taking place.) Whilst type inference might offer a
solution, it is itself a much bigger project than this, so my quick
solution was to permit the annotation of names using prefixes to
indicate which names refer to DOM-style objects. For example:

# Special magic defined earlier says that x2_ is the chosen prefix.
x2_element.childNodes -> libxml2mod.children(x2_element)

The result of this is libxml2macro [1], an experimental interface to
libxml2 which manages to retain much of the space/time performance of
that library, albeit without addressing the divisive issues of
transparent memory management. It also offers an insight into the
"optional static typing" parallel universe for Python...

Paul

[1] http://www.boddie.org.uk/python/libxml2dom.html