Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
rosuav at gmail.com
Sat Mar 29 04:45:29 CET 2014
On Sat, Mar 29, 2014 at 2:18 PM, Mark H Harris <harrismh777 at gmail.com> wrote:
> On 3/28/14 9:45 PM, Chris Angelico wrote:
>> ... uhh... how does the QWERTY system demonstrate Microsoft's
>> control?? There's more than a hundred years of gap between them, and
>> in the wrong order.
> You know the answer to this question. Does your keyboard have the
> "Windows" emblem|logo on the meta key(s) on lower right, lower left? On a
> standard keyboard its the meta key between ctrl and alt. Microsoft has
> controlled that meta section of the keyboard for years, effectively
> preventing those keys from being used for unicode meta control keys
> (ironical considering the fact the Microsoft is a major player at the
> unicode consortium). The meta keyboard on the mac is much more of what I
> have in mind, but that's mac only for now.
No, actually. A lot of my keyboards don't have those, and even those
that do aren't controlled by Microsoft. We've been using those for
other purposes since they first came out. To claim that they indicate
MS control is just as ridiculous as claiming that the Backspace key
indicates control from the Remington Typewriter Company.
>> By the way, thanks for telling me what a zillion is. It must be 65536,
>> because that's the biggest thing Unicode gives us plural of in number
>> of characters. :)
> ha! :-)) A zillion is 65536 x(several thousand languages). Actually I
> used a zillion because the consortium doesn't even put a number on it...
> because there is a difference between script and language, and there are
> many languages that use Latin. The point is its a huge number greater than
> 128 or 256. (or 104)
>> Considering that we have ten fingers, having 1114112 keys would be
>> quite impractical.
> don't be literal, think meta pages (key mappings) over the actual
> keyboard, but think "standards".
The Unicode standard specifies only 1114112 possible codepoints, of
which only roughly 200K are currently allocated. (And those figures
include non-character codepoints, like the U+D800 to U+DFFF range used
to encode non-BMP codepoints into UTF-16.) So you can't possibly need
any more than that - just over a million - for full Unicode support.
That's standards for you.
>> Do you really want a keyboard that takes up that much space? Most
>> people can't efficiently use F1 through F12, much less another hundred
>> or two hundred keys.
> No, I want a standard unicode keyboard (a standard specification for a
> unicode keyboard) that facilitates unicode typing with minimal actual keys
> and standard key maps for alternate sets that may be easily selected without
> a mouse and without moving the hands from the home row.
Minimal actual keys. Steven almost got it with the link he posted
above, but I can cut one more key off it: if you always press exactly
21 keys to enter one codepoint, you don't need a "Done" key. (But the
"Done" key would allow you to type some characters much more quickly.
You can send a spew of U+0000 just by holding Done, for instance; and
what an accomplishment THAT is in a family man! )
> The mac does a pretty good job of this now, but the mapping editor is not
> built-in; otherwise, the key mappings are very good, quite easy, and very
> fast. But, like Steven pointed out, everyone needs to be on the same unicode
> input device (as standard) before language specs could relay on certain code
> points for tokens | identifiers.
If that idealized Unicode keyboard were worth doing, it would have
been done by now. There are myriad keyboard designs to choose from,
None has the hundreds of keys needed for rapid entry of arbitrary
Unicode codepoints or characters (in theory you could have a key that
creates a full CCS). Why? Because there's no demand for it.
 Look up Gilbert & Sullivan's "Ruddigore" for a very similar line
of argument regarding a sailor.
More information about the Python-list