An email conversation between two members of the IPy team that you, dear reader, might find amusing.

From:Srivatsn Narayanan
Sent: Friday, May 02, 2008 4:00 PM
Subject: You dont need pinky fingers? 😄

http://twitter.com/DevHawk/statuses/802239164

---

From:Dino Viehland
Sent: Friday, May 02, 2008 11:30 PM

Wow, am I really that loud? 😄

This is a response to the idea that no design is complete until you can’t remove anything else without sacrificing the overall goals of the end result.  Is the pinky really necessary?  We can “cut that feature”, right? 😄

---

From: Srivatsn Narayanan
Sent: Friday, May 02, 2008 11:49 PM

If you cut off the pinkie, then the ring finger becomes the pinkie and so iteratively you will have to lose all of them 😃. If I remember right in Europe, you hold up the pinkie to order beer. So it’s quite important 😄

---

From: Dino Viehland
Sent: Friday, May 02, 2008 11:59 PM

Well I find it hard to argue with ordering beer, but I doubt the pinkie’s original use was to order beer.  Therefore I’d describe this as an abuse of an existing API that might be better served by a new API specifically designed for this purpose.  But I question even if a new API is necessary.

Drinking beer by definition involves a container in which the beer is consumed from.  Therefore the container it’s self (or the lack thereof) might be able to serve the dual role for both consuming the beer and indicating the need for a refill.  For example when drinking sake I’ve been told it is customary to tip the bottle on its side to indicate the desire for a refill.  Are we really to expect that the Human API exposes every need in a direct fashion?  For example should I have another appendage for “I need more bread sticks” and yet another for “Can I get a refill or on the water?”.  I’d propose the “2 creams no sugar” appendage because that’s the way I take my coffee.

On the other hand the iterative problem does seem to be more relevant – but it presupposes a purpose for the pinky in the first place!  But alas, I admit I’ve just returned from drinking beer, so this may not be the best argument 😃.

---

From: Srivatsn Narayanan
Sent: Saturday, May 03, 2008 12:21 AM

The pinkie is like a reserved field/custom field in a API. Every user community can come up with its own use for it but they have to devise the protocol themselves. Apparently different civilizations have. Wikipedia as usual has a list of those. So do you get your “2 creams no sugar” appendage – sure if u can agree on the semantics with the waiter. Seems like a PM call to me 😄

PS: What beer did u have? I should try that – seems effective 😄

---

From: Dino Viehland
Sent: Saturday, May 03, 2008 12:26 AM

I hadn’t quite considered it like this but I’d propose an alternate encoding – binary.  With 4 fingers one can communicate up to 16 different which seems to cover most of the listed issues.  Yes 5 gives you up to 32 messages but 16 should be enough for everyone 😃.

And they were various Hale’s Ales fresh from the brewery.

---

From: Srivatsn Narayanan
Sent: Saturday, May 03, 2008 12:31 AM

I wouldn’t want to hold up 0010 really (although it won’t be the middle finger anymore) 😄

---

From: Dino Viehland
Sent: Saturday, May 03, 2008 12:40 AM

Ahh, but let’s just call that one reserved – that leaves the end-user with 15 other messages!  Personally I’d suggest we reserve the entire bit – that way we could use other codes like 1010 for future expansion of various standard messages.  Urination seems popular on the pinky list so maybe we’d want to standardize that in the future – we of course need to look at uses of the other fingers before we come to this conclusion.  Users are now left with 8 user-defined messages but that seems plenty.  Also they can then use 1000 or 0001 (depending their endianness, a.k.a. left-handed or right-handed) for the now deprecated pinky-messages.

---

From: Srivatsn Narayanan
Sent: Saturday, May 03, 2008 12:55 AM

1000, 1100, 1110 and 1111 are actually used for counting numbers 1,2,3,4 😄 They are too obvious to be non-standardized. So they are out as well.

That cuts the user messages to 5 (third bit is reserved anyway). Some of the ones left are hard to make as well – try 0101 😄

We pushed out the latest beta of IronPython 2.0 this morning. From the release notes:

