Gets worse if you own an electric vehicle. My power company has a neighbor comparison tool, where it compares my electric usage to similar neighbors (the nearest 100 houses of roughly the same size, same heat/AC systems, same number of occupants). I reliably came in between #2 and #5 lowest electric usage. Until I bought a Leaf. I'm still in the top 20% "most efficient", but only barely, thanks to the $20-30 of electricity it takes to fuel each month. Because I got rid of a 20 MPG rusting to pieces junker for a 115 MPGe vehicle, my performance on the one metric of "home electric use" went down.
The ability to seamlessly use + with mixed text and numeric types in a language without explicitly declared types is usually considered a design flaw, not a positive feature. Perl uses separate operators for strings vs. numbers to avoid ambiguity, while Python and Ruby require explicit type conversions. Java defaults to string concatenation, but Java requires explicit types, so you get a compile time warning if you make a mistake like adding a String and an int and expecting an int. Even PHP, the go to standard for poor language design, which explicitly rejects separating operators for strings and numbers, made a concession for addition vs. concatenation and borrowed Perl's approach of using + for addition and . for concatenation so the operator itself selects the operation.
As for the ternary operator, really? That's your big gripe? The fact that it reads like an English sentence? Guido hates excessively concise/cryptic punctuation as language elements, so they chose something that reads a bit more like English; if you read it aloud, e.g. "a if a is not None else b", it makes sense. You could also view it as a stealthy attack on the ternary operator, which many people despise as encouraging cryptic code. Either way, we're not talking about something truly ridiculous here; it's a reasonable design decision. This isn't PHP's left associative ternary operator or anything.
I really hope 3.x, if only for the fact that your code tends to work with non-English text by default, because str supports the whole Unicode range, so it works with non-English input by default. Compare to 2.x where you have to make a conscious effort to work with Unicode. Particularly important for third party libraries, where they aren't producing a final application, and often don't think about Unicode at all even for text based APIs. Heck, the Python built-in csv module in 2.7 doesn't work properly with Unicode; you have to load or convert as UTF-8 bytes, parse, then decode to the 2.7 unicode type. It's a mess.
For teaching purposes 3.x is even better, since you have a proper distinction between binary data and text, rather than the mushy 2.x situation where str is sometimes binary data and sometimes handicapped text, while unicode is always text, and sometimes interoperates with str, while at other times it explodes. Teaching languages should be consistent, and 3.x is simply more consistent than 2.x (largely because of cleanup decisions like this).
I agree that a good shared standard might allow for efficient production of batteries by removing the market fragmentation that dissuades people from starting up "gigafactories".
That said, Tesla hasn't demonstrated a superior battery technology. The 2013 Leaf's range was rated lower than it really should have been. It offered a "Long life" charging setting, where it would stop charging at 80% instead of 100% to extend battery life. The EPA decided to base the estimated range on a 90% charge to split the difference between the two options, because the 80% charge was "recommended". Tesla allows you to stop charging at any 10% increment between 50% and 100%, but because lower charges aren't "recommended" the EPA assigned a range based on a 100% charge.
Factoring that in, at 100% charge, the 2013 Leaf should have a range of ~84-85 miles. Assuming 84, on a 24 kWh battery pack, that's 3.5 mi/kWh. The Tesla gets ~3.1 mi/kWh. The Tesla is heavier thanks to all those extra batteries, which is a big part of the difference; I suspect that if you made a Tesla with a 24 kWh pack, it would have similar efficiency to the Leaf. Battery tech is hard to improve; Tesla and Nissan are using the same basic tech.
TL;DR: Stacking more batteries is hardly a demonstration of superior technology.
A short key right now is 512 bits (0.5 KB). A longish key right now is 4096 bits (4 KB); many sites use shorter keys because high traffic sites can't afford the bandwidth and CPU required to transmit and process even a 4096 bit key for thousands of connections per second. Squaring even the short end of that range would produce a 262144 bit key (256KB). That's a ridiculous amount of data overhead just to initiate a connection, and performing math in a space that large would tax the CPU of individual computers; if a web server is performing that much math for every connection, you'd dramatically increase the overhead to serve web pages.
TL;DR: Squaring key length make math hard, hurt computer.