20

I'm writing a set of python functions that perform some sort of conformance checking on a source code project. I'd like to specify quite verbose names for these functions, e.g.: check_5_theVersionOfAllVPropsMatchesTheVersionOfTheAutolinkHeader()

Could such excessively long names be a problem for python? Is there a maximum length for attribute names?

Alexander Tobias Bockstaller
  • 4,657
  • 4
  • 36
  • 58
  • 6
    Please don't do this. Long names aren't always bad, but they are a code smell. In this case I would shorten the name and put a more detailed description in a doc string. Also, I would either log the results verbosely or throw a clearly written exception explaining the failed check. – Steven Rumbalski Jun 04 '13 at 15:20

3 Answers3

43

2.3. Identifiers and keywords from The Python Language Reference:

Identifiers are unlimited in length.

But you'll be violating PEP-8 most likely, which is not really cool:

Limit all lines to a maximum of 79 characters.

Also you'll be violating PEP-20 (the Zen of Python):

Readability counts.

kirelagin
  • 13,248
  • 2
  • 42
  • 57
  • well thanks, but for the readability part, I can't let that count: This is exactly what I'm trying to achieve here. The name of the function tells you what it does. If I abbreviate it, it becomes less readable. (will accept your answer in 8 min) – Alexander Tobias Bockstaller Jun 04 '13 at 14:53
  • 5
    @AlexanderTobiasHeinrich Your code will be _absolutely unreadable_. Use [docstrings](http://www.python.org/dev/peps/pep-0257/). – kirelagin Jun 04 '13 at 14:54
  • 4
    "Fully descriptive" and "readable" are two separate things. Long, long camel-cased strings are the former, not the latter. – chepner Jun 04 '13 at 14:58
  • I do use docstrings and I aggree, in general, that long names should be avoided, because they're not easy to read and not easy to remember. I agree with @chepner that there's a difference between descriptiveness and readability - here I wanted a descriptive name. Reason: The function will only be called at a single location in source code and it will be called together with many other similar functions. By giving long, descriptive names to these functions I release the reader from having to jump to the function definition only to get a glimpse of what they're doing. docstrings don't help here – Alexander Tobias Bockstaller Jun 04 '13 at 15:10
  • If they are only being called once and in one place, just provide comments at that point, rather than trying to embed comments in the names of the attributes. – chepner Jun 04 '13 at 15:13
  • 3
    @chepner Indeed. I hate it when I encounter things like `AggregateAccountabilityViewManager aggregateAccountabilityViewManagerForAlternateSetupScrollingLoaderViews = new AggregateAccountabilityViewManager();` (as a random Java example) in code. Just because code-completion makes stuff like that a lot easier to write doesn't mean you should. – JAB Jun 04 '13 at 15:14
  • @JAB Well, your example mostly shows a huge problem of Java. I mean, long idetifiers are bad, but Java makes even not-very-long identifiers horrible. – kirelagin Jun 04 '13 at 15:16
  • @chepner: why spend an extra line, if the name can carry that information? only to get the warm feeling, I (blindly) adhered the coding guideline? – Alexander Tobias Bockstaller Jun 04 '13 at 15:19
  • The name carries the information poorly. Why are you so set against using comments for their intended purpose? – chepner Jun 04 '13 at 15:21
  • 5
    @AlexanderTobiasHeinrich Because functionsThatTellYouExactlyWhatTheyDoInCamelCase(areReallyAnnoyingBecauseItAllRunsTogether). – JAB Jun 04 '13 at 15:21
  • 2
    @chepner: I love comments, if they document a public interface. If they don't I'd rather try to write code that does not need comments. – Alexander Tobias Bockstaller Jun 04 '13 at 15:25
  • @AlexanderTobiasHeinrich I think his point is (and if it isn't I'm making it myself): A single identifier is inferior to comments/docstrings for long descriptions, whole sentences etc. because they impose stupid restrictions on formatting - you can't use spaces, or punctuation, etc. and if you adhere to a particular casing style (which you probably should for consistency) you can't even capitalize half the words properly. –  Jun 04 '13 at 15:27
  • @AlexanderTobiasHeinrich Nesting of templates in C++/generics in Java isn't the issue here, but using long identifier names does indeed make them less parsable. `LongIdentifierName, WhyWouldYouEvenDothis>>>`. Even if you break it across lines and use indentation, it's still a lot messier than using decently descriptive yet succinct identifiers and putting a proper description elsewhere (and delnan makes a good point about the (lack of) inline formatting as well). – JAB Jun 04 '13 at 15:29
  • Python also gives you the flexibility, especially for something like this, to monkey patch a test harness in to your program. If you combine the ability to overload (and return any arbitrary type, like, say, `ComparisonResult`) operators with something that attaches metadata to objects and a function that generically generates logging for verifications, you can end up with something like `verify(all_v_props.version == auto_link_header.version)` that will log a nice verbose message for both success or failure. – Silas Ray Jun 04 '13 at 15:29
  • @AlexanderTobiasHeinrich Perhaps you should ask the people who would be reading and maintaining your code what they would prefer. – chepner Jun 04 '13 at 15:37
  • for this specific project: that would be me. (Anyway: I really appreciate all your comments, even if I may appear a bit stubborn) – Alexander Tobias Bockstaller Jun 04 '13 at 15:40
7

They could be a problem for the programmer. Keep the function names reasonably short, and use docstrings to document them.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
3

Since attribute names just get hashed and turned in to keys on inst.__dict__ for 99% of classes you'll ever encounter, there's no real limit on length. As long as it is hashable, it'll work as an attribute name. For the other 1% of classes that fiddle with __setattr__\ __getattr__\ __getattribute__ in ways that break the guarantee that anything hashable is a valid attribute name though, the previous does not apply.

Of course, as others have pointed out, you will have code style and quality concerns with longer named attributes. If you are finding yourself needing such long names, it's likely indicative of a design flaw in your program, and you should probably look at giving your data more hierarchical structure and better abstracting and dividing responsibility in your functions and methods.

Silas Ray
  • 25,682
  • 5
  • 48
  • 63
  • You really think that interpreter hashes method names on each invocation? – kirelagin Jun 04 '13 at 14:52
  • Would be more productive if worded `the interpreter doesnt hash method names on each invocation, see ...` – hexparrot Jun 04 '13 at 14:54
  • Unless you are using a JIT or other sort of optimizing or look-ahead interpreter (which to my knowledge CPython is not), yes. – Silas Ray Jun 04 '13 at 14:54
  • Not dumb at all. My understanding is that the CPython interpreter was specifically designed to be as simple to extend as possible, which meant tradeoffs for performance optimization. Hence why PyPy and the like exist. – Silas Ray Jun 04 '13 at 14:58
  • CPython is mostly a simple interpreter, yes, but that does not mean there are no performance optimizations (if there weren't, it would be much slower than it is anyway). Two of those optimizations interact to make sure virtually no attribute lookup actually runs a hash function. (1) The strings for attribute lookup are constant, and hence [interned](http://stackoverflow.com/q/1136826/395760). (2) Strings [remember their hash value](http://hg.python.org/cpython/file/2.7/Objects/stringobject.c#l1272) after the first time they're hashed. –  Jun 04 '13 at 15:08
  • @delnan Interesting, thanks. I removed the offending sentence from my answer. – Silas Ray Jun 04 '13 at 15:13
  • @delnan Unless you're using run-time reflection, in which case the interpreter won't know what strings to intern until runtime. ...Or so I thought, but it seems attribute-access strings actually are interned either way. – JAB Jun 04 '13 at 15:17
  • @JAB It's possible that `getattr` and the like call `intern` on the argument names. I don't know if that's what happens but that would be my guess based on your edit. Good point anyway, as this is an implementation detail and likely to change. –  Jun 04 '13 at 15:23
  • 1
    @delnan It seems they are interned... when using a char* string. http://hg.python.org/cpython/file/tip/Objects/object.c#l816 On the other hand, `setattr` does utilize interning for Python strings. http://hg.python.org/cpython/file/tip/Objects/object.c#l953 – JAB Jun 04 '13 at 15:47