This marble column from the Oregon Caves looks pretty impressive.
That is, until you see it with a person in the picture for scale ;)
My main web browser is Mozilla Firefox. It has this lovely little extension called AdBlock, which let's me eliminate irritating content from the web pages I view. So what does that have to do with the title of the article?
Simple: A lot of the time, I do not switch AdBlock on. Normal banner ads, that generally stay out of my way, just plain don't bother me that much. I'm happy to let them appear on the screen (even if I don't click on them). As soon as an ad starts intruding on my web experience, though, out comes AdBlock, so I can say "Leave me the hell alone, you rude, pushy mongrels". Some ads get my attention without triggering that reflex (Absolut and IBM come to mind), because they don't block the main text, and are genuinely entertaining. Other ads (especially ones that interfere with real content) discover that getting too much of my attention can be a bad thing - it raises the irritation level enough to get me to take action. And, thanks to AdBlock's address wildcards, that will mean far more than just the one ad that triggered the block will be eliminated from my web surfing.
Just checking it works. Nothing to see here. Move along.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
So, Guido has brought up the idea of optional static typing again, posting his current throughts on the idea, as well as noting what he sees as the problem areas.
His favoured syntax is:
def (a: sometype, b: sometype) -> sometype:
pass
Bleh. The main reason I dislike the current version of anonymous functions is because they embed a colon in the middle of an expression so you can probably guess how I feel about Guido's reuse of the colon here. And I've always quite liked VB's approach of using 'as' to indicate the return type of a function. Anyway, syntax aside, there's a question of what the optional type declarations are actually for.
Now one point to make at the start is that optional typing (checked by the VM) and optional static typing (checked by the compiler) are different things, and it makes some sense to do the former before doing the latter. Once you have a syntax for optional typing, making it static is merely a question of figuring out how to get the compiler to do the type check, instead of the VM. This activity would then blend in with Python's general issue of "how can we move things to the compiler to save run-time activity, without losing too much dynamism?"
Having dropped the static idea for the moment, there's the fundamental question of what does a type declaration mean? Python has historically relied on an approach that says "if it defines the right methods, it's OK by me". This is great for flexibility and code reuse, but plays merry hell with type inferencing systems, and can lead to some exceedingly cryptic error messages when you pass a type that doesn't provide the correct methods (or provides methods with the right names, but the wrong signatures, etc, etc).
Stealing an example I like:
def int_divide(x as Integer, y as Integer) as Integer:
return x / y
We don't really want x as Integer (or x : Integer in Guido's syntax) to mean isinstance(x, Integer) do we? After all, we'd like this function to work for builtin types, and Python's builtin types won't know anything about this interface we have created. It would be far nicer if the optional typing was just a way of formalising the 'duck typing' that Python currently relies on.
So let's consider something like the interfaces from PJE's PEAK, or Eiffel's idea of conformance (PEP 246, basically). In this case, we have a builtin method adapt() to adapt a given object to a given protocol. I'd suggest the meaning of the example should become:
def int_divide(x, y):
x = adapt(x, Integer)
y = adapt(y, Integer)
return adapt(x / y, Integer)
Objects participate in this scheme as interfaces by definining __adapt__ special methods, and as adaptable objects by defining __conform__ special methods. That way, interfaces and types can be written in any order, and still play well together. For instance, the existing 'adaptation methods' understood by the builtin objects' constructors (i.e. __int__, __str__ and friends) could be incorporated into the system by having the __adapt__ methods of the relevant interfaces invoke the appropriate constructor - if the constructor throws an exception, then the adaptor method converts it to the appropriate adaptation exception.
As mentioned in PEP 246, it would also be possible to have an 'adaptation registry' which mapped from (type, interface) tuples to adaptation methods. While this doesn't really matter to the basic idea of adaptation, it's handy for people trying to integrate code which provides the right interface, but doesn't actually provide the relevant adaptation information (e.g. if it provides a read() method, and the function uses an interface which expects that method).
For containers, it would make sense to have the interfaces be parameterisable (e.g. List(Integer), List(Number), List(int, long) or List() - that last example meaning, "allow a List with any types", since a list which allowed no types wouldn't be very useful). This suggests the concept of interface factories - classes whose instances are themselves interfaces.
For example (assume AdaptationError is a subclass of TypeError that is thrown when an adaptation fails):
class AdaptedOk(Exception): pass
class List(object):
def __init__(self, *args):
self._allowed_interfaces = args
def __adapt__(self, obj):
try:
lst = list(obj)
except Exception, ex:
raise AdaptationError(str(ex))
interfaces = self._allowed_interfaces
if interfaces:
for i, x in enumerate(lst):
try:
for interface in interfaces:
try:
lst[i] = adapt(x, interface, None)
raise AdaptedOk
except AdaptationError:
continue
raise AdaptationError("List element %s does not "
"support any allowed interface" % str(x))
except AdaptedOk:
pass
return lst
def __eq__(self, other):
return (isinstance(other, type(self)) and
(self._allowed_interfaces == other._allowed_interfaces))
OK, so PEP 246 combined with syntactic support would give a cleaner mechanism for dynamic type checking. However, it would still be nice to have some sort of static checking for optimisation purposes (if the compiler knows the types at compilation time, it can do all the operator lookups and so forth then, instead of waiting to do the lookups at runtime).
Well, how about a slightly different pair of special methods: __adapt_strict__ and __conform_strict__. The result of strict adaptation guarantees that the result of adaptation is an actual instance of the interface. If an interface defines __adapt_strict__ without defining __adapt__, then Python can be certain that the results of adaptation to that interface will be an instance of that interface.
For example, the builtin types might provide __adapt_strict__ methods, allowing them to be used as interfaces which guaranteed that the result was an instance of the builtin type:
isinstance(adapt(x, int), int) # Always true
isinstance(adapt(x, Integer), Integer) # Likely false
isinstance(adapt(x, Integer), int) # Only possibly true
This can give us static typing, as long as the compiler can check for the existence of __adapt__ and __adapt_strict__ on the supplied interface (e.g. by assuming the names of builtins actually refer to the builtins). Here's some hypothetical implementations of __adapt_strict__ for the builtins object and list:
def object:
# The rest of object's definition is as normal
# Naturally this would really be implemented in C. . .
# Use a class method so any new-style class
# can automatically be used for strict adaptation
@classmethod
def __adapt_strict__(cls, obj):
if isinstance(obj, cls):
return obj
try:
result = cls(obj)
except Exception, ex:
raise AdaptationError(str(ex))
return result
class AdaptedOk(Exception): pass
def list(object):
# The rest of list's definition is as normal
# Naturally this would really be implemented in C. . .
# Uses an instance method, so we use self
# to store the list of allowed interfaces
def __adapt_strict__(self, obj):
try:
lst = list(obj)
except Exception, ex:
raise AdaptationError(str(ex))
if self:
for i, x in enumerate(lst):
try:
for interface in self:
try:
lst[i] = adapt(x, interface, None)
raise AdaptedOk
except AdaptationError:
continue
raise AdaptationError("List element %s does not "
"support any allowed interface" % str(x))
except AdaptedOk:
pass
return lst
With strict adaptation available, our earlier example of non-strict list adaptation would change to be:
def List(list):
def __adapt__(self, obj):
return self.__adapt_strict__(obj)
The rules for adaptation would change slightly from those suggested in the PEP:
OK, so here's the thing. In the real world, most Australians talking about 'Nick Coghlan' are going to be talking about the guy on Secret Life of Us. If not him, then the surfer from somewhere down south. If we went to Canada, well, there's a diplomat by that name, so at least a few people would know who he is, or would have seen an article or two about him.
Enter the world of Google, though, and an awful lot of it is about me. On the first two pages of a search for "Nick Coghlan", there's just one entry halfway down the second page for the Canadian guy. The other two don't show up until the third page. The results are skewed massively in my favour because of the public mailing list web archives that Google indexes - and every one of my messages to those lists includes my name.
You can really see the effect of this by searching for "Nicholas Coghlan" instead. I disappear from the results, and the TV actor and the Canadian diplomat take control of the show. I don't show up until page 4, on an old announcement from UQ. As you might guess from that, I don't use my full first name very often.
Another interesting search is "nick coghlan -python -cygwin -software". The results are then quite similar to the "nicholas coghlan" results.
Anyway, I guess my only real observation is that, when searching just for names, Google gives extremely high weight to participation in public online communities. Obvious, one might say, but it's an interesting limitation when looking for information on more famous people that happen to share a name with someone like me.
Suppose a new employee came to work for you. They're asked to collect 20 items from the company warehouse. You come back at the end of the day to find they have retrieved only one of the items. When queried, they say, "Well, the warheouse didn't have the second item on the list, so I came back to see what you wanted to do about it." "OK, fine, where are the other 18 items, then?" "Oh, I didn't try to get those. I needed to ask you about the second item, so I came back here." You'd be justifiably pissed off, and they'd probably be well on their way to getting fired.
Yast Online Update is that employee. If it encounters a problem with any of the packages you ask it to install, it sits there with a freaking dialog box on the screen doing absolutely nothing until you come back and tell it, "Look, just get on with the rest of the downloads already".
To be fair, this problem isn't specific to YOU - YOU just happens to be the most recent example I've encountered. When a computer program is given a list of tasks to do, and encounters a problem with one of them, it should look at the list and continue on with as many of the remaining tasks as it can. At the end, it can present a report detailing any problems encountered, and asking what is to be done about each of them. With Brain Dead Software like YOU, I can't just leave it to run overnight - chances are it will only do useful work for a short while before some glitch causes it to twiddle its thumbs for the rest of the night, waiting for me to wake up and reassure it that everything is fine.
Anyway, that's Brain Dead Software - programs that do things that would get a human fired. I'm sure there'll be more entries in this category.
When I was in the US, one of the most impressive things I saw was the area around Mt St Helens. It was one of those things that made me glad my digital camera makes it so easy to take panoramic shots (click the panoramics to see slightly larger versions. If you want actual prints of any photos I post, let me know, since the originals have much better resolution than the versions I post).
The river valley downstream from the mountain:
The view from the interpretative centre:
Heading around the back of the ridge:
Looking back towards the next ridge:
And here we have Leung making an appearance (Leung is the mascot I took with me on my trip. He's a little big to make a great photo mascot, so there are long stretches of photos where he doesn't appear). Anyway, the real point of this photo is the effect of the lateral blast from the eruption. Most of the grey stuff on the ridgeline is actually dead trees that were knocked over by the blast. You can see a bunch of trunks still standing where they were sheltered by the ridgeline.
Python's a very nice language to program in, but it does have a few quirks. Normally, if you put multiple strings in your code, Python will automatically combine them into a single string.
However, it *doesn't* do this if your string literals are positioned in the "docstring" location for a class or function. If they are then only the first string will be used as the docstring - the remainder will be ignored.
Update: A quick discussion on python-dev showed that the behaviour was fairly easily explained. The string literal concatenation magic only works inside a single expression (e.g. an assignment statement). Two string literals on separate lines look like two distinct statements to the interpreter. Escaping the newline after the first literal causes the string concatenation behaviour to be applied.
So, I occasionally post stuff over at Talkinboutstuff. However, that's mostly for random crap I expect the rest of the guys to find interesting/annoying/whatever.
So, I created this extra blog for myself - somewhere to pontificate about things I don't expect them to find interesting, like software and Python and open source and what have you. And, anything of interest to them can be cross-linked quite happily :)
Maybe I'll even get around to attaching this thing to a real domain name!