Dev-Picayune

(now updated with some pointless Python code)

This is perfect for this little blog concerned with trivial and small things. I noticed that my Peanuts calendar on my desk is essentially a reproduction of the 1990 calendar. Obviously, they all have to be reproductions because Charles Schulz died in 2000. So looking more closely, I realized they’d chosen 1990 primarily because the dates and days of 1990 match 2007. So a quick hack with the ‘cal’ program under linux and I was off and searching for what will most likely be next year’s calendar. Since 2008 is a leap year and obviously 1991 is not, I knew that wasn’t going to work.

First I generated target calendar with:

cal 2008 > cal2008.txt

Then, I just manually (although I could have written a script) looped through a few known leap years and found that 1980 seems to match perfectly as well.

cal 1980|diff - cal2008.txt

Obviously, what we’re looking for is a diff of only the first line, the year. Side note: the selection of 1952 (also a match), would seem to be fairly unlikely.

For 2009, there are a bunch of choices including: 1953, 1959, 1970, 1981, 1987 and 1998.

Why am I posted this? I don’t know other than it was fun to use ‘cal’ and ‘diff’ to anticipate which Peanuts calendar would be next.

UPDATE

I couldn’t resist doing a Python solution to this little problem. I know this isn’t as efficient as someone else could make it, but it was entertaining for me to do it. It took about 5 or 6 minutes to write and ran correctly the first time (matching my previous results):

import sys 
import datetime
def matchCals(inputYear,minYear,maxYear):
    sDayOfWeek = datetime.date(inputYear,1,1).weekday()
    eDayOfWeek = datetime.date(inputYear,12,31).weekday()
    for testYear in range(minYear,maxYear+1):
        if (sDayOfWeek == datetime.date(testYear,1,1).weekday() and eDayOfWeek == datetime.date(testYear,12,31).weekday()):
            print "Match Found... %s = %s" % (str(testYear) , str(inputYear))
 
if __name__ == "__main__":
    matchCals(int(sys.argv[1]), int(sys.argv[2]), int(sys.argv[3]))

Here I just check the day of the week on the first day of the year, and the last day of the year. If both of those fall on the same day, I assume the calendars for those years are the same. And since we’re dealing with a limited set of dates (valid complete Peanuts calendars running roughly 1951 to 1999, it handles a min and max year for input as well. So to run it for 2008, you just type in:

python ./caltest.py 2008 1951 1999

Of course, there is no error checking… so if you enter a string or an invalid year… that’s your own problem. I just wanted to see how quick I could do it. Obviously, I’ve waisted more of my time… and more of your time.

Brandon and I were exchanging emails the other day about the state of Python IDE’s and specifically about IDE support for GUI’s. My thought was that while nearly every distribution of Python has Tkinter with it, it’s just so impotent that despite being included it’s not really the standard GUI library for Python. Whether it’s wxPython, or PyGTK or something else, there’s plenty of debate on GUI frameworks and Python. That has certainly hurt the Python community a little if what you’re looking for a great editor IDE combined with a great GUI layout tool.

So what does this have to do with web frameworks? I’d say that unlike the GUI thing, we’re probably better off in a sense because Python retains it’s own identity. Unlike Ruby, where one can barely think or mention the name Ruby without also saying “Rails”. It’s like saying Marco without saying Polo. Ruby has (in my opinion) lost a fair amount of identity because of Rails. Certainly, there are plenty of projects in the Ruby community that by their nature will start to reverse that (one that immediately comes to mind is IronRuby). But just imagine for a moment if Python was just known for one web framework only. What if it was “Python turning TurboGears” or “Python on Pylons” or “Twisted Python (aka Python in a Knot)” or even “Python was his Django”. Python would lose some of its identity. So, for those who like to revel in the diversity of web solutions for Python, enjoy! And for those who wish the community would just pick one framework, they can just go to Zope.