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.

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.

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).

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.