Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Types certainly matter, and Python has types. Yes, feeding the wrong type into a function probably won't work. It'll raise an exception and you'll see a traceback that helps you to fix your code.
If you want to check the types that are supplied to a function, you can do it with assertions. You can even go further and check the things going in have the properties you want. Type checks are a crude form of precondition. A function that expects a tuple will probably work with a list. A function that works with an iterable can accept a whole load of types without all the constipation of an explicitly coded interface to declare for all of them.
If you want the type errors picked up before you execute the code, you might be in luck. You could use the assertions, although I don't know of any tools that do this. There's also a convention for type specifications in docstrings. And official support for function annotations:
None of which addresses static typing as such, which says that after assigning an integer to a variable, you shouldn't be able to reassign it as a float.
There are, still, real advantages to static typing and languages that give you those benefits with type inference, so you don't have to put type declarations all over the place. There are also languages with better generics than void * in C or Object in Java. (C++ and Java are even two of them). Mixing the good features of Python with a good static typing system would certainly be a good thing.
Oh, and I've been programming for a good deal longer than 20 years. I can appreciate different languages for working in different ways.
It's Debian with a coherent desktop built around Openbox, and an installer, and maybe some other choices different to the Debian defaults. It uses the Debian repositories as well as its own and even declares itself "Debian GNU/Linux" when you SSH in.
I happen to prefer the LXDE desktop now I can turn the bits I don't want off. I can understand the argument that Crunchbang isn't as important as it was. But enough people will prefer the Crunchbang style that they'll keep it going with a different name.
If you want a systemd-less Debian, go make a systemd-less Debian. Make it everything you think crunchbang should have been. Nobody's stopping you.
It isn't much more than a metapackage, anyway. Gnome, KDE, LXDE, and XFCE are all metapackages and Debian live images. There is a point to Crunchbang living on in some form because most of the desktop is different to LXDE (they both have Openbox). And it probably will live, but with a different name.
The autostart specification defines a method for automatically starting applications during the startup of a desktop environment after the user has logged in and after mounting a removable medium.
http://www.freedesktop.org/wiki/Specifications/autostart-spec/ Obviously, desktops could still do with a better way of starting services and making sure they stay running. Because that wouldn't be at all useful on servers or anything.
I have a vague memory of the DHMO project being about the presentation of science in the media, rather than public ignorance. It showed how people will get the wrong idea if you portray a scientific issue badly. Ironically, this story has been hideously portrayed in the media. We're told that 80% of Americans support labeling of food containing DNA, which is much the same as 80% of Americans supporting food labeling, which is an obviously good idea, so you wonder what the other 20% were thinking. But oh, no, let's make fun of these people who fell for a ludicrous scam without actually explaining what was ludicrous about it.
By "tenure" they mean experience. They don't say why they didn't call it "experience".
The trouble is, the Internet is standardized on UTC. You can keep your system clock to TAI and use the "right" time zone files, but you have to deal with the offset between your clock and NTP, and the complexity of NTP broadcasting the leap second as it happens. (Or forego the convenience of NTP altogether, of course.)
There should be an RFC to decree that for networking purposes, we'll ignore this and future leap seconds and keep "Internet UTC" as a fixed offset from TAI. People who care about strict UTC (and it would, apparently, cost millions of dollars to fix critical military systems) can use libraries or time zones to get it. The rest of us will know our system clocks keep ticking away with minimal breakage.
What will probably happen is that we follow the leap second again, things break again, and any impetus to fix the underlying cause dies away by the time the next leap second comes around. And eventually UTC will be defined as consistent atomic time and the people who wanted UTC for what it was originally designed for will have to learn to call it something else.
Monopoly is certainly best as an out-of-the-box game. You can't do much at all if you leave everything in the box.
I'm distracted from the whole argument by this idea that two standard deviations above the mean isn't that great. In fact, it puts you well within the top 4% of the population (assuming a gaussian distribution). Is that how smart they are or how smart they think they are?
There's an even more basic misunderstanding if he thinks Linux is somehow responsible for an OpenBSD project.
S.encode(encoding='utf-8', errors='strict') -> bytes
Encode S using the codec registered for encoding. Default encoding
is 'utf-8'. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a UnicodeEncodeError. Other possible values are 'ignore', 'replace' and
'xmlcharrefreplace' as well as any other name registered with
codecs.register_error that can handle UnicodeEncodeErrors.
foo == "constant" will not throw an exception. It does not coerce anything. If foo is not a string, it will return false.
The bytes type does have isalpha(). At least in 3.2.3. It really does.
You can't search bytes for 'A' without thinking about encodings because encodings matter. You can search bytes for b'A'.
They have added isalpha() to bytes. They do assume it is ASCII if it's in the ASCII range.
If you want to compare bytes with str, you can do the encoding if you know what you want. The language will refuse the temptation to guess.
You can turn a quoted string into a bytes object: by decoding it.
If the source is UTF-8, it won't have errors. Errors are, by definition, not UTF-8. The parser will refuse the temptation to guess what encoding you meant.
This is a Python article! Of course somebody has to complain about whitespace! When did you ever know a Python article to not start an argument about whitespace?