[Python-ideas] Documenting Python warts

[Nick Coghlan]

On Wed, Jan 2, 2013 at 9:49 AM, Oleg Broytman <phd at phdru.name> wrote:
>> 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 at gmail.com   |   Brisbane, Australia