How coding in Python is bad for you

[Steve D'Aprano]

On Mon, 30 Jan 2017 12:05 am, BartC wrote:

> What might be unreasonable is to criticise it in a Python group full
> of language aficionados who are going to view every feature and quirk of
> the language in a good light; 

It's all about the trade-offs we choose to make. Its not that we don't
understand that feature X has a downside; its that we value that feature
enough to make up for it.


> nothing is ever a problem! 

1. for...else is misspelled, and should be for...then;

2. Same for while...else;

3. shutil.get_terminal_size() is broken by design;

4. Decimal is not integrated with the numeric tower;

5. The statistics module is too slow (and if I ever meet the author, I'll
give him a kick in the head);

6. duck-typing with numbers often fails, requiring you to resort to
polymorphic code with type checking;

7. which is too slow;

8. fractions could easily support infinities (±1/0) and NAN (0/0) but don't;

9. the state of GUI toolkits in 2017 is nowhere near as easy to use as
Hypercard in 1986 (although that doesn't apply just to Python);

10. packaging is still too complex and hard to get right;

11. the last couple of years has seen an emphasis on asynchronous
programming that I don't understand and scares me;

12. there's no try...except expression;

13. or constants;

14. writing bullet-proof file handling code (e.g. atomic file save that
either is guaranteed to write to the disk or guaranteed to leave the
previous file contents in place) is too hard;

15. str.centre() is misspelled;

16. despite what the Zen says, there aren't enough namespaces;

17. unicodedata is missing a lot of functionality;

18. CPython makes object IDs look like memory addresses;

19. there's no way to tell the compiler to do certain calculations at
compile-time, instead of run-time;

20. the utf-8 encoder is strict, but the utf-16 and utf-32 encoders are not,
which makes them technically non-compliant;

21. the CPython compiler isn't smart enough, and so has to forgo the
opportunity for optimizations which apply 99.9% of the time, because of the
0.1% of the time that they don't apply (e.g. in-lining functions);

22. there's no syntax for Design By Contract;

23. no support for Snobol/Icon like string patterns (BNF context-free
grammars, more powerful than regular expressions);

24. lack of support for Prolog-like logic programming paradigm;

25. no way to bail out of generator expressions early, e.g. (expr for x in
seq while condition);

26. the glob module doesn't support escaping, or {a,b,c} alternatives;

27. in hindsight, all() and any() shouldn't coerce their result to True or
False, but return a truthy or falsey value from their inputs.


That's just off the top of my head. Is that enough for you?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.