This is from the first recipe in my brand-new Python cookbook. It’s quite obvious, but it hasn’t really struck me before. Well doh. In most languages, swapping the values in two variables means using an intermediate temporary variable, e.g.: int a = 1; int b = 2; int temp; temp = a; a = b; b = temp; With the tuple packing and unpacking in Python however, we don’t need no steenking temporary variables!
Have a look at this brief snippet: In : a = range(10) In : 3 in a Out: 1 In : 3 not in a Out: 0 In : not (3 in a) Out: 0 Input/output 4 should strike you as a tad strange if you don’t know Python that well but are familiar with similar constructs in other languages. At first glance, it almost seems like the sense of an operator can be negated with the not operator.
This should be very useful: In : class oldObject: ...: ....def __init__(self): ...: ........self.someVar = 1 ...: In : o1 = oldObject() In : o1.someVar = 2 In : o1.someOtherVar = 3 This is of course expected behaviour. Have a look at this though: In : class newObject(object): ...: ....__slots__ = ['someVar'] ...: ....def __init__(self): ...: ........self.someVar = 1 ...: In : o2 = newObject() In : o2.someVar = 2 In : o2.
I broke down and ordered Python in a Nutshell by the Python guru Alex Martelli as well as The Python Cookbook, edited by Alex Martelli and David Ascher. Amazon UK will now proceed to bend my credit card even further, but that’s okay. It’s really flexible. EET VILL INCREEEZE MY PYTHON POWERS 10-FOLD, UND ZEN I VILL TAKE OVER DE WORLD!
Yes, where are those Weapons of Mass Destruction that the US was warning everybody about? Those same WMDs that were used as some of the primary excuses for violating Iraq have not popped up yet, it seems. Funny… In related news, this article reports that there was a certain pressure by the US administration on the intelligence services to generate reports that would help to convince the public that attacking Iraq was urgent business.
According to the new VESA CVT (Coordinated Video Timing) system for describing display pixel formats, the display on my laptop has magically turned into a 1.47M3. SXGA+ is now officially passé.
Today Paul discovered ZomboCom. You can do anything at ZomboCom. ZomboCom is strangely comforting. Why can’t I stop staring at ZomboCom?
I’m reading some more juicy bits from the Microsoft Windows Official Guidelines for User Interface Developers and Designers. This section details the specific layout of controls in windows and dialog boxes. At least now the dialogs I design are more or less consistent with some standard. :)
Most of us outside the borders of the USA know this, but nothing we do or say will probably have any kind of effect on the status quo: The American government is supported by an extremely efficient propaganda machine that ensures that the majority of its citizens will support it in its most barbaric of ventures. The big problem is that this propaganda machine consists primarily, contrarily to tradition, of “independent” media entities.
So, here we have the Aqua Human Interface Guidelines (i.e. the MacOS-X user interface guidelines), the GNOME Human Interface Guidelines, the KDE User Interface Guidelines and of course the Microsoft Windows Official Guidelines for User Interface Developers and Designers (I came back in January of 2018 to fix this link — also interesting is the section on margins and spacing).
Apple says that “The default button for dismissing a dialog should go in the lower-right corner. If there’s a Cancel button, it should be to the left of the default button.”. Gnome seems to imply that the default button should be on the bottom right, with other buttons to its left, which is more or less consistent with the Apple guidelines.
Microsoft says: “Lay out the major command buttons either stacked along the upper right border of the dialog box or lined up across the bottom of the dialog box. Position the most important button — typically the default command — as the first button in the set.” The KDE User Interface Guidelines don’t seem to set specific constraints on this kind of button placement, but judging by many of the standard KDE 3.1 applications, the dialogs seem to follow the Windows convention.