I know that there's a function called id so I wouldn't create a function or a variable called id, but what about an attribute on an object?
+3
A:
I do this frequently for classes that abstract database tables where there is often a field called id because there is no reasonable chance of a name conflict. Be advised that some synatax highlighters will mark it as a builtin function.
aaronasterling
2010-08-16 22:24:40
+1 just because i like you.
Odomontois
2010-08-16 23:08:35
@Odomontois. Thanks for calling my attention to this post. I cleaned up my grammer
aaronasterling
2010-08-16 23:26:58
though not my spelling apparently
aaronasterling
2010-08-16 23:32:43
@aaronasterling I would like someone to clean my grammar too. My english is so dirty.
Odomontois
2010-08-16 23:35:38
+3
A:
That's ok, and is pretty common. For example, objects mapped to a database record will often have an "id" attribute mapped to the database "id" column value.
Attributes are always "namespaced" so you have to refer to them via self.id or obj.id so there's no conflict with the built-in function.
Matt Good
2010-08-16 22:25:14
Object's actual IDs are not normally exposed as properties. Try "dir(SomeCustomInstanceOfSomething)" and you will NOT see "id" property there unless it's specifically declared as part of your custom class / object. "id(SomeCustomInstanceOfSomething)" would not be affected by you doing things like "myObject.id = 1234"
ddotsenko
2010-08-16 22:31:45
+1
A:
As others have said, it's perfectly fine to have an id attribute, although many consider a bad practice for database design. But that's another question.
If you care about conventions in general, you should check out pylint. This tool analyses your code for errors and also convention problems.
bukzor
2010-08-16 23:31:23