Brian Ray's Blog : Python

Painting is just another way of keeping a diary. --Picasso

Wed, 01 Mar 2006

ChiPy ChiPy Sprint

We are organizing a Code Sprint [1] for ChiPy by ChiPy ChipyChipySprint.

The idea is we want to make a site like MeetUp open source this and use this for our Chicago Python user group. Here my original note to the ChiPy list:

I propose our next Sprint Saturday March 18th. The Sprint will be in response
to Alanta's User Group site where we will make our own with Django. At the same
time we will invite those who wish to learn Python to come and get hands on
experience. I suggest we hold this all day (pending availability) at the
Lincoln Park Chicago Public Library. They have a nice big room they have let us
use in the past.

At the same time we are also organizing a free class for those who wish to learn Python. We are still working out the details but it sounds like all you will need to do is to:

  1. Sign up at ChipyChipySprint
  2. Load Python on a laptop and bring with you
  3. The hands-on class will be lead by Michael Tobis [2]

So, if your a Python Expert, come code with us. If not, become an expert.

I am suggesting we use Django instead of TurboGears. We will see if other ChiPy people go for this idea or not. Either way, I am happy to continue hosting the server. The reason I like Django is because it's agile in getting up and running. If you were at our last ChiPy Sprint you would already know getting up and running was one of our hangups. Likewise, I plan on having everyone get things set up before meeting up at the Sprint.

[1]http://en.wikipedia.org/wiki/Code_sprint
[2]Postdoc at the Department of Geophysics at the University of Chicago and an Adjunct Professor at the Department of Computer Science at Loyola University of Chicago.

Fri, 20 Jan 2006

Python Conditional Expressions

In a rather silly Chicago Python User Group Mailing List Thread, it was brought to my attention Python 2.5 will have a not-so-silly new in-line Conditional Expression feature.

