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.
--
https://mail.python.org/mailman/listinfo/python-list
