I'm curious, is there a standard approach to dealing with long lists in the Python community, and in particular, is there any antipathy toward doing blank lines followed by comments to break up a particularly long list, e.g. of tuples, or in a dict, etc.?For example, I'm developing a GUI application in wxPython, and am defining the keyboard shortcut mappings to . Is this fairly Pythonic?accelerator_table = wx.AcceleratorTable([    # Case accelerators    (CTRL, ord('S'), EventIds.SAVE_CASE),    (CTRL_SHIFT, ord('S'), EventIds.RENAME_CASE),    (CTRL, wx.WXK_DELETE, EventIds.REMOVE_CASE),    (CTRL_SHIFT, wx.WXK_DELETE, EventIds.DELETE_CASE),    # Project accelerators    (CTRL_ALT_SHIFT, ord('S'), EventIds.RENAME_PROJECT),    (ALT, wx.WXK_DELETE, EventIds.REMOVE_PROJECT),    (ALT_SHIFT, wx.WXK_DELETE, EventIds.DELETE_PROJECT),    # Help accelerators    (NORMAL, wx.WXK_F1, EventIds.HELP),    (NORMAL, wx.WXK_F2, EventIds.LAUNCH_MANUAL),    (NORMAL, wx.WXK_F12, EventIds.ABOUT),    ...])The details aren't particularly important, but I'd like to write in a style that will not annoy other programmers along the way, and therefore to decide right now whether this pattern is worth keeping around.Edit: Just to clarify: I'm not intending to put anything beyond that single blank line between sections in the list. That seems like it should minimize any confusion on the part of someone reading through the code.
Python code style - blank lines in long list
coding style;python;whitespace
Looking at the OP's initial approach, it is immediately obvious to me what it's doing. I don't see that there are readability or maintainability problems with this at all, nor do I see that it violates any commonly-accepted Python conventions or idioms. It's clear, and it uses minimal syntactic boilerplate and extraneous operations to achieve its goal. I recommend sticking with this approach.The implementation suggested by Demian's answer seems to create more problems than it solves. Returning a list from a property is usually not a good idea, because it creates an interface that will look identical to an attribute, but will exhibit bizarre behavior if used as such, e.g. t.file.extend(t.project) will not do what most users would expect, and will fail silently, causing potentially confounding bugs.The OP could use instance attributes or class fields instead of properties, but I'm not sure an object-oriented approach has much utility here (i.e. it seems to be using class syntax without employing actual OOP concepts).But the suggestion to separate the tuple-list aggregate into multiple smaller lists, that are then concatenated and passed to wx.AcceleratorTable, seems sensible. The right approach is mostly a matter of preference, though I still prefer the OP's initial approach because it involves less list manipulation, and doesn't have any readability issues that I see. 