In most circumstances for (key, val) in data won't work, as the default dictionary iterable only contains the keys. You want for key, val in data.items():

I use dictionary comprehensions personally but I have mixed feelings about the syntax. It looks too much like set comprehensions on first glance. Compare the following to see what I mean.

myset = {x for x in "This is my stuff".split()}

mydict = {x:len(x) for x in "This is my stuff".split()}

Well I see what you mean but then again a comma looks very much like a period ...

The advantage of this syntax is that : unambiguously introduces a key: value pair, whereas (key, value) could also occur in a list comprehension (e.g., by accident).

Or iteritems() for an iterable.

Erm, you can leave out 'in most circumstances' and 'default'; this the way they always work.

well,

    (key, val) in data 

works if

    data = {(1,2) : 3}

Well but then the variable names are just wrong.

Some of the stuff in there is pretty spectacular, like this qt-brainfuck: https://github.com/sea-kg/seakgChrysocyonParser/compare/0988...

Nine times out of ten I'd say you could probably just install from the AUR. If not I doubt you could do so programatically, because the names might not be the same.

Not only are the names not the same, but the way the packages are split differs. For instance, Debian/Ubuntu will give the end-user "somepackage", but the developer needs to also install "somepackage-dev". In Arch, the -dev stuff is included in the end-user package.

I can see the ship for a second, then it explodes and disappears. Firefox 12, Linux, Intel Mesa drivers

It seems odd that it only returns a province/state when just the area code provides more information than that. Example: any (647) or (416) area code will always be from Toronto, but numbers for both just return ONTARIO.

I have 5+ years experience with Erlang, a language I know literally not a single line of. It's from a repo (that I forked) that is half/half Erlang, Python.

/dev/random will block while waiting to collect entropy from the system. /dev/urandom will be satisfied with pseudorandom numbers. That's fine for many applications (e.g. a file filled with garbage) but not acceptable for things like cryptography.

That entropy, by the way, is derived from the keyboard and mouse devices. If you want /dev/random to go faster, move your mouse and type more ..

Can it be configured to use other sources?

Does this mean that if I've got a server with no mouse/keyboard attached, /dev/random will block forever?

Logging into my slicehost server, and running cat /dev/random | hexdump -C seems to support this, more or less - only a few lines get output unless I start typing into the terminal - then it goes marginally faster.

You can buy hardware random number generators.

http://www.entropykey.co.uk/

http://www.idquantique.com/true-random-number-generator/prod...

http://www.gamesbyemail.com/dicegenerator

...among many others.

It will also use other interrupt timings in the creation of the entropy, most notably hard drives since they're rather random on when they reply back due to it having to rotate to the right place. Not sure how this works on an SSD. I also believe if you've got some kind of hardware RNG it will use that too.

Interesting. I don't see /dev/random blocking on Mac OS X (13" MacBook Pro). I wonder what the source is?

On OS X, /dev/random and /dev/urandom are the same thing (both acting like the traditional /dev/urandom).

The kernel is literally a day older than I am, and I use it every day. I wish I'd accomplished nearly as much as it had.

Start hacking on the kernel, maybe you will :).

Programming is fun! Why else would I be here?