"but it's "ugly", by which I mean it is hard to use, error prone, and not easily maintained."
OK, I see the problem. What you call "ugly" is really just objectively bad. Ugliness and beauty are subjective qualities that can't really be debated on a deep level. Like I mentioned in other post, I find the lazy-evaluation idiom that avoids __init__ initialization of the stored value to be pretty, so I code it that way (in C#, in Java, in Python, even though the syntax is slightly different in each one). But I wouldn't say that using the __init__ (or the constructor) to initialize the lazy variable is "hard to use, error prone, not easily maintained". I would say it's ugly (or less pretty), and that it does seem to have some minor functional drawbacks. But I wouldn't make a big deal out of it if a colleague wanted to code it that way. Looking at Fortran, C, C++, C#, Java and Python (the languages I have done large bodies of work in, and, not coincidentally, some of the most popular languages ever, since I like to get paid and that requires going with the flow a little) it's easy to see that a lot of cosmetic things are maintained (i.e. foo.bar(), k += 1, etc) but some important, conceptual things are improved in profound ways. So a colleague that was advocating coding a project in C when Python would work ... yeah, that's a deal breaker, we're going to lock horns over that. I wasn't going to ramble on like this but I think you, Stephen, were the one encouraging me to step into the flames. -- https://mail.python.org/mailman/listinfo/python-list
