Just because a workaround exists, doesn't stop it being DRM.
Well, saying that this is "DRM", based on what's known at the moment (not based on what's speculated by outlets which stand to benefit from the traffic such a story would bring them), would begin to dilute the term into meaninglessness. One might as well say that a car has "DRM" because you have to buy gas to keep the engine running...
You might want to read a couple of Iain M. Banks' Culture novels.
The premise of the Culture is your basic lax post-scarcity society -- people can have whatever they want, do whatever they want, etc. -- but then it confronts the question of what such a society's long-term goals would be, and what happens to people who aren't content to spend their entire lives getting high and going to parties (solution: they go out and mess around with less-technologically-advanced societies to try to steer their development into something resembling the Culture, providing the basis for most of the books' plots). A good introduction (since it's relatively self-contained and lets you pick stuff up as you go), if you're interested, is The Player of Games. Then if you like it, move on to, say, Use of Weapons or Excession.
So it is illegal/unconstitutional to prevent speech, but it's legal/constitutional to punish you after you say it?
You seem to be hung up on a misunderstanding: rape is a crime, and is handled by a criminal process whereby a government official prosecutes you and, if convicted, you receive a sentence from the government as punishment. Defamation (which includes libel, slander, etc.), on the other hand (in this type of case, and in the US), is not a crime. The government does not prosecute people for it, and does not punish people for it. It's a tort, and is handled by a civil process; effectively, the government-run court acts as a sort of mediator/enforcer in a disagreement between individuals or corporations. A tort (the word comes to us from the French for "wrong") is something you shouldn't have done (whether deliberately or accidentally) and which caused some actual harm to a person or actual damage to someone's property (although, importantly, not a breach of contract -- that's handled by a separate area of law), and the result of a successful lawsuit over a tort is payment of damages or some other form of restitution.
Which brings me back once again to the key difference: defamation laws do not restrict or prevent or outlaw any type of speech. They simply provide people with a way to be compensated for harm done to them.
In the case of defamation, generally it is asserted that a person's reputation has been harmed by a particular statement, and the standard of proof for the harm varies with the type of statement. Some statements -- for example, false assertions that someone has committed a serious crime -- are (in most US states) automatically considered harmful enough to be defamation, but other statements require a description of the alleged harm and proof that the harm actually occurred as a result of the statement. Also, (again, in the US) a defamation suit must generally prove that the statements either were made with intent to cause harm, or were made with negligent disregard for their truth (this provision and several others in US defamation law, by the way, exist precisely because of the First Amendment, in order to prevent defamation suits from having an improperly chilling effect on the genuine expression of opinion).
So this isn't really a candidate for a slippery slope argument; the body of law around defamation is literally thousands of years old, and has been refined and clarified over that time to ensure that it's fair and equitable to both sides, with a history of court rulings balancing the need to redress harm against the need to protect free speech. Unfortunately, it's just not something the average person ever really learns about...
But the "right" to not be defamed is not defined in the constitution, so doesn't the right to free speech over-ride the "right" not to be defamed?
Sigh.
The ability to sue for libel, slander and general defamation does not infringe the right to free speech, because it does not restrict speech. It just does what most civil law is intended to do: hold people accountable for harm they cause.
To see an example, suppose you're a programmer looking for a job, and a company is about to hire you. But then someone at the company reads a post I've written about you on the Internet where I make (false) claims that you don't know anything about programming, that you were incompetent and cost my company lots of money, etc., and as a result they decide not to hire you. My post has caused actual harm to you (loss of a job opportunity), and you could bring a lawsuit against me to recover damages. Not a lawsuit forbidding me to write things, or forbidding me to say what's on my mind, but simply to compensate you for the harm my words caused. This is really no different from, say, being forced to pay to replace a window if I throw a rock through it.
And that distinction -- between regulating the act of speech, and holding people accountable for the consequences of the action -- is what makes all the Constitutional difference (a law forbidding you to speak would be unconstitutional -- the term is "prior restraint"). In other words, it's the difference between saying, before the fact, "you aren't allowed to do that" and saying, after the fact, "you must make amends for what you did". The former, when speech is involved, is called prior restraint and there are very few cases in which it's allowed. The latter is simply called a civil suit, and is as common as weeds.
Since this ended up turning into yet another Python versus Ruby thread on Slashdot, I'll pick on Python as an example.
From Python 2.0 up until (but not including) Python 3.0, Python had an abstract basestring class, from which were descended two classes of things which were used as "strings": str represented sequences of bytes in some particular encoding (the particular encoding was up to you, and you could have str instances of different encodings coexisting within the same file), and unicode represented, well, Unicode strings. This turns out to be a bit troublesome in practice, since it means you have to be very careful about mixing different types of strings, or even differently-encoded str instances, in order to avoid encoding errors.
As of Python 3.0, there's only one string type, the equivalent of what used to be the unicode type. This means that if something's a string, it's always the same type of string, always Unicode, always comparable to other strings, can always be combined with other strings, etc. To meet the need for sequences of bytes in various encodings, a new type -- bytes -- was introduced, and has slightly different syntax and different semantics from the old str type in Python 2.x. Most importantly, any attempt to mix these two types in Python 3.0 automatically raises a TypeError (where previously, such attempts would sometimes work and sometimes fail with various encoding-related errors); you must either explicitly call the encode method of a string to get a byte sequence, or explicitly call the decode method of a byte sequence to get a string (bytes objects know what encoding they're in, and so can do this cleanly) before doing any sort of comparison or other operations between a string and a byte sequence.
The biggest objection that's been raised is how to work with filesystems where file names may not be valid Unicode, and to compensate Python's I/O APIs will accept bytes objects as arguments when you need them to, but some functions will not be able to represent some file names. Personally I've never run into a situation where this is problematic, though, since usually if there's no way to convert a file name to a valid sequence of Unicode you'll have larger problems with the file than just whether you can see it from Python's os.listdir() function.
Actually, Python's OO was pretty much "just bolted on", but that happened several iterations of the language ago. Somewhere before 1.4. Possibly before 1.0.
No, the OO has been there from day one; Python 0.9.0, the first public release, was an object-oriented language.
What you may be getting at is the fact that originally Python had two type hierarchies, similar to the way.NET and Java still distinguish between "primitive" types ("value types" on.NET IIRC), which include things like numbers, and everything else; hence on those platforms some types have to be explicitly or implicitly wrapped ("boxed") in objects for certain use cases. This doesn't change the OO tenor of the language, really (the biggest stumbling block was simply that the primitives couldn't be subclassed directly, so workarounds were provided to allow user-defined classes with the correct behavior), and the unification of those two hierarchies started a long time ago; everything you'll interact with in Python today is derived from the base object, which is one definition of OO (but, importantly, not the only such definition). A few years ago I heard Guido describe it by saying that in Python, everything is an object but not everything is necessarily an instance of a class (something that's actually been changed now, since everything derives from object these days), which is fine by me.
So maybe it comes down to someone's personal definition of "object oriented", which is of course possible given how many definitions of the term there are, but for general statements about types of languages I don't see any reason to say Python isn't or wasn't "object oriented" (unless your personal definition is one of the extreme ones which basically only admits Smalltalk, in which case that's your problem and not Python's).
Meanwhile I think I've shown pretty clearly that Python is thoroughly object-oriented and that the OO is so deeply embedded in the language that claims of being "bolted on" just don't hold up.
Then again, your complete post is content-free except for some handwaving about "deep knowledge" and "cursory familiarity".
...snip...
The fact that method calls (assert, print and del) are included in the language syntax, means that Python is not (yet) fully OO.
Well, actually understanding what's going on does require a bit of knowledge of the way the languages work, but my point was that it's irresponsible to go from an assertion like "up until Python 3.0 print was a statement" to "Python isn't really object-oriented" or "Python's OO is just bolted on", because even a basic understanding of how Python works shows that to be false. Let's consider an easy example, a simple function which adds two numbers (Slashdot's comment system will eat the indentation of the function body, but that's neither here nor there):
def add(x, y): return x + y
You might call this function by writing add(2, 3), which would return 5. That turns into a method invocation, delegating to the __call__ method of the function, which is an object: add.__call__(2, 3). And that, in turn, expands into an invocation of the __call__ method of the class of the function object, with the function object passed as the first argument to get the self reference, and the rest of the arguments following: types.FunctionType.__call__(add, 2, 3) (all functions in Python are instances of FunctionType, which is accessible through the types module if you ever have a need to do things manually without resorting to Python's function-definition syntax).
From just this simple example it's clear that the object-orientation really does go all the way down, and that the existence of the print statement in older Pythons was a "bolted-on" wart of an OO language rather than being the other way around. The same is true for the other "special" statements in Python; these are not vestigial remnants of some non-OO language which got an object system tacked on, they are bits which were added on to an OO language for pragmatic reasons (print was turned into a function in Python 3.0, but assert and del, remain as special cases).
This also reveals a few interesting points of Python/Ruby comparison:
Just as many things which appear to be "standalone" functions in Ruby are actually methods on Kernel, which is implicitly available everywhere, many things which appear to be "standalone" functions in Python are actually members of various modules (and are exposed at the toplevel through Python's implicit __builtins__ module, which also provides a handy way to access the original objects if they're being shadowed by something user-defined; if a name is not found in local scope, any enclosing scope or global scope, __builtins__ is the last place Python will check before raising a NameError).
But, Python's style of OO is different than Ruby's; Ruby has a message-passing OO system, where there really are no "method calls", just objects which respond to messages of particular names (the syntax hides this somewhat, but if you poke at it you'll see this is how Ruby does it), while Python has a method-invoking OO system. This is why Python requires parentheses for function and method calls: the parentheses are the syntax which invokes the __call__ method of a callable object, just as, for example, "/" is the syntax which invokes the __div__ method of a (numeric, or number-emulating) object. In this sense the parentheses can be thought of as an operator of slightly higher-than-normal complexity (they are not actually an operator in the sense of being recognized as such by Python's lexical analyzer, however, because parentheses are used for other purposes depending on context).
So far, Ruby 1.9/2.0 is the only high-level language I know of which allows strings within the same program to be in different encodings
Perhaps you need to spend time trying more languages; you'd learn not only that other languages have done this, but that many of them later rejected the idea and moved to, typically, a pure Unicode string type with a separate non-string type for working with sequences of bytes in particular encodings.
The difference is that Ruby is OOP from the start and through and through, while Python get stuff patched in a little bit at a time with every new version. See Pythons print-statement vs Ruby puts for example.
You really need to work on your form; this is at best a 2 out of 10 on the Ruby/Python trolling scale. Generally, you want to pick something that's subtly false, or which requires deep knowledge of the topic to expose the problem with the assertion, not something which is known to be false by folks who have even cursory familiarity with the subject.
I would really dearly love to see a lot of tech companies start refusing to ship products to east Texas, and start refusing to do distribution deals to stores there. Take every single useful gadget off their market with an industry boycott, and tell 'em that they can have their shiny gizmos back when they stop producing ludicrous patent decisions.
I actually work tech at a big media organization, so this is something I think about constantly, and the article is a perfect example of the media missing the goddamn point.
I actually work tech at a small media corporation, and getting the rest of the industry to wake up is something we've been trying to do for years now. I'm employed by the company which (among other things), publishes the Lawrence Journal-World, of Lawrence, Kansas. Most folks, if they know who we are at all, know us as the original home of the Django web framework, but Django came out of our need to quickly put together custom applications for our online presence, something we've historically done as well as or better than anybody else in the industry.
An example:
Lawrence is home to the University of Kansas; last year, one of our reporters got his hands on a set of documents listing every crime report on the campus for the period 2005-2007. He got these documents (Word docs with embedded tables of the reports) on Wednesday. On Friday I had a demo of a browsable database of the reports ready to go; our UI guys put some polish on it, and we ran it online alongside a story looking into trends and interesting bits we picked up from the data (if you're interested, I gave a lightning talk at PyCon last year which covered, in whirlwind fashion, how it was put together. So far we don't have data for 2008, but I'd love to go back and add it, and see a followup story).
People really seem to like this stuff and find it useful (and our former lead developer is recognized as having more or less invented what's now called "database-driven journalism"; these days he's turning out even more interesting uses for online data). Unfortunately, the industry as a whole is stubbornly stuck with the mindset that the printed paper is and always should be their "main product", and most folks are burdened with tech solutions that are far too cumbersome to be put to these sorts of uses.
Anyway, my point is that not all of the stuff going on these days is "Web 2.0 widgets"; there are plenty of us who, when given the chance, are trying to help journalists save themselves from extinction by bringing tech into the newsroom in actually useful and interesting ways.
Apple didn't force a non-standard container for MP4 files on anyone.
And I never said they did. It's just that if you're looking at an MP4 container coming out of the iTunes store, figuring out why a given bit is in it can be an interesting trip into historical Apple stuff (IIRC the iTunes metadata boxes actually live in a sub-branch of a hierarchy from the pre-MP4 QuickTime days, for example).
Since this watermark must be fairly easy to modify
It's not a watermark. People need to learn the difference between a piece of actual media (e.g., a track of music) and the container it comes in; the actual music is not carrying any of this metadata, but the container (which is designed to hold arbitrary bits of whatever in addition to the media bits) is. There's also plenty of freely-available software for editing the contents of MPEG-4 containers (which are what iTunes uses -- the file you get is an AAC audio track and some metadata bundled together inside an MPEG-4 container).
(and in case anyone wants to get pedantic on me: yes, I know that the difference between "standard" and "custom" metadata fields is a bit muddled when it comes to Apple, since much of the MPEG-4 container format was lifted straight from QuickTime, and so things Apple was already doing became part of the "standard". AFAIK, though, the purchase-ID stuff falls on what would normally be called the "custom" side)
If some form of steganography is used to alter a file, then somewhere and in some way the quality of that file will be compromised. Bitmaps lose sharpness, audio files lose certain audio data.
Except this isn't "steganography" and doesn't degrade the file. The actual "file" you get from iTunes is an AAC audio track inside an MPEG-4 container, and the MPEG-4 container format, in turn, provides a way to embed both standard metadata (e.g., things like artist/genre/running time, etc.) and to create and use custom metadata fields (IIRC, the spec calls them "boxes"). The iTunes purchase info is an example of the latter.
Martin Gardner's essay "Wilhelm Reich and the Orgone" is highly recommended reading on the topic (as is, well, pretty much anything he writes debunking pseudoscience).
However, I think you missed an important aspect of your own "jump ship of their own accord" argument: the fact that people using more recent third-party 2.6+ python modules will also have to start considering whether django itself is keeping up with their needs.
Django runs on Python 2.6 (as well as Python 2.5, Python 2.4 and Python 2.3, and equivalent non-C implementations like Jython and IronPython). It will run on Python 2.7 when that lands. So if you've got a library that currently only works on 2.6, you can use it with Django right now.
For me, this is the main concern. I've been waiting on decent unicode support, amongst other things, in python for years. Now that it's finally here and stable, I really hate the idea of having to keep coding to the older apis for the sake of django etc. If my projects can target 2.6/3.x, and django is the only thing holding it back from that, then I'm quite likely to abandon django for those projects. It'd be a shame, as django *is* the nicest web platform I've found for most things, and it has at least made the transition to __unicode__(). Still, when it comes to developing new code, it makes little sense to target platforms that are already behind the times.
Honestly, I think you're underestimating a couple of things:
The sheer size of the ecosystem of stuff that has to migrate before Python 3.0 will be useful to you.
The number of people who would be even more miffed than you if projects like Django just suddenly dropped everything lower than 2.6 and made a mad rush to get on 3.0 as quickly as they can port the code.
The simple fact is that most projects which are large/mature enough to be "nice" to use just aren't going to be running on 3.0 any time soon (IIRC, Plone -- to take a different example -- is talking about a four- or five-year migration timeline). Even if every library needed by every one of those projects magically ran perfectly on 3.0 tomorrow, the fact remains that any sizable project has a significant obligation to its existing users, the majority of whom are not stamping their feet and loudly demanding "Python 3.0 RIGHT NOW". And that means you can't drop support for, say, Python 2.3, 2.4 and 2.5 next month, unless you'd like to lose most of your user base; too many people still depend on things working with those versions of Python and can't upgrade that quickly no matter how impatient you might be.
Meanwhile, I think you're mischaracterizing projects which aren't yet on 3.0; it's not that they're "behind the times", it's that you seem to have misunderstood how Python 3.0 was planned from the beginning. Nobody in the Python world expected this to be a sudden overnight transition. It was always expected to be and always described by the Python team, from the start, as a process of at least a year or two while existing projects dropped their support for older Pythons, cleaned up their code, got onto 2.6 or 2.7 to start running parallel on 2.x/3.x, and then finally made the 3.x-only jump at the end.
In other words, if your approach to Python is that you won't use a particular piece of software unless it plans to be on 3.0 immediately, you may find yourself without any software you can use, because this is not Django going off on its own and saying "screw it, we'll be lazy". And Django isn't going to be "the only thing holding you back", not by a long shot, since this is the type of plan most major projects seem to be going with (and the type of plan that a lot of projects been putting together for quite some time now, based on upstream recommendations to do it this way).
When you learn what estoppel means, you will know why that is extremely unlikely to happen.
I assume what you actually mean is "laches", not "estoppel" (since laches is the specific type of estoppel asserted in, e.g., patent-infringement defenses), but it seems you've failed to note that a successful laches defense leaves open the possibility that future infringement will be barred and/or subject to damages even though damages or injunctions for past infringement are not awarded.
(of course, IANAL, but I've spent more time than is good for me studying IP law)
Since both the Django and python communities are very active, I suspect this will be remedied soon. I cannot wait.
You might end up in trouble, then; as explained by the FAQ, it'll be a while before Django officially supports Python 3.0.
Remember: even the Python developers themselves are talking about a migration timeline of years, rather than a simple "next version of every library will be on Python 3" (which just isn't possible with any kind of responsible release process). See this summary I posted on django-developers for some more information.
No, these days it'd have to work in something about the software being rejected from the iPhone application store by Apple to hit the real Slashdot-buzzword bingo.
Gruber will come up with a justification even if Steve Jobs urinates in his face and shits on his head.
Hmm... this would be the same Gruber who wrote that the App Store's exclusion of applications which "compete with" Apple's own offerings is "seriously wrong"? The one who said (same link) that "[i]f this is truly Apple's policy, it's a disaster for the platform"? The same Gruber who said, of Apple's policies, "they shouldn't be doing this"? The same Gruber who said of Apple's inscrutable rejections of applications which violate no SDK guidelines that "[r]ules you disagree with are frustrating. Rules you don't know about are scary"?
Yes, and they appear to be rather arbitrary in what apps they decide to disallow. This would be less of a problem if Apple were less capricious about it.
Not in this case, actually; the developer agreement for the iPhone includes language forbidding the development of, for example, general-purpose language interpreters. But Opera's mobile browser is written in Java, and so to run on the iPhone they'd have to port a general-purpose Java VM, or at least a minimal Java environment, to the iPhone, and that runs afoul of the developer agreement.
So in this instance the use of "with glowing hearts" in relation to the olympics.
Not quite. The IOC is not happy with merely controlling use of what they perceive to be their trademarks in relation to the Olympics; they actually seek to control any use, for any reason. For example, the role-playing/card game(s) "Legend of the Five Rings", which takes its name from a Japanese book on dueling published long before the IOC ever existed, was forced to change its visual-identity branding -- even though it had not one single thing to do with the Olympics -- because that branding included five interlocked circles, something over which the IOC claims control in any form and in any context.
Slashdot Mirror
Well, saying that this is "DRM", based on what's known at the moment (not based on what's speculated by outlets which stand to benefit from the traffic such a story would bring them), would begin to dilute the term into meaninglessness. One might as well say that a car has "DRM" because you have to buy gas to keep the engine running...
You might want to read a couple of Iain M. Banks' Culture novels.
The premise of the Culture is your basic lax post-scarcity society -- people can have whatever they want, do whatever they want, etc. -- but then it confronts the question of what such a society's long-term goals would be, and what happens to people who aren't content to spend their entire lives getting high and going to parties (solution: they go out and mess around with less-technologically-advanced societies to try to steer their development into something resembling the Culture, providing the basis for most of the books' plots). A good introduction (since it's relatively self-contained and lets you pick stuff up as you go), if you're interested, is The Player of Games. Then if you like it, move on to, say, Use of Weapons or Excession.
You seem to be hung up on a misunderstanding: rape is a crime, and is handled by a criminal process whereby a government official prosecutes you and, if convicted, you receive a sentence from the government as punishment. Defamation (which includes libel, slander, etc.), on the other hand (in this type of case, and in the US), is not a crime. The government does not prosecute people for it, and does not punish people for it. It's a tort, and is handled by a civil process; effectively, the government-run court acts as a sort of mediator/enforcer in a disagreement between individuals or corporations. A tort (the word comes to us from the French for "wrong") is something you shouldn't have done (whether deliberately or accidentally) and which caused some actual harm to a person or actual damage to someone's property (although, importantly, not a breach of contract -- that's handled by a separate area of law), and the result of a successful lawsuit over a tort is payment of damages or some other form of restitution.
Which brings me back once again to the key difference: defamation laws do not restrict or prevent or outlaw any type of speech. They simply provide people with a way to be compensated for harm done to them.
In the case of defamation, generally it is asserted that a person's reputation has been harmed by a particular statement, and the standard of proof for the harm varies with the type of statement. Some statements -- for example, false assertions that someone has committed a serious crime -- are (in most US states) automatically considered harmful enough to be defamation, but other statements require a description of the alleged harm and proof that the harm actually occurred as a result of the statement. Also, (again, in the US) a defamation suit must generally prove that the statements either were made with intent to cause harm, or were made with negligent disregard for their truth (this provision and several others in US defamation law, by the way, exist precisely because of the First Amendment, in order to prevent defamation suits from having an improperly chilling effect on the genuine expression of opinion).
So this isn't really a candidate for a slippery slope argument; the body of law around defamation is literally thousands of years old, and has been refined and clarified over that time to ensure that it's fair and equitable to both sides, with a history of court rulings balancing the need to redress harm against the need to protect free speech. Unfortunately, it's just not something the average person ever really learns about...
Sigh.
The ability to sue for libel, slander and general defamation does not infringe the right to free speech, because it does not restrict speech. It just does what most civil law is intended to do: hold people accountable for harm they cause.
To see an example, suppose you're a programmer looking for a job, and a company is about to hire you. But then someone at the company reads a post I've written about you on the Internet where I make (false) claims that you don't know anything about programming, that you were incompetent and cost my company lots of money, etc., and as a result they decide not to hire you. My post has caused actual harm to you (loss of a job opportunity), and you could bring a lawsuit against me to recover damages. Not a lawsuit forbidding me to write things, or forbidding me to say what's on my mind, but simply to compensate you for the harm my words caused. This is really no different from, say, being forced to pay to replace a window if I throw a rock through it.
And that distinction -- between regulating the act of speech, and holding people accountable for the consequences of the action -- is what makes all the Constitutional difference (a law forbidding you to speak would be unconstitutional -- the term is "prior restraint"). In other words, it's the difference between saying, before the fact, "you aren't allowed to do that" and saying, after the fact, "you must make amends for what you did". The former, when speech is involved, is called prior restraint and there are very few cases in which it's allowed. The latter is simply called a civil suit, and is as common as weeds.
Ah, so now you want to violate the "no original research" policy?
Since this ended up turning into yet another Python versus Ruby thread on Slashdot, I'll pick on Python as an example.
From Python 2.0 up until (but not including) Python 3.0, Python had an abstract basestring class, from which were descended two classes of things which were used as "strings": str represented sequences of bytes in some particular encoding (the particular encoding was up to you, and you could have str instances of different encodings coexisting within the same file), and unicode represented, well, Unicode strings. This turns out to be a bit troublesome in practice, since it means you have to be very careful about mixing different types of strings, or even differently-encoded str instances, in order to avoid encoding errors.
As of Python 3.0, there's only one string type, the equivalent of what used to be the unicode type. This means that if something's a string, it's always the same type of string, always Unicode, always comparable to other strings, can always be combined with other strings, etc. To meet the need for sequences of bytes in various encodings, a new type -- bytes -- was introduced, and has slightly different syntax and different semantics from the old str type in Python 2.x. Most importantly, any attempt to mix these two types in Python 3.0 automatically raises a TypeError (where previously, such attempts would sometimes work and sometimes fail with various encoding-related errors); you must either explicitly call the encode method of a string to get a byte sequence, or explicitly call the decode method of a byte sequence to get a string (bytes objects know what encoding they're in, and so can do this cleanly) before doing any sort of comparison or other operations between a string and a byte sequence.
The biggest objection that's been raised is how to work with filesystems where file names may not be valid Unicode, and to compensate Python's I/O APIs will accept bytes objects as arguments when you need them to, but some functions will not be able to represent some file names. Personally I've never run into a situation where this is problematic, though, since usually if there's no way to convert a file name to a valid sequence of Unicode you'll have larger problems with the file than just whether you can see it from Python's os.listdir() function.
No, the OO has been there from day one; Python 0.9.0, the first public release, was an object-oriented language.
What you may be getting at is the fact that originally Python had two type hierarchies, similar to the way .NET and Java still distinguish between "primitive" types ("value types" on .NET IIRC), which include things like numbers, and everything else; hence on those platforms some types have to be explicitly or implicitly wrapped ("boxed") in objects for certain use cases. This doesn't change the OO tenor of the language, really (the biggest stumbling block was simply that the primitives couldn't be subclassed directly, so workarounds were provided to allow user-defined classes with the correct behavior), and the unification of those two hierarchies started a long time ago; everything you'll interact with in Python today is derived from the base object, which is one definition of OO (but, importantly, not the only such definition). A few years ago I heard Guido describe it by saying that in Python, everything is an object but not everything is necessarily an instance of a class (something that's actually been changed now, since everything derives from object these days), which is fine by me.
So maybe it comes down to someone's personal definition of "object oriented", which is of course possible given how many definitions of the term there are, but for general statements about types of languages I don't see any reason to say Python isn't or wasn't "object oriented" (unless your personal definition is one of the extreme ones which basically only admits Smalltalk, in which case that's your problem and not Python's).
Meanwhile I think I've shown pretty clearly that Python is thoroughly object-oriented and that the OO is so deeply embedded in the language that claims of being "bolted on" just don't hold up.
...snip...
Well, actually understanding what's going on does require a bit of knowledge of the way the languages work, but my point was that it's irresponsible to go from an assertion like "up until Python 3.0 print was a statement" to "Python isn't really object-oriented" or "Python's OO is just bolted on", because even a basic understanding of how Python works shows that to be false. Let's consider an easy example, a simple function which adds two numbers (Slashdot's comment system will eat the indentation of the function body, but that's neither here nor there):
You might call this function by writing add(2, 3), which would return 5. That turns into a method invocation, delegating to the __call__ method of the function, which is an object: add.__call__(2, 3). And that, in turn, expands into an invocation of the __call__ method of the class of the function object, with the function object passed as the first argument to get the self reference, and the rest of the arguments following: types.FunctionType.__call__(add, 2, 3) (all functions in Python are instances of FunctionType, which is accessible through the types module if you ever have a need to do things manually without resorting to Python's function-definition syntax).
From just this simple example it's clear that the object-orientation really does go all the way down, and that the existence of the print statement in older Pythons was a "bolted-on" wart of an OO language rather than being the other way around. The same is true for the other "special" statements in Python; these are not vestigial remnants of some non-OO language which got an object system tacked on, they are bits which were added on to an OO language for pragmatic reasons (print was turned into a function in Python 3.0, but assert and del, remain as special cases).
This also reveals a few interesting points of Python/Ruby comparison:
Perhaps you need to spend time trying more languages; you'd learn not only that other languages have done this, but that many of them later rejected the idea and moved to, typically, a pure Unicode string type with a separate non-string type for working with sequences of bytes in particular encodings.
You really need to work on your form; this is at best a 2 out of 10 on the Ruby/Python trolling scale. Generally, you want to pick something that's subtly false, or which requires deep knowledge of the topic to expose the problem with the assertion, not something which is known to be false by folks who have even cursory familiarity with the subject.
I would really dearly love to see a lot of tech companies start refusing to ship products to east Texas, and start refusing to do distribution deals to stores there. Take every single useful gadget off their market with an industry boycott, and tell 'em that they can have their shiny gizmos back when they stop producing ludicrous patent decisions.
Amazon and other places will sell them to you. iTunes only sells AAC-in-MP4.
I actually work tech at a small media corporation, and getting the rest of the industry to wake up is something we've been trying to do for years now. I'm employed by the company which (among other things), publishes the Lawrence Journal-World, of Lawrence, Kansas. Most folks, if they know who we are at all, know us as the original home of the Django web framework, but Django came out of our need to quickly put together custom applications for our online presence, something we've historically done as well as or better than anybody else in the industry.
An example:
Lawrence is home to the University of Kansas; last year, one of our reporters got his hands on a set of documents listing every crime report on the campus for the period 2005-2007. He got these documents (Word docs with embedded tables of the reports) on Wednesday. On Friday I had a demo of a browsable database of the reports ready to go; our UI guys put some polish on it, and we ran it online alongside a story looking into trends and interesting bits we picked up from the data (if you're interested, I gave a lightning talk at PyCon last year which covered, in whirlwind fashion, how it was put together. So far we don't have data for 2008, but I'd love to go back and add it, and see a followup story).
We do that kind of thing all the time, and it's neither burdensome nor useless (and we have a bookcase full of shiny things given to us by industry award groups -- two examples I can pull off the top of my head were for this feature on the demise and aftereffects of mining in southeastern Kansas, and our retrospective on the KU basketball team's championship season last year).
People really seem to like this stuff and find it useful (and our former lead developer is recognized as having more or less invented what's now called "database-driven journalism"; these days he's turning out even more interesting uses for online data). Unfortunately, the industry as a whole is stubbornly stuck with the mindset that the printed paper is and always should be their "main product", and most folks are burdened with tech solutions that are far too cumbersome to be put to these sorts of uses.
Anyway, my point is that not all of the stuff going on these days is "Web 2.0 widgets"; there are plenty of us who, when given the chance, are trying to help journalists save themselves from extinction by bringing tech into the newsroom in actually useful and interesting ways.
And I never said they did. It's just that if you're looking at an MP4 container coming out of the iTunes store, figuring out why a given bit is in it can be an interesting trip into historical Apple stuff (IIRC the iTunes metadata boxes actually live in a sub-branch of a hierarchy from the pre-MP4 QuickTime days, for example).
It's not a watermark. People need to learn the difference between a piece of actual media (e.g., a track of music) and the container it comes in; the actual music is not carrying any of this metadata, but the container (which is designed to hold arbitrary bits of whatever in addition to the media bits) is. There's also plenty of freely-available software for editing the contents of MPEG-4 containers (which are what iTunes uses -- the file you get is an AAC audio track and some metadata bundled together inside an MPEG-4 container).
(and in case anyone wants to get pedantic on me: yes, I know that the difference between "standard" and "custom" metadata fields is a bit muddled when it comes to Apple, since much of the MPEG-4 container format was lifted straight from QuickTime, and so things Apple was already doing became part of the "standard". AFAIK, though, the purchase-ID stuff falls on what would normally be called the "custom" side)
Except this isn't "steganography" and doesn't degrade the file. The actual "file" you get from iTunes is an AAC audio track inside an MPEG-4 container, and the MPEG-4 container format, in turn, provides a way to embed both standard metadata (e.g., things like artist/genre/running time, etc.) and to create and use custom metadata fields (IIRC, the spec calls them "boxes"). The iTunes purchase info is an example of the latter.
Martin Gardner's essay "Wilhelm Reich and the Orgone" is highly recommended reading on the topic (as is, well, pretty much anything he writes debunking pseudoscience).
Django runs on Python 2.6 (as well as Python 2.5, Python 2.4 and Python 2.3, and equivalent non-C implementations like Jython and IronPython). It will run on Python 2.7 when that lands. So if you've got a library that currently only works on 2.6, you can use it with Django right now.
Honestly, I think you're underestimating a couple of things:
The simple fact is that most projects which are large/mature enough to be "nice" to use just aren't going to be running on 3.0 any time soon (IIRC, Plone -- to take a different example -- is talking about a four- or five-year migration timeline). Even if every library needed by every one of those projects magically ran perfectly on 3.0 tomorrow, the fact remains that any sizable project has a significant obligation to its existing users, the majority of whom are not stamping their feet and loudly demanding "Python 3.0 RIGHT NOW". And that means you can't drop support for, say, Python 2.3, 2.4 and 2.5 next month, unless you'd like to lose most of your user base; too many people still depend on things working with those versions of Python and can't upgrade that quickly no matter how impatient you might be.
Meanwhile, I think you're mischaracterizing projects which aren't yet on 3.0; it's not that they're "behind the times", it's that you seem to have misunderstood how Python 3.0 was planned from the beginning. Nobody in the Python world expected this to be a sudden overnight transition. It was always expected to be and always described by the Python team, from the start, as a process of at least a year or two while existing projects dropped their support for older Pythons, cleaned up their code, got onto 2.6 or 2.7 to start running parallel on 2.x/3.x, and then finally made the 3.x-only jump at the end.
In other words, if your approach to Python is that you won't use a particular piece of software unless it plans to be on 3.0 immediately, you may find yourself without any software you can use, because this is not Django going off on its own and saying "screw it, we'll be lazy". And Django isn't going to be "the only thing holding you back", not by a long shot, since this is the type of plan most major projects seem to be going with (and the type of plan that a lot of projects been putting together for quite some time now, based on upstream recommendations to do it this way).
I assume what you actually mean is "laches", not "estoppel" (since laches is the specific type of estoppel asserted in, e.g., patent-infringement defenses), but it seems you've failed to note that a successful laches defense leaves open the possibility that future infringement will be barred and/or subject to damages even though damages or injunctions for past infringement are not awarded.
(of course, IANAL, but I've spent more time than is good for me studying IP law)
You might end up in trouble, then; as explained by the FAQ, it'll be a while before Django officially supports Python 3.0.
Remember: even the Python developers themselves are talking about a migration timeline of years, rather than a simple "next version of every library will be on Python 3" (which just isn't possible with any kind of responsible release process). See this summary I posted on django-developers for some more information.
No, these days it'd have to work in something about the software being rejected from the iPhone application store by Apple to hit the real Slashdot-buzzword bingo.
Hmm... this would be the same Gruber who wrote that the App Store's exclusion of applications which "compete with" Apple's own offerings is "seriously wrong"? The one who said (same link) that "[i]f this is truly Apple's policy, it's a disaster for the platform"? The same Gruber who said, of Apple's policies, "they shouldn't be doing this"? The same Gruber who said of Apple's inscrutable rejections of applications which violate no SDK guidelines that "[r]ules you disagree with are frustrating. Rules you don't know about are scary"?
Is that the Gruber you're talking about here?
Not in this case, actually; the developer agreement for the iPhone includes language forbidding the development of, for example, general-purpose language interpreters. But Opera's mobile browser is written in Java, and so to run on the iPhone they'd have to port a general-purpose Java VM, or at least a minimal Java environment, to the iPhone, and that runs afoul of the developer agreement.
Not quite. The IOC is not happy with merely controlling use of what they perceive to be their trademarks in relation to the Olympics; they actually seek to control any use, for any reason. For example, the role-playing/card game(s) "Legend of the Five Rings", which takes its name from a Japanese book on dueling published long before the IOC ever existed, was forced to change its visual-identity branding -- even though it had not one single thing to do with the Olympics -- because that branding included five interlocked circles, something over which the IOC claims control in any form and in any context.