We’re pleased to announce the release of IronPython 2.0 Beta 2. In addition to the usual bug fixes (~25 reported on CodePlex and ~50 reported internally), this release has been partially focused on improving the performance of IronPython, in particular startup perf. Another focus of this release was improving upon our traceback support which had regressed quite a bit in 2.0B1 and had largely been broken in the 2.0 Alphas. Our traceback support should now be superior to that of IronPython 1.1!

We’ve also made a minor change to our packaging by adding a Microsoft.Scripting.Core.dll in addition to the Microsoft.Scripting.dll that’s been around since the start of 2.0. We are doing this purely as an architectural layering cleanup. Microsoft.Scripting.Core contains DLR features that are essential to building dynamic languages. Microsoft.Scripting will contain language implementation helpers that can either be re-used (e.g., BigInts) or copied (possibly e.g., the default binder). This process is all about our work to get the DLR architecture right and shouldn’t have any noticeable IronPython impact except that there’s now one more DLL to include in any package.

As a consequence of the new DLL, the deprecated file IronPython2005.sln is broken. This is the last release that will include this .sln file in the source zip file. Of course the Visual Studio 2008 version of this file, IronPython.sln, still builds.

We’d like to thank everyone in the community who reported these: kevgu, oldman, christmas, brucec, scottw, fuzzyman, haibo, Seo Sanghyeon, grizlupo, J. Merrill, perhaps, antont, 05031972, Jason Ferrara, Matt Beckius, and Davy Mitchell.

The full release notes have details about the bugs we fixed. Congrats to the team and thanks again to the community members for their assistance.

Like .NET, Python uses namespaces to avoid name collisions. However, the semantics are a bit different. If you want to use a type or function from a a given namespace in Python, you have to import it into your current scope. For example, if you want to use the Python datetime built-in module, you would import it into the current scope and use it like this:

import datetime
bush_last_day = datetime.date(2009,1,20)

Notice that when I import a Python module this way, it’s scoped into it’s namespace, which forces me to use the entire namespace scoped name to access the type. Of course, that gets tedious quickly, so Python provides a way to import a type from a specific namespace into your current scope like this:

from datetime import date
bush_last_day = date(2009,1,20)

With IronPython, you can do import .NET namespaces as well. Here’s that same code using the standard .NET DateTime class.

from System import DateTime
bush_last_day = DateTime(2009,1,20)

What I didn’t know is that you can import static methods & properties from .NET types into the current scope using the same syntax. Here’s an example:

from System.DateTime import Now

if Now >= bush_last_day:
    print 'celebrate'
else:
    print (bush_last_day - Now).Days, 'days left'

Being able to import a static method into the current scope is pretty convenient. Thanks to my teammate Jimmy for cluing me into this IPy feature.

One caveat though: in Python, you can import an entire namespace into your current scope. You can do that with .NET namespaces, but not with .NET types

from datetime import *         # this works

from System import *           # so does this

from System.DateTime import *  # this doesn’t work

Update: Michael Foord pointed out that if you import Now as I describe above, it places a DateTime object representing the time you imported it into local scope, rather than placing the underlying get_Now static method in local scope. So while DateTime.Now always returns a new value, Now never changes. Sounds like an IPy bug to me, but I’ll have to circle back with the team to be sure.

I’m back home from PyCon, but between digging out my inbox, finishing transition reports and doing my mid-year career discussion I’m a little busy. But I did want to point at a couple of recent posts from the IPy team blog:

• DLR Resources is a partial list of links to blogs (where’s mine?), mailing lists, specs, whitepapers and websites related to DLR, IronRuby and IronPython. I especially want to call out Dynamic Silverlight which not only has lots of good information but also looks frakking sweet. Props to my so-to-be teammate Jimmy Schementi.
• Dev and Test Job Openings on IronPython, IronRuby & F#. We’re hiring, so if you’re interested in working on language development @ MSFT, drop me a line and I’ll make sure it gets to the right people. BTW, I hear the IronPython PM position has been filled.