Written by Ram Rachum, developer of GarlicSim.
Text
Silly Python riddle
Here’s a silly Python riddle for you.
Today I opened up a Python 2.7 shell, and ran two commands in it.
>>> f = lambda: g(???)
>>> f()
(Note that these are the only commands that I ran. You’re not allowed to run any other commands before them.)
The riddle: What’s the shortest thing you can put instead of ??? so my second command would not raise an exception?
Edit: I just posted it and people are already coming up with creative solutions! So now it’s time to say: The winning solution is 7 characters long. Try to match that!
———————————
Update: An anonymous commenter on Hacker News solved it!
The solution:
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
(Scroll down…)
The solution:
>>> f = lambda: g((yield))
>>> f()Funny, isn’t it? I was surprised to see that the yield keyword can be used in a lambda function.
So when you type f(), it just returns a generator. If you’ll try to exhaust it, an exception will be raised because g doesn’t exist, but that’s a new line :)
It’s funny that in this case, Python seems to throw away the value of the lambda function! As we know, the yield keyword actually forms an expression whose value is None, unless you used the generator’s .send instead of .next. So you could also use .send to send in whatever value you want into the lambda function, and Python will just throw it away. Unless I’m missing something.
So that’s the only case I can think of where Python completely throws away the value of a lambda function.
Text
The `coverage` module celebrates 10 years today!
Today, December 4th 2011, marks the tenth birthday of the excellent coverage module! Here is the changelog entry showing it was created exactly ten years ago, on December 4th, 2001 by Gareth Rees.
The coverage module is one of the most sturdy and reliable pillars of my development toolset. It’s a hallmark of a great tool that you never have to spend too much with it— When I want to check the statement-coverage of my tests, I just use coverage (invoked via its Nose plugin), it just works, and then I can go back to writing my tests and ensuring they cover a big part of my code. You don’t have to spend too much time with it for the simple reason that it very rarely breaks— Which is not a trivial accomplishment for a tool that acts on every, single, line of code in your project.
Kudos to Ned Batchelder for his excellent maintenance of the coverage module! I’m a relatively new user of coverage, having used it only for about 2 years, if I remember correctly. So long-time users of coverage may have a bigger perspective on this module than I do. But in the relatively short time that I’ve been using it, Ned has been an exemplary maintainer, and the few tickets that I created on the bug tracker received his attention. Ned also made sure that coverage supported Python 3.x before it was cool, and on every release he takes the time to create Windows binaries of coverage to help Windows users avoid having to compile it themselves.
If every maintainer was as dedicated as Ned, the Python community would be in a better place today, and we would have probably already seen Python 3.x going into mainstream.
Thank you, Gareth and Ned, for this wonderful module!
Text
Deadline for GarlicSim 0.7 cancelled
Just when I finished one contract job and thought that I finally had time for some serious work on GarlicSim, I got a new contract job.
Since the deadline for the GarlicSim 0.7 release has been postponed so many times, I’m just going to cancel the deadline altogether. Sorry for the disappointment.
I’m angry at myself for not making the deadlines, but on the other hand I’m happy about having a bunch of contract jobs. This will allow me to spend a lot of time on GarlicSim later on. My contract jobs have already allowed me to do a bunch of upgrades and improvements of my work environment (from hardware upgrades, through time-saving AutoHotKey scripts, to ergonomic upgrades), and that really helps me be more productive, both in my contract work and my open-source work.
Text
GUIs kick CLIs’ asses
Or, “Hey programmers, did you know you can use a GUI with the keyboard?”
This post is part 1 of the Unpopular Opinions series. In this series I will present a few opinions of mine that go against what most other software developers think. If you disagree any of these posts, you know they’re working. Please stay civil in the comments— Criticizing my opinions is encouraged, as long as it’s done in a constructive and respectful manner.
One of the big things that have been bugging me ever since I became a professional developer is that most developers shun GUIs.
As a developer, I often get to hang out with other developers and see their tools and work processes— Sometimes in person, and sometimes online. I quickly found that almost all of them hate GUIs (Graphical User Interfaces, i.e. visual programs with windows, buttons, menus, dialogs, etc.) Most programmers much prefer working with CLIs (Command Line Interfaces, i.e. a textual shell.)[1]
Page 1 of 17
