Timeline for Readability in creation of a long output string
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 19, 2014 at 7:58 | comment | added | RolfBly | @DarinDouglass I accept your point and I very much appreciate your effort as well. But I often find OOP code unnecessarily abstract. Some time in the future, I'd be keen to debate that, but not here. Here, instead, maybe. | |
| May 18, 2014 at 0:49 | comment | added | BeetDemGuise | @RolfBly I agree with one of your points: hard-coding the list is definitely not the prettiest, however it was the solution that quickly came to mind when writing this answer. As for 'hiding mechanisms', I don't think that is what's happening here. What I'm doing is taking related info (data, statements, etc.) and bringing them into a single structure. This is the whole point behind OOP: provide a single point of access for evaluating and storing related info. Now, if your program is decently simple, I would recommend janos's answer. Otherwise, I would recommend my answer as it scales better. | |
| May 17, 2014 at 20:21 | comment | added | RolfBly |
@DarinDouglass I don't think it's good to hide mechanisms that help to understand the code. Also, hard-coding lists, specifically the )])) in str(TH)])), imho is not very pretty.
|
|
| May 15, 2014 at 19:24 | history | edited | BeetDemGuise | CC BY-SA 3.0 |
added 3 characters in body
|
| May 15, 2014 at 19:20 | comment | added | Jonas Schäfer |
hasattr(true_val, "__iter__") is duck-typier than isinstance(true_val, list), and will work for exactly everything which works with the *-notation.
|
|
| May 15, 2014 at 19:17 | history | edited | BeetDemGuise | CC BY-SA 3.0 |
added 38 characters in body
|
| May 15, 2014 at 18:52 | history | answered | BeetDemGuise | CC BY-SA 3.0 |