Comments for Honest to a Segfault

Comment on A prototypal binding trap by cdleary

cdleary — Mon, 06 Sep 2010 22:38:53 +0000

@Peter Hansen: Honestly, I'm not concerned. This entry wasn't written with a newbie audience in mind -- readers already have to be familiar with the idea of method resolution order to understand why self._next_id would resolve to Egg._next_id. I think readers at that level of expertise will understand why I chose to use is, especially if they read your helpful comments. :-)

Comment on A prototypal binding trap by Peter Hansen

Peter Hansen — Mon, 06 Sep 2010 19:31:04 +0000

@cdleary, I understand what you are trying to do, but it’s if nothing else potentially confusing for newcomers. Though it’s obviously not going to happen in your simple test case, in a multithreaded application (for but one example of how this could occur), another thread might set Egg._next_id to 2 just before your assert statement… and your assert statement would not fail!

Comment on A prototypal binding trap by cdleary

cdleary — Mon, 06 Sep 2010 18:26:35 +0000

@Peter Hansen: Thanks for the feedback. As you point out, you almost never want to use the is operator in day-to-day programming; however, in this case, is is doing exactly what we want -- we want to see if self._next_id is identical to Egg._next_id, meaning that they resolve to the same object. Yes, the virtual machine keeps an integer object pool that could turn is into == behind our backs, but identity is the operation we really want here (semantically).

Comment on A prototypal binding trap by Peter Hansen

Peter Hansen — Mon, 06 Sep 2010 15:27:43 +0000

It appears there’s another trap, this time lurking in that assertion. Using identity to compare integers can give unexpected results, since for integers in the range -5..256 (as of Python 2.6.5 anyway) the interpreter precreates and caches instances for each value (thus ensuring that if a and b are both 5, “a is b” will be True), but for integers outside that range it does not (meaning that for most integers, “a is b” will be False). The moral is never use “is” to compare integers.

Comment on A prototypal binding trap by Tweets that mention Honest to a Segfault» Blog Archive » A prototypal binding trap -- Topsy.com

Mon, 06 Sep 2010 00:06:14 +0000

[...] This post was mentioned on Twitter by Planet Python, Chris Leary. Chris Leary said: Posted: A prototypal binding trap http://bit.ly/aQOYbo [...]

Comment on House rental, showers, and auctions by Dave

Dave — Sat, 07 Aug 2010 23:14:58 +0000

We actually had exactly the same config in Redmond.
No one wanted to pay more for any of the rooms, so we split it equally. But I got the master bedroom in exchange for acting as the house dad, ie. taking care of all the bills and collecting each month, making sure anything else was taken care of, etc.

Comment on House rental, showers, and auctions by walla walla

walla walla — Thu, 05 Aug 2010 04:37:38 +0000

Assuming a year long lease how about each person gets a different room every 3 months. Keeps things interesting and motivates people to keep their room somewhat clean since they’ll be subjected to someone else’s after a quarter.

Comment on Coding style as a feature of language design by cdleary

cdleary — Wed, 04 Aug 2010 09:45:49 +0000

@Gerv: Ah, nice catch — you might have to continue to enforce style guidelines for comments. Human languages are a _lot_ harder to reformat/reflow. :-)

It seems like there are a few common heuristics for comment styles you might be able to factor out in a language-neutral and most-of-what-you-want kind of way. For example, on one of my projects we used \param instead of @param doxygen-style comments; also, it’s probably not hard to convert simple things like “stars on every line” to “stars on just the first and last lines”.

Comment on Coding style as a feature of language design by Gerv

Gerv — Wed, 04 Aug 2010 09:26:32 +0000

One thing you’ve missed is comments. Some styles have comments like this:

/**********************************************************/
/* This is a comment in a nice box */
/**********************************************************/

If, say, your preference was for 75 character lines instead of 80, this wouldn’t work well.

Gerv

Comment on Coding style as a feature of language design by Simon

Simon — Sun, 01 Aug 2010 23:04:12 +0000

@Chris – to some degree, the auto formatting could be made smarter if it can recognise certain ‘idioms’ in the code, such as the chained “return this” methods of a builder (like StringBuilder, or Hibernate’s Criteria queries). Supported, perhaps, by some form of metadata – not explicit formatting instructions, but something to tell it “this class is a builder”, so it can apply “builder” formatting rules?

It’s not perfect though, since I can’t see how *any* automated process could recognise that the fourth “append” call in my example above ought to be on the same line as the previous one, instead of on a new line like most builders. Though I suppose StringBuilder is an unusual case, a very generic builder, without a lot of semantics to the method names.