Ok, so I have spent a lot of time making fun of (and sometimes secretly coding, but don't tell anybody) languages where programmers spend hours trying to write everything on one line. Likewise, I found myself hacking away on the recent seven-segment PyContest where we attempted to solve this puzzle by writing Python on one line and with a ridiculously few number of keystrokes (like 117). Would I support yet another one-liner time saver syntax much like decorators, list compression, or the lambda construct?

Yes, actually, in-line conditional expressions are a worth while language addition. The reason i am found of this feature goes back to the PEP. This ternary expression (at least the one accepted by BDFL), is extraordinarily easy to read in the form:

X if C else Y

So, now things can be done like (factored from dev-list and ChiPy mailing list):

return TRUE if a else FALSE
l = map(lambda x:'%s: "%s"' % (x[0], '""'.join(x[1]) if x[1][0] else ''), l)
b = if a[i] else a
1 if z in [1,'a',7,9] else 2

Of course, I have no clue what I just typed would actually work. That's not my point. The point is that I get some sort of understanding of each lines function by simply glancing at it. In other words, if I am reading through 1200 lines of code, this line would not throw me off so much as with one-liners from other languages, say C or PERL.

I usually wait until new language features are actually implemented and, usually, for them to appear in other sources before I even consider. For example, I am just now starting to use decorators. I trust the PSF and (in this case) BDFL who made the call on this one. I am excited about writing one-liners with this one, but only in Python.


Tue, 13 Dec 2005

Python's Whitespace

"There should be one-- and preferably only one --obvious way to do it." -- Tim Peters

Most people who know me know I am fond of Python. The biggest gripe I hear from programmers about Python is it feels restrictive, at first. Although, what I say in return is to think about with other languages how much time is waisted trying to adhere to all the best practices, DRY and Agile and so on, and work with a flimsy language. Some choices should be trivial and treated this way. Also, if your making something for someone else to use, the "how to" should be as self explanatory as possible.

Take whitespace in Python. One good thing about ChiPy is that I get to hear a lot of programmers talk about programming Python. Once a presenter said when he was first placing is Python code under version control he had done some thing really stupid, he said. He said that instead of converting his tabs to space, he checked them into source control as tabs. Now is this so bad? What is wrong with tabs under source control. For one thing, the tab size, three spaces or four... needs not specified.

I still think back to Guido van Rossum's April's fool joke in his blog. But seriously, why are people afraid of white space? And what is the proper way to handle it? Also, why does it seem some editors are so unfit for managing white space? Why are some programmers afraid to work off a restrictive foundation?

It seems to me, I am better off with Python being restrictive much the same way a carpenter feels comfortable with a rigid piece of wood. Through carefully tooling, the wood can be made pliable into whatever you want and without ever hindering productivity or creativity. Although, if you start with a flimsy piece of wood you can not do as much: not as quickly and not as concisely.


Thu, 01 Dec 2005

Snakes and more Snakes

Wow, already 122 people have RSVP'd for the Snakes and Rubies conference we are throwing this weekend here in Chicago. And who voted PyCon should not be held in Chicago? Tsk Tsk.

Good job Chipy organizers!


Sun, 20 Nov 2005

Snakes and Rubies

As it turns out, Chicago is not such a bad place for developers to hang out...

Shortly after the top ten indie Mac Developers hold a mini-conference for Mac Developers dubbed Evening at Adler here in Chicago, the Windy City will host yet another event with near celebrity status, Snakes and Rubies!.

http://snakesandrubies.com/images/snakeandruby.gif

This time from the Web Publishing World (Web 2.0), two celebrity developers Adrian Holovaty and David Heinemeier Hansson creators of Django framework and Ruby on Rails framework, respectively, will hold a public conference at Depaul.

Many other almost famous Ruby and Python developers already said they will not miss it for the world. Hey, even some Perl Mongers will show up. This may be the event of the year for next generation Web 2.0 indie masterminds to rub elbows. I wonder if anybody from out of town can make it?

Although, we do not have custom tee-shirts, trading cards, or nicknames like drunkenbatman, this still is an event no Chicago hacker should miss.


Fri, 11 Nov 2005

November Chipy Meeting

This month's Chipy meeting was a huge success: Good location, great speakers, and amazing turnout.

I can't believe how far we have come from sharing nachos at Goose Island a year and a half ago.

This months topic "Remote, Generic and Random", just like us!

Presentations

Generic Functions (aka RuleDispatch) Ian Bicking

This was Ian's best talk yet: well delivered, fun, interesting, and a strong topic.

Dispatch brings true Polymorphism to Python Functional programming. I always wondered how this could be handled in Python. Basically, Ian revealed how to dispatch used decorators to do type checking on function prototypes. I also found this nice article about PEAK's Dispatch.

From the article, here is a very simple example:

import dispatch

@dispatch.on('foo')
def doIt(foo, other, args):
    "Base generic function of 'doIt()'"

@doIt.when(int)
def doIt(foo, other, args):
    print "foo is an int |", other, args

@doIt.when(str)
def doIt(foo, other, args):
    print "foo is a str |", other, args

doIt( 1, 'this','that')  # -> foo is an int | this that
doIt('x','this','that')  # -> foo is a str | this that

So, doIt now has two prototypes and a default action. Nice generic programming!

Thanks Ian.

The Random module Robert Ramsdell

Robert gave us a good field trip into Random land. He covered all major aspects including the story behind Python's switch to MersenneTwister (original C source) from Wichmann-Hill.

The explanation went into several use cases for random seeds for pair on objects. For example, on nice backreferrece was to Robert's earlier talk on SimPy, a event simulation package. He used a similar seeded random pair to serialize asynchronous events by logging the random output. A creative approach. I imagine the report could remain cleaner and to a higher level of accuracy with a fewer numbers than if a time stamp was used.

PYRO (Python Remote Objects) Fawad Halim

Fawad went into a great detail on how and when to use Python Remote Objects. PYRO comparison to other techniques of remote communication SOAP, XMLrpc, was quite insightful.

Although I have not used PYRO, I can definitely can now see some future applications. PYRO basically allows client server communication between Python applications over TCP on a LAN. I see where PYRO method of pickling Python objects can be lighter weight than using XML. Because the two or chain of computers behave (practically) as one I see where the physical architecture can create a Cluster. To me this means either the possibly of more horsepower or the ability to power peripherally computer operations from a centralized location.

Great talk Fawad. BTW, I now clearly see this PYRO is not this one, although I still bet you I can power my robot with either ;)

All in All

Typically, I find myself nodding off in any meeting longer than 1 1/2 hours. However, this crew kept it exciting. Also, I want to thank Chris McAvoy and Performics for sponsoring the meeting.


Thu, 27 Oct 2005

IPython as primary Shell

IPython , a Python interactive shell developed for the scientific computing community by Fernando Perez is such a powerful tool, I just may replace my default login settings from just bash [1] directly to IPython over bash.

How may people do this? I mean really! Is it practical to cross this line?

If you are new to IPython, there is a decent intro article from ONLamp. Although, I fail to see how this article fits into the LAMP [2] world. Still, it unveils some need features like:

  • magic: Quickly assess special IPython features.
  • Tab Completion: auto-complete code attributes, classnames, methods, and more
  • Introspection: Easy access to Doc Strings and internal documentation
  • History: store a dumpable session of commands
  • Debugger Access: internal access to pdb
  • Run: a safe way to run a file and ignore the __name__ == "__main__", trick
  • Macros: capture command history into a macro

All great stuff. Also mentioned in the article is System Shell Access. For example, you can use cd, pwd, and ls directly in IPython. To escape to the shell use '!' or '!!'.

The IPython Manual notes in the section IPython as system shell. I loose job control if I use iPython this way. Although, I haven't had many issues so far.

Starting IPython with "ipython -p pysh", creates a special enviroment just for shell usages. Usefull in assinging aliases, moving around, and esp capturing varialbes:

bray@chipy[~]|1> $logs = ls *.log
bray@chipy[~]|2> logs.split("\n")
             <2> ['labtest.log', 'try.log', 'untitled-1.log']

In addition, with "ipython -pylab", I can do interactive plots with a fellow ChiPy member's matplotlib. I blogged more about matplotlib. For OSX users, from another ChiPy fixture, Here is some advice on getting matplotlib running.

As ludicrous as it seems, I am unable to find reasonable reasons why not to use IPython as my primary shell.

[1]Bourne Shell (/bin/sh) predecessor, for Bourne Again SHell. :D
[2]LAMP stands for Linux, Apache, MySQL, and [Perl, PHP, or Python] -- a web framework.

Sun, 18 Sep 2005

TurboGears

This is my Response to a "from __future__ import *" post:

Just when you think the number of web frameworks are about to plateau, here comes another. So, what is up with that TurboGears?

It seams to be built on a bunch of good stuff:

  • Mochikit: A javascript library from Bob
  • CherryPy: A lightweight web framework
  • SQLObject: A database wrapper from Ian
  • Kid: Some template engine I have not heard much about?

Is this competition with Django and Ruby on Rails? Should I take a serious look at this? It sometimes seems like the world needs another web-framework just like we all need another hole in our heads. Still, it seams a competent web programmer could easily just take the above packages without help from TurboGears, no?

I may be a little dense here, but can somebody tell me why all these different web programming frameworks are needed? Who is going to maintain these if by chance they do not get the expected traffic. And where does that leave the people who do decided to develop a serious application with these.


Wed, 07 Sep 2005

ChiPy Presentation: Embedding Python

I will be presenting on embedding Python into a C/C++ application Thursday night. Also, will be introducing GULP. A new project designed to provide an wrapper to help C++ developers with this task.

Other presentations will be on SWIG by John Hunter from the University of Chicago and maybe somebody will present on Elmer.

So, come see me at ChiPy.


Wed, 24 Aug 2005

Is Python Safe

Someone once asked me if Python is safer than Java. This person was a high up marketing VP from an ad agency (waves to KH). She lead a team of Java developers and I was trying to talk her into considering the move to Python for web-development. My answer was, "No, Python is not safer than Java for web development." In particular, I was referring to web-safety. Today, years later, my answer would probably be the same in this context. However, what makes a "Safe" programming language is a much larger and more complex topic. I guess it is also possible I misunderstood her questions and she was talking about a different type of safety.

What is 'Safe'

What makes a "Safe" programming language depends entirely what your trying to protect and from whom.

Save the environment

When trying to protect a shared computing environment, such as this one, there has been many attempts to make a safe version of Python (remember this thread). Here, you want to limit the damage one user can do to another or the system as a whole. Besides using proper system administration techniques, it would also require a trusted version of Python. One without all of the bells and whistles. Although, part of the advantage of Python is that the "Batteries are Included".

Later, in Python 2.3 release I believe, the Python team declared even with rexec (restricted execution) Python remained without a safe, restricted execution environment. This effected places where Python was embedded into other services. For example, PostgreSQL (in 7.4) moved plpython to plpythonu (the 'u' is for unstrusted). Sure, Python can still be embedded and used as a Procedure Language (like Oracle's PL/SQL). Also, It is "Safe" to do so in that it works great. However, the scripts can potentially do bad things if programmed to do so.

Save the information

Failing to protect information from the outside are cases of: "exploits", "compromised", "cracked", "infected" and "vulnerabilities". As with all open source languages, the level of threat is both exposed and remedied by the availability of the code.

A perfect example is the PHP worm NeverEverSanity. Although, this worm gave PHP a bad name (among other security problems they had in earlier versions) the problem was not actually PHP fault they say. The problem existed with the lack of URLencoding on form validation.

The comparison of PHP an Python is never a fair one. I like to say PHP could have been built with Python. The point here, is that Python often requires some framework to organize the web services for use of a web-programmer. For example: Django, Twisted, Plone, Zope, Paste, CherryPy, Webware, mod_python, ...

Save the programmer

Generally, the way I see it:

Language Safety Level Type Safety
"C" is least safe Weakly Static Typed
"C++" less safe Weakly Static Typed
"Python" more safe Dynamically Typed
"Java" is most safe Strongly Static Typed

But, it is more complex than this. Type-safety, namespace scopes, pre-compiler code checking, and syntax are only some of the aspects which make one programming language safer for the programmer to use.

Save the other programmer

Or, save the 'next', programmer. If you know what IOCCC means, this section is for you. A program should be legible. A complaint I often have about Perl is that it can be very hard to read, "Write Once, Read Never."

Another aspect which can effect the safety of old code is if the compiler has changed. If the compiler has change greatly there is a chance the code will no longer compile or work. So, how frequently a language changes plays a role on how safe the a program is when looked at by the next programmer on a latter date.

Python is safer than most any language in these areas. It's easy to read and the compiler does not change at too rapid of a rate.

Save the program

Another aspect of safety in whether or not the delivered product can easily be decompiled. A Python program may be deliver in text format where compiled by the receiver. This fact, by large, has made Python unsuitable for distributed commercial programs. There are ways around this. They have drawbacks.

Python is Safe

Overall, Python requires some trust to be placed on the programmer and on the others in it's environment. Other language loose luster sometimes due to the extraordinary lengths people have taken to make them Safe. I would trust Python on a lengthy and large, mission critical application.

I do not know if I gave the VP of Marketing the correct answers--causing her to make the jump to Python for use in a commercial situation. However, sometimes a length explanation may help someone better see the aspects of both sides. As with many great tools, they may also be used as weapons when in the wrong hands.