On Wed, Jan 2, 2013 at 9:49 AM, Oleg Broytman
I also disagree that missing features are "warts"; they are just missing features, not something unpleasant that's difficult to get rid of.
Some of those missing features are near to impossible to get rid of. The idea of anonymous code blocks is rejected constantly so no one would dare to create a patch. As for their unpleasantness -- it's in the eye of the beholder, of course. I'm not going to fight tooth and nail for my vision.
This is why the "wart" term in an inherently bad choice: it polarises disputes, and creates arguments where none needs to exist. If you instead split them into "hard problems" and "traps for the unwary", it's easier to have a more rational discussion and come up with a shared list. Interoperable asynchronous IO is an inherently hard problem - Guido's probably the only person in the world capable of gathering sufficient interest from the right people to come up with a solution that the existing async frameworks will be willing to support. Packaging and software distribution is an inherently hard problem (all current packaging systems suck, with even the best of them being either language or platform specific), made even harder in the Python case by the presence of an existing 90% solution in setuptools. Anonymous blocks in a language with a strong statement/expression dichotomy is an inherently hard problem (hence the existence of not one but two deferred PEPs on the topic: PEP 403 and 3150) Switch statements in a language without compile time named constants are an inherently hard problem, and some of the demand for this construct is reduced due to the availability of higher-order programming features (i.e. dynamic dispatch to stored callables) (hence the rejected PEPs 275 and 3103) A do/until loop has the problem of coming up with an elegant syntax that is demonstrably superior to while/if/break (hence the deferred PEP 315) The design space for things that Python *could* do is unimaginably vast. The number of changes we can make that won't have the net effect of making the language worse is vanishingly small by comparison. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia