Python 3.0 handles Dictionary differently

I read through Python 3.0 from Developer's Library about 2 months ago. I decided to skim through another introductory level book used at MIT so I could try keeping Python 2.5.x and Python 3.x separate.

While reading about Python 3.0, I didn't catch this difference. Dictionary processing has changed a little bit in the new version of Python.

For instance:

Python 2.5.x (pg 112 from MIT's reading material):
>>> letterCounts = {}
>>> for letter in "Mississippi":
letterCounts[letter] = letterCounts.get (letter, 0) + 1
>>> letterCounts
{’M’: 1, ’s’: 4, ’p’: 2, ’i’: 4}
>>> letterItems = letterCounts.items()
>>> letterItems.sort()
>>> print letterItems
[(’M’, 1), (’i’, 4), (’p’, 2), (’s’, 4)]
Python 3.1.x:
>>> letterCounts = {}
>>> for letter in "Mississippi":
letterCounts[letter] = letterCounts.get (letter, 0) + 1
>>> letterCounts
{'i': 4, 'p': 2, 's': 4, 'M': 1}
>>> letterItems = list(letterCounts.items())
>>> letterItems.sort()
>>> letterItems
[('M', 1), ('i', 4), ('p', 2), ('s', 4)]

This is a slight difference in code. In fact, the Python 3 code will work in previous versions. But, if you tried the Python 2.5.x code in Python 3, you will notice that letterItems can not be sorted. This is because "letterItems = letterCounts.items()" returns type: <class 'dict_items'>

An explanation of what is going on can be found here.

"Python 3.0 changes keys(), values() and items() so they return a lightweight set-like object, effectively making them behave like the olditer* methods, and removed the iter* methods themselves. In Python 3.0"

Ruby and Python in your script tags!

I came across this weeks ago, and I'm surprised I never posted it. This is a javascript 'framework' to add ruby and python languages in your script tags. It's a pretty awesome idea. I haven't really tested it out, but it's worth taking a look at:

http://visitmix.com/labs/gestalt/

Keeping busy with ASP.NET MVC

I'm looking for a job in "the worst recession since the great depression" blah blah blah. It really sucks.

To keep busy, I've been doing some 'freelance' work. I've been trying to expand more into MVC products by deploying a RadiantCMS site in Ruby on Rails and an e-business site I'm developing in ASP.NET MVC.

I'm liking the entire MVC mantra of keeping it DRY, or Don't Repeat Yourself. I don't know if it's because I've always hated repeating myself and this idea really hits home with me, or if it's just because it's a huge change from what I've encountered professionally and academically. Whatever it is, I love it.

One thing I love about ASP.NET MVC is it's heavy use of extension methods as "Helpers". It's easy to go overboard with helpers, but I like them anyway. One nice thing about them is that if you are like me, and sometimes forget to close some HTML tags, helpers can fix that.

For instance, if you're always writing div tags and adding id and class attributes, you can standardize the procedure with the following two methods (I overloaded them to accept objects just as ASP.NET MVC does):

   1:    /// <summary>

   2:      /// Returns a DIV with specified attributes

   3:      /// </summary>

   4:      /// <param name="helper">HtmlHelper class to extend</param>

   5:      /// <param name="contents">Contents of the DIV element</param>

   6:      /// <param name="htmlAttributes">Attributes to apply to the DIV element</param>

   7:      /// <returns>string</returns>

   8:      public static string Div(this HtmlHelper helper, string contents, object htmlAttributes)

   9:      {

  10:          return Div(helper, contents, new RouteValueDictionary(htmlAttributes));

  11:      }

  12:   

  13:      /// <summary>

  14:      /// Returns a DIV with specified attributes

  15:      /// </summary>

  16:      /// <param name="helper">HtmlHelper class to extend</param>

  17:      /// <param name="contents">Contents of the DIV elemtn</param>

  18:      /// <returns>string</returns>

  19:      public static string Div(this HtmlHelper helper, string contents, 

  20:          IDictionary<string, object> htmlAttributes)

  21:      {

  22:          TagBuilder tagBuilder = new TagBuilder("div")

  23:          {

  24:               InnerHtml = contents.NewlineToHtmlBreak() ?? string.Empty

  25:          };

  26:   

  27:          if(htmlAttributes != null)

  28:          {

  29:              tagBuilder.MergeAttributes(htmlAttributes);

  30:          }

  31:   

  32:          return tagBuilder.ToString();

  33:      }

this allows you to do the following in a View:

   1:  <%= Html.Div("<p>This is content in left_box and helper method</p>", new {@class="left_box"}) %>

You could, of course, call the methods Tag and pass in the string value of the tag to create, eg. a, div, p, em, etc. Then, you would have a fairly generic helper to standardize all of your tags!

Even the NewlineToHtmlBreak method on String class is an extension method which calls String.Replace(Environment.Newline, "<br />") on the string input. I've done this because it's easier/faster to rely on Intellisense to hit .n+TAB than to type out the entire method. Like I said, it is very easy to go overboard with Helpers!