Blog Posts from April 2008 (page 1 of 3)
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.
- Big news since my last Morning Coffee post was the announcement of Live Mesh. I’ve been running it for about a month, and I’m really digging it. Make sure you check out the team blog and watch the developer tour video (be on the lookout for IPy about half way thru the video)
- I had a great time @ the ALT.NET open space conference last weekend. I was somewhat distracted on Saturday as due to a family communication mixup, I had to bring my son Patrick with me. Jeffrey Palermo shot a cute video of him (3 minutes in) where he explains that he’s at the conference “to be with my dad”. Having a five year old is a little distracting, but everyone was amazingly cool with having him around. When he gets a little older I have no doubt he’ll be attending conferences and leading open sessions.
- I did a session on F#, but it felt kinda all over the place. I hadn’t touched F# in a few months and it showed IMO. Matt Podwysocki was there to help keep the session from devolving into mass chaos. Thanks Matt.
- My favorite session of the conference was Scott Hanselman’s “Are We Innovating?” talk, which I think originated from a question I asked him: There are many examples of large OSS projects in other dev communities that get ported to .NET (NHibernate, NAnt, MonoRail, etc). Can you name one that’s gone the other way? I can’t.
- I took Matt’s advice and joined the local ALT.NET Seattle group.
- Martin Maly posts about how dynamic method dispatches are cached in three different layers by the DLR. You shouldn’t care about this stuff if you’re a DLR language user, but you will certainly care about it if you’re a DLR language builder.
- I’m really excited to see Phil Haack (whom I met F2F @ ALT.NET) is experimenting with IronRuby & ASP.NET MVC. True, I’d rather it was IPy, but his Routes.LoadFromRuby would work with Python with very little code change.
- Note to self, take a deeper look at Twining, the IPy database DSL by David Seruyange.
- Daily Michael Foord – Ironclad 0.2 Released. Ironclad is a project to implement Python’s C extension API in C# so that IronPython could load standard Python C modules like SciPy and NumPy. So far, they’re able to load the bz2 module.
- Congrats to Brad and Jim for shipping xUnit.net 1.0.
- Everyone seems to be jumping on the functional C# coding bandwagon. Bart De Smet’s series on pattern matching in C# is currently at eight posts. Now Luca Bolognese is in on the action, with three posts so far on functional code in C#. I like how Luca keeps writing that the C# syntax is “not terrible” for functional programming. Again, why suffer thru the “not terrible” syntax when you could be using F# instead? (via Charlie Calvert)
- I need to take a look at VLinq. Charlie and Scott Hanselman both mentioned it recently.
- I would like to have been in the conversation with Ted Neward, Neal Ford, Venkat Subramaniam, Don Box and Amanda Silver.
- I haven’t had any time to play with XNA of late, which means the great list of GDC videos Dave Weller posted on the XNA team blog will remain beyond my ability to invest time for now.
- There’s a new drop of Spec# from MS Research. IronRuby is using Spec# heavily as I recall.
I should be mad. Angry. Furious even.
The Capitals season ended tonight in large part due to what I think was
a horrific non call in the second period. The on-air commentators were
stunned that the officials allowed the goal after the Flyers Patrick
Toresen took Caps’ goaltender Huet out of the play by body checking
Shaone Morrison into him. Sami Kapanen had the whole net to shoot at and
didn’t miss. The NHL quickly trotted out an
for the call, but what else are they going to say. “Yep, the officials
blew the call. It only decided game 7, no big deal”?
As I said, I should be pretty upset. Especially after what sounded like a poorly called game four (no comment from me – I didn’t see the game).
However, I can’t help but think back to the last Friday in November when the Caps had the worst record in the league @ 6-14-1 and had just promoted their minor league affiliate’s coach to the big leagues. If you had told me then – almost exactly five months ago – that the Caps would go 37-17-7 over the remaining 3/4ths of the season, win the division in their last game and take battle back from a 3-1 series deficit to force a game seven, I would have wondered what you were smoking.
This season has been a gift for Caps fans and I’ve relished the few games I’ve gotten to see, even the one that sent us home.
Furthermore, even though they lost, these playoffs are a promise of future success. I tell my kids all the time that the only way to get good at something is to work hard while you’re bad at it. Playoff hockey is no different. Most of the Caps had little or no playoff experience going into this series and it really showed thru the first three games. But they kept at it and played much better over the last four games of the series. They went 2-2 in those games, but the two losses went to overtime. A little more luck (or better officiating) and the Caps are headed to Pittsburgh instead of the golf course.
Speaking of Pittsburgh, look back at the Penguin’s performance in the playoffs last year. Like the Caps, Pittsburgh is loaded with young talent that were thin on playoff experience. Also like the Caps, they went home after the first round. However, unlike the Caps, they only managed one win against an Ottawa team they had beaten three times down the stretch in the regular season. Furthermore, when facing elimination, the Penguins laid a goose egg. However, as much as I hate to complement the Penguins, things are very different this year. Here’s hoping the early playoff exit has a similar effect on the Caps.
Bumping around my music collection for a song that captured my mood, I came across Getting Better from Tesla’s debut album.
All that rain, outside my window
But I’ll live on I know
Its gettin’ better every day
Soon the sun will shine, through my window
When it’s gonna come
You know I really, couldn’t say
But I know, it’s gettin’ better every day
Swapping “season” for “day” kills the rhythm and rhyme, but it captures how I feel.
Thank you Washington Capitals for a great season. I look forward to many more to come.
Thank you Bruce Boudreau for jumping in the deep end unafraid and turning this season around.
Thanks you Washington fans for turning out in such force. Who would have thought the Verizon Center would be considered “most electric arena“?
Finally, thank you to Ted Leonsis for enduring the criticism, for turning Washington DC into a hockey town and for ensuring I’ll be able to wear my #8 Ovechkin jersey until my kids are in high school.
Between MVP summit last week, ALT.NET this past weekend and an internal brown-bag presentation yesterday, my unread email and blog posts have piled up. Most of the following is old news, but I wanted to get something out. Especially since I feel a case of Caps Fever coming on that will force – ***force***you understand – me to head home early today.
- My teammate Srivatsn demonstrates how to make your static C# types act more dynamic in order to interop better with DLR languages. For example, by implementing GetBoundMember and SetMemberAfter, you can support setting arbitrary attributes on a C# class from Python. Cool.
- Today’s Michael Foord link: On Testing: Some Programmers Refuse to Get it. He’s responding to a comment by Allen Holub suggesting that having 110k of test code for 30k of production code is “a real indictment of the language” (IronPython). I’m with Michael on this, Holub’s suggestion is laughable and worse radically uninformed. I like the way Larry O’Brien (who passed on Holub’s comment in the first place) describes the views of tests from inside and outside the agile community. I also like his description of tests as “quality diodes”.
- Werner Vogels posts about a new Amazon EC2 feature: Persistent local storage. Basically, you can create an empty volume up to a terabyte in size and then mount it to your images as a drive. The objective seems to be able to run relational databases in the images, rather than being limited to S3 and SimpleDB. Kinda interesting, but given Google’s announcement last week, I think the shine is off EC2 a bit.
- This past weekend’s Twitter outage has Dave Winer re-thinking the idea of building networks on a single point of failure. While obviously I agree with the concept, I don’t agree with his solution that “We need some big infrastructure companies to get into this game”. While there are some big blog infrastructures out there, most of that network was built on a massive number of small infrastructures. Why wouldn’t the same thing work for microblogging?
We’ve hired a few people around here recently (including me obviously). However, if you have a burning desire to work on IronPython (or IronRuby) and Visual Studio, we’re still hiring:
An important aspect of developing these dynamic languages [aka IronPython and IronRuby] is providing support in the Visual Studio IDE. This includes editing features (color-coding of source code, intellisense, go-to-definition, refactoring, etc), debugging features (breakpoints, data tool tips, etc), ensuring a language-specific look-and-feel (interactive console, etc), and integration into the Visual Studio project system. It includes integration with the various designers like the WPF designer via CodeDOM, and development of project templates for various scenarios (Silverlight 2 app, WPF app, ASP.Net website, VSTT unit tests, etc). We also want to integrate with Visual Studio technologies like profiling and code coverage. Your job will be to ensure that developers using dynamic languages built on top of the Dynamic Language Runtime (DLR) have the best development environment in Visual Studio.
We’re looking for a talented developer with exceptional programming ability and a passion for dynamic languages. Experience in these areas is a bonus though not strictly required: building developer tools like editors and debuggers, compiler implementation, reflection, dynamic languages, VM implementation, performance measurement and/or optimization, C#. Applicants should have a BS/MS in computer science or equivalent, and three or more years of industry experience.