Hungarian Notation

[inhahe]

Does anybody know of a list for canonical prefixes to use for hungarian
notation in Python? Not that I plan to name all my variables with hungarian
notation, but just for when it's appropriate.

 

[Kam-Hung Soh]

Does anybody know of a list for canonical prefixes to use for hungarian
notation in Python? Not that I plan to name all my variables with hungarian
notation, but just for when it's appropriate.

I used simple Hungarian notation when I started programming in Python
(e.g. "s" for strings, "l" for lists, "d" for dictionaries). As my
programming style became more "Pythonic" and I chose better variable
names, I stopped using Hungarian notation.

YMMV.

 

[Paul McGuire]

Does anybody know of a list for canonical prefixes to use for hungarian
notation in Python?  Not that I plan to name all my variables with hungarian notation, but just for when it's appropriate.

You are likely to get some links to PEP 8 for coding style and naming
conventions, but it turns out PEP 8 doesn't really say yay or nay on
the Hungarian notation topic.

My own knee-jerk reaction was "Hungarian Notation Bad!" and googling
about for "python hungarian notation" led me through some like-minded
sites. But I also found this entry on Joel Spolky's site (http://
www.joelonsoftware.com/printerFriendly/articles/Wrong.html), that
warns against tarring all Hungarian-type notations with the same
brush.

So with that article in mind, I'd have to ask, what do you mean by
"appropriate"?

-- Paul

 

[inhahe]

Well, I just need it once in a while. Actually now is the only time I
remember. The last time what I needed was a file name extension. I want a
string called headers, but I want to derive a dict from it, also called
headers. So I figured the string would be called strHeaders, and the dict,
dctHeaders probably, but when a precedent for something like that exists, I
like to use it.

 

[Carl Banks]

Well, I just need it once in a while. Actually now is the only time I
remember. The last time what I needed was a file name extension. I want a
string called headers, but I want to derive a dict from it, also called
headers. So I figured the string would be called strHeaders, and the dict,
dctHeaders probably, but when a precedent for something like that exists, I
like to use it.

I doubt there's anything canonical since Python community, PEP 8, and
Python's dynamic typing all discourage its use. I would venture to
say that the community would frown upon names such as "strHeaders"
since they don't agree with the naming conventions in PEP 8. Instead,
use "str_headers" and "dict_headers". Better yet, use "headers_str"
and "headers_dict". Put the less important information last.


Carl Banks

 

[Carl Banks]

You are likely to get some links to PEP 8 for coding style and naming
conventions, but it turns out PEP 8 doesn't really say yay or nay on
the Hungarian notation topic.

My own knee-jerk reaction was "Hungarian Notation Bad!" and googling
about for "python hungarian notation" led me through some like-minded
sites. But I also found this entry on Joel Spolky's site (http://www.joelonsoftware.com/printerFriendly/articles/Wrong.html), that
warns against tarring all Hungarian-type notations with the same
brush.

The name of a variable is a valuable resource. There are all kinds of
things you can encode in it, but you have to choose only one or two.
The most important information is what it is (e.g., box), or what it's
archetype is (i, for a counter variable). Pretty much all names
should contain one of these two. Second most important are
discriminators such as a description (red_box), usage (shoebox), or
circumstance (next_box).

But sometimes other things are important enough to warrant addition to
the name. Type usually isn't one of them, but there are times when
it's helpful to know. But then, I'm not sure I would call it
"Hungarian notation" to add ad hoc type information to a few of names
here and there.

One convention I have for myself is to use x<elementname> for elements
when I'm using ElementTree, but the reason is pragmatic: I'm creating
objects that have the same name as the elements.

So with that article in mind, I'd have to ask, what do you mean by
"appropriate"?

It seems like OP wanted to disambiguate two objects based on type,
which seems reasonable to me. Sometimes you want to have side-by-side
represenations of something where type is the main difference, in
which case there's no reason type shouldn't be added to the name.


Carl Banks

 

[Paddy]

Well, I just need it once in a while. Actually now is the only time I
remember. The last time what I needed was a file name extension. I want a
string called headers, but I want to derive a dict from it, also called
headers. So I figured the string would be called strHeaders, and the dict,
dctHeaders probably, but when a precedent for something like that exists, I
like to use it.

"Kam-Hung Soh" <[email protected]> wrote in message

I have a my own sometime used convention od using dict names that
mirror
what is being mapped to what, so a dict mapping headers to body might
be called head2body, in general a mapping from x to y I might call
x2y.

- Paddy.

 

[John Salerno]

My own knee-jerk reaction was "Hungarian Notation Bad!" and googling
about for "python hungarian notation" led me through some like-minded
sites. But I also found this entry on Joel Spolky's site (http://
www.joelonsoftware.com/printerFriendly/articles/Wrong.html), that
warns against tarring all Hungarian-type notations with the same
brush.

Wow, that was fascinating. I had no idea Hungarian notation originally
didn't mean to prefix the object type!

 

[George Sakkis]

I have a my own sometime used convention od using dict names that
mirror
what is being mapped to what, so a dict mapping headers to body might
be called head2body, in general a mapping from x to y I might call
x2y.

I use the same convention, though it's less than ideal if x or y
consist of more than one word (typically joined with underscore), e.g.
"value2row_id" or if the values are also dicts
("category2value2instances").

George

 

[Dan Bishop]

Does anybody know of a list for canonical prefixes to use for hungarian
notation in Python?  Not that I plan to name all my variables with hungarian
notation, but just for when it's appropriate.

pnWe vUse adjHungarian nNotation prepAt nWork, conjAnd pnI vauxDont
vLike pnIt advVery advMuch. conjSo pnI vAvoid pnIt prepIn nPython.

 

[Lou Pecora]

pnWe vUse adjHungarian nNotation prepAt nWork, conjAnd pnI vauxDont
vLike pnIt advVery advMuch. conjSo pnI vAvoid pnIt prepIn nPython.

HAHAHAHAHAHA! Beautifully done. Next time I need to diagram a sentence
I will come to you. You're the man.

 

[Bruno Desthuilliers]

Dan Bishop a écrit :

pnWe vUse adjHungarian nNotation prepAt nWork, conjAnd pnI vauxDont
vLike pnIt advVery advMuch. conjSo pnI vAvoid pnIt prepIn nPython.

Mouarf ! Keyboard ! (and +1 QOTW BTW)

 

[Lie]

Does anybody know of a list for canonical prefixes to use for hungarian
notation in Python?  Not that I plan to name all my variables with hungarian
notation, but just for when it's appropriate.

If it was me, I'd use an empty-defined class:

class Fake(object):
pass

data = 'headinfo=trash;headtrash=info'
Header = Fake()
Header.Str = data
Header.Dict = parse(data)

it saves name if it's important (alternatively, you may also use a
dict or a tuple/list to store the string/dict pair).
But using Fake class just like that is difficult to work with if I
need to "write" to the data (not read only) and synchronizes the data,
in that case, it's easy to extend the Fake Class:

class Fake(object):
def __init__(self, data):
self.data = parse(data)

def toStr(self):
return str(self.data)
def fromStr(self, s):
self.data = parse(s)
Str = property(toStr, fromStr)

def toDict(self):
return self.data
def fromDict(self, s):
self.data = s
Dict = property(toDict, fromDict)

you might go as far as overriding __str__ and __repr__ as appropriate.