Not content with making fools of themselves, the folks over at Oracle are having another poke about Android being copyright theft of their Java. They’ve filed with the US Federal Circuit Appeals Court in an attempt to overturn their loss when Judge William H. Alsup of the US District Court ruled that Google was not infringing upon Oracle’s copyright of Java, mainly on the basis that APIs are not covered under copyright.

More specifically, copyright does not protect “names, titles, short phrases or expressions”, including, “catchwords, catchphrases, mottoes, slogans, or short advertising expressions.” Those are covered under trademark law, not copyright law, and it’s a whole different ballgame.

Also not protected by copyright law are, “listing of ingredients, as in recipes, labels, or formulas.” Which in software terms is the same thing as APIs.

So on these grounds, copyright does not cover APIs.

Hence Google hasn’t infringed Oracle’s copyrights by using the Java APIs in Android.

So ruled Judge Alsup.

The court of law set its standards for modern interpretation of aged laws not designed with software engineering in mind.  And frankly, pretty much everyone but Oracle agrees with this, gets it, and is perfectly content with it that way.

But losing once wasn’t enough for Oracle. They’re adamant that their misinterpretations of law are correct and so they’re appealing that decision.  Which, in theory, they have the right to do.

Of course having potentially billions of dollars at stake might have something to do with their pig-headedness.

But I’m starting to think it’s more of a mental deficiency, to be honest.  Here’s how Oracle’s appeal begins:

Ann Droid wants to publish a bestseller. So she sits down with an advance copy of Harry Potter and the Order of the Phoenix – the fifth book – and proceeds to transcribe. She verbatim copies all the chapter titles – from Chapter 1 (“Dudley Demented”) to Chapter 38 (“The Second War Begins”). She copies verbatim the topic sentences of each paragraph, starting from the first (highly descriptive) one and continuing, in order, to the last, simple one (“Harry nodded.”). She then paraphrases the rest of each paragraph. She rushes the competing version to press before the original under the title: Ann Droid’s Harry Potter 5.0. The knockoff flies off the shelves.

J.K. Rowling sues for copyright infringement. Ann’s defenses: “But I wrote most of the words from scratch. Besides, this was fair use, because I copied only the portions necessary to tap into the Harry Potter fan base.”

Obviously, the defenses would fail.

Defendant Google Inc. has copied a blockbuster literary work just as surely, and as improperly, as Ann Droid – and has offered the same defenses.

Clearly, the state of mind over at Oracle must be questioned if this is their idea of how to write a lawsuit.

The ironic thing is that Oracle’s cute little story of little miss Ann Droid in no way re-examines how APIs should be protected under copyright. It appears that Oracle seems to think that they’ve somehow made a point here, but it only goes to show just how much they’ve actually missed the point, in my opinion. Because essentially their little story of Ann Droid is exactly what anyone working with APIs would and has had to do, by definition. You could no more sue Libre Office for reverse-engineering Word document reading, or Foxit for PDF viewing, or Linux’s Samba and Wine for writing Windows API names and recipes for that matter.

Oracle’s whole short story of Ann Droid centers on writing a book, not on APIs.  And seems focused on confusing the laws of copyright, of trademark, and potentially even of patent depending on how you try to interpret what they’re saying and how it could possibly relate to software.

And, in fact, anti-competitive lawsuits have been filed against Microsoft for not documenting their Windows APIs more clearly. (Sometimes if at all.)  To intentionally block competitors from using APIs is not kosher.

So how Oracle can somehow think that they’re special and that their APIs are copyrightable is beyond anyone’s ability to comprehend.

But writing a short story about Ann Droid writing a Harry Potter knock-off is a whole new level of WTF?!  It’s childish.  It’s apples to oranges.  It’s ignorant.

Again, Oracle doesn’t seem to comprehend where one law ends and the next begins. They seem to think that trademark law and patent law are all a part of copyright law now, as if the three weren’t completely different things.

But then maybe it’s not gross incompetence / ignorance after all, so much as just desperation.  Surely they must know that without a shadow of a doubt they’d lose hands down in a patent law battle, and likewise in a trademark battle. Copyright is the only battleground left that they can even remotely try to claim, and that’s still the longest of long-shots as that is also a clear and obvious lose for them. But with potentially billions of dollars at stake, I guess Oracle figures that it’s worth the chance to play the part of complete and utter fools … just in case they somehow magically conjure up a courtroom equally as foolish. Which, let’s face it, just ain’t gonna happen, even if they try to invoke the magic of Harry Potter.

Frankly, I hope the appellate court slaps them down hard. These ridiculous antics of Oracle are demeaning to the whole judicial system and to software developers alike. But then with so much Java egg on their face already when it comes to security and patches lately, maybe Oracle figures that they’re already chock-full-o’-idiocy, so why not got that extra mile and become the laughing stock of everyone?

I can honestly see a future where no one uses Java anymore not because of security concerns, but because they simple no longer want to have anything to do with Oracle.

One of the lovely things about Python is that there are so many free libraries to choose from. But sometimes that’s a bad thing, because people love to reinvent the wheel, thinking that they can make it somehow rounder and more efficient. This of course results in a lot of dead code and modules that haven’t been updated since the Stone Age.

Recently at work I found myself looking at a new package to replace one really old dead one: PyXML. We’ve got a good chunk of code that reads and writes data to an XML file basically as a flat-file database for when we (or our customers) are not using PostgreSQL, Oracle, etc.

Normally that wouldn’t be such a big deal, except that we have one requirement: XPath.

There are an awful lot of good XML parsers out there in the world. CPython now even comes with one build in: ElementTree. …And cElementTree (the compiled version of ElementTree) which is the same API, just a whole lot faster – unless you’re using PyPy, which we’re not – but I digress.

The problem with ElementTree however is that it doesn’t fully support XPath. In fact, it barely does at all. It’d be nice if it did, but it doesn’t much, so there you are.

The following is a run-down of my research into a few other Python libraries that do fully support XPath XML coding standards. I wish I could release the benchmark code that my performance evaluations are based on, but the benchmark code is based on real use cases of proprietary code. Meaning that they also don’t necessarily represent the on-paper perfect-world performance of these libraries, but more useful real-world use-cases. These were run under CPython 2.7.3 on a Windows 7 64-bit Intel Xeon workstation.

PyXML: The Baseline

You’d think that PyXML, having last been updated in 2004, would be long dead. And it is. But if you don’t mind fixing some minor things in this all-Python XML library, it actually does still work. You just have to find-and-replace the two places where “as” is used as a variable name, since Python now protects keywords with a vengeance. Simple changing the name to “_as” is enough to fix the problem, and then you can continue to use the long-dead PyXML on Python 2.7.3. Since this is the library that our code used in the past for Python XPath XML support, it’s what I used as a baseline to compare other libraries to. We also used Python’s minidom with PyXML, which is not exactly known for speed…

FourThought 4Suite: 2X

This is another dead project, having last been updated in 2006 as far as I can tell. It’s written by the same company that wrote most of what is in PyXML. (According to Wikipedia, it’s also the same company that brought you PowerPoint?) Unfortunately their corporate website seems to be down, meaning that they’re likely just as dead as their 4 Suite package.  Fortunately the great thing about places like SourceForge, besides the whole open-source thing, is that they’re also a great repository for dead packages and code.

The advantage of 4Suite is that because it was written by the same people as PyXML, 4Suite can be used with minimal code changes. It contains the PyXML API with very few differences. It just adds a whole lot more. But the one big differences is that you don’t use Python’s minidom, you use 4Suite’s cDomlette. Cute. And yes, it’s compiled code. And at least on CPython, it runs faster. It’s a little more than twice as fast as PyXML.

libxml2: 2.5X

Finally, a living breathing project! Based on a Python wrapping of the Gnome XML parser written in C, libxml2 is a breath of fresh air. Err … sort of. There’s a nice object-oriented wrapper written in Python. Which would be good … if it were documented. But darned if I can find any API documentation. And since the libxml2 wrapper changes the API dramatically from the original C code that it came from, it takes a bit of figuring out to use. It’s also slow. Oh, sure, the two-and-a-half times the performance of PyXML seems great. It’s even better than 4Suite. Barely. But if you’ll read through the rest, you’ll see it’s not so impressive after all, and there’s actually a very useful alternative right under its nose.

libxml2.libxml2mod: 6X

Yes, that’s right, it’s still technically the same libxml2 module as above. But if you load the libxml2mod.pyd file directly and skip the object-oriented Pythonic wrapper, going straight to the literal Gnome libxml2 APIs, you’ll have a lot more programming work (as the API is a lot more effort to code to) with a much better performance of six times the speed of PyXML. And it fully supports XPath. Who could ask for more?

Well, I could, actually. I don’t know if it’s the distribution that I got, or if it’s just not fully wrapped, or what, but there were some pieces of the Gnome C-code’s API missing from the Python libxml2mod.pyd file. The largest omission to me was XPath’s compile operation was completely missing. Since this can be vital to improving performance of executing an evaluate query across multiple nodes, it makes the 6X speed improvement even more impressive, as I was forced to do things the slow way, without compile. Which can of course be done. But it just makes you wonder, because the Gnome library definitely has this API, so it’s a mystery why the libxml2.pyd file didn’t.

PyQt4: -2.5X

If you’re using Qt4 as your Python GUI, you might as well use the Qt4 XML parser … right?

Well, maybe not.

Now don’t get me wrong. I love Qt.

Or at least, I loved the Qt that Trolltech put out.

But ever since Nokia bought Qt, it’s gone downhill. Fast. And this is a perfect example, right here.

The Qt4 XML parser is the darndest most complicated pile of API I’ve ever run across. Oh, it’s highly flexible. In theory. And it fully supports XPath. … In theory.  (I certainly haven’t tested every last feature.) But darned if I didn’t run into all sorts of mess just trying to convert the benchmark code to using Qt4’s XML parser. It was even worse when a bug (I don’t know if it’s in Qt4 or PyQt4) prevented me from evaluating to a QString, like you’re supposed to be able to do. So simple property lookups required the full QXmlResulItems overkill where I resolve the first result item from my results class instance, get the model index from that item, then use the model pointer from the index with the index to resolve it into a string.  Instead of just getting the first string, like I’d wanted and like it should have been able to do.  And not only is the API a mess (a highly flexible mess, but still a mess all the same), but it’s also two and a half times slower than PyXML. I honestly didn’t even think that it would be possible to write an XML parser slower for CPython than a pure-Python implementation that uses a DOM no less. Surely the C++ compiled-code PyQt4 would have a much faster XML parser than PyXML, right?

Well, apparently not!  As my benchmarks showed.

It was slow. Really slow.

Three-legged horse at the racetrack slow!

So I would highly suggest, to anyone using Qt4, DO NOT USE QT4’s XML PARSER! It’s that bad. To code for, and in performance. Find yourself another library for your XML needs. Trust me, you’ll be much happier that way.

I can only hope now that Digia owns Qt that some of these horrendous trainwrecks that have plagued Qt4 can finally be sorted out over time. Not likely to be seen in Qt5 though, as that’s still Nokia’s aborted afterbirth. Digia probably won’t get things straightened out until Qt6. And goodness knows how many years away that could end up being!

It’s hard to believe that with these lovely landmines in Qt that I still love it.  But the thing is, as bad as some parts of Qt are, no one has ever come close to doing anything better as an all-around solution to platform independent computer programming.  I just wish the original integrity of Trolltech had even remotely carried on to Nokia.  I just hope that Digia can give back some of the polish that Qt once had.

ElementTree: 3X

So I know, I already said that ElementTree doesn’t really support XPath properly yet. I really wish that it did. It’d be nice if I could just use the libraries built into Python for everything, and a good XML parser seems like a no-brainer. But for whatever reason, XPath is not really a part of ElementTree. They have kind of added beginning support to XPath type evaluate strings into the ElementTree find/findall queries, but a full implementation of XPath it is not. It doesn’t even support the full XPath string standard there.

Still, at least for enough of our use case, I was able to code for ElementTree. Converting the code from a full on XPath PyXML implementation to ElementTree and its lame partial implementation of XPath-based queries wasn’t as much work as it could have been. It’s nowhere near as much work as, say, converting the code to PyQt4, or even to libxml2. Which was pleasantly surprising. It’s a nice simple API, so I can see why people love it.

And the performance? It’s about three times faster than PyXML, making it a fair improvement. For a pure-Python implementation it’s actually quite amazing to squeeze that much out. But then, there’s a reason people don’t use DOM anymore. But the real treat comes next.

cElementTree: 18X

And here we have a real winner! Also included in Python, it’s the same API as ElementTree, just a very well written compiled-code implementation wrapped for Python. The same code that ran my ElementTree port also ran cElementTree with only the library name changing. Exactly like it should.

And the results were astounding. The real-use-case benchmark of XML parsing was a whopping eighteen times faster than our old PyXML code. Ding-dong, the DOM is dead!

Of course the problem is, all of our existing code is written for DOM using PyXML, so it’ll take a while to convert all of that to cElementTree.

As a side note, if any PyPy enthusiasts want to know why CPython programmers can’t convert to PyPy just yet (maybe not ever) here’s the reason why. A well-wrapped compiled code library runs like a champ in CPython. As a result, a lot of us big data/number crunchers have lots of compiled code in our Python projects. And since PyPy only just barely even runs compiled code, slowing things down far worse in that than native Python code, this leaves a lot of us CPython folks out in the cold. If you want the serious data crunchers to switch to PyPy then you have to start taking that compiled code lag more seriously or else we’re never going to be able to join you in your fancy little JIT Python interpreter’s dance.

Conclusion

So if you’re a Python 2.7 programmer looking for the best XPath XML parser ever, well, if you’re staying true to XPath at least, I’d say go with libxml2.

However, if you can swing it (and you’ll need to really evaluate your code to determine this) you might be able to get away with the rather unfinished XPath implementation in cElementTree. In which case you won’t need to install any third-party package for XML parsing and you’ll get blinding performance out the asterisk. (And obviously, if you’re coming at a whole new XML parser, and you don’t need XPath at all, then go with cElementTree since it’s what everyone in Python land is using and it’s got great performance.)

Hopefully the all-Python ElementTree runs just as great on PyPy, giving the world a pretty well rounded solution.

If any ElementTree authors catch this, hey, could you please work on supporting XPath a little more seriously?

And finally, dear god of all things software, whatever you do, avoid Qt4’s XML parser like the plague! Unfortunately I can’t speak to Qt5 yet as there’s still a lot of untested theory there that, professionally, we just don’t want to even approach mucking about with yet. Let things get a few more minor version numbers under the hood and then we can re-evaluate a PyQt5 upgrade path. (Or maybe even PySide.) But even if Qt’s XML parsing gets a major performance improvement, the API is still just as likely to suck wet donkey fur for being so “flexible”. Seriously, what committee designed that API? It’s everything that you could ever need … without being anything that you’d ever want! Yeesh!

So the super-secret Skunkworks Facebook project has finally been revealed in all of its glory … or lack thereof. No, it’s not a FacePhone. Or a PhoneBook. (Snicker.) Or any new gadget. It’s a search engine. Oh. Sorry, Zuckerberg. I mean it’s a “Graph Search”. The Mighty Zuck was clear to differentiate the Facebook Graph Search from any old search engine by pointing out that it doesn’t just search Ye Olde Interwebs, it searches Facebook.

Ooooooh.

Um … yeah. Whatever.

The point of Graph Search is that the results of your searches are tailored to your Facebook account. So if you search for vacation photos of Fiji, the photos taken by your friends and family are at the top, unlike any old internet search which relies upon the kindness of strangers. If you search for the best plumber, it knows where you live, and it goes by the recommendations of the people you Like over more generic information from world + dog. Allegedly making your search results that much more tailored to your needs, likes, etc.

Basically, like everything else in Facebook, it revolves around that creepy stalker feel to work its magic.  In fact you can even use Graph Search to find “friends of your friends who are single”.  No creepy vibes there!

Zuck obviously also considered privacy to be a big deal because apparently he wouldn’t shut up about privacy. Which, coming from All Things Facebook, is kind of ironic to say the least. Just because you say that you’re taking privacy seriously doesn’t make it true. And as privacy in Graph Search was explained further, this basically turned out as expected. As described, if it’s public on Facebook, it’s public to Facebook’s Graph Search. That’s it. Nothing particularly special, not even a new privacy feature to be found, and in fact highly confusing to so very many Facebook users who still aren’t always certain if they’ve managed to make something private or not even when they think that they have. Not to mention when policy changes, code changes, or bugs result in things turning up public when by any sane person’s judgment they shouldn’t be.  So take their claims of taking privacy seriously with a whole bag of salt … and then wait for the truck to drop off the rest.

Yes Zuck, we’re all laughing at you.

But, privacy, theoretically, is why Facebook’s Graph Search will be working closely with Microsoft’s Bing instead of Google’s search engine, because allegedly (not that I disbelieve this one) Google wouldn’t commit to removing information at the drop of a hat should something suddenly become private.  Nothing at all to do with Google, you know, that other major search engine, having launched a service that competes with Facebook.  Naw.  Not at all.  I’m sure Google+ had absolutely nothing to do with Facebook’s choice of Microsoft Bing as their search engine partner.

On a similarly dubious note of allegedness, Graph Search will one day be open to all with APIs. Probably. In theory.  So Facebook claims.  So in theory Google could snarf the data anyway. And still refuse to remove it whenever a swallow farts the wrong way.  In theory.

When exactly anyone will see Graph Search (let alone be able to use it) is anyone’s guess though. Facebook is doing a very limited roll-out as Graph Search isn’t even really at the beta testing stage yet. And what features will actually exist in Graph Search are also still rather up in the air. In fact, Facebook’s Graph Search announcement really seemed more vaporware than real software. But at least now we know what matters to Zuck and Co. So we can stop rumor-mongering that Facebook phone already.

And, of course, if you happen to not actually use Facebook, then Graph Search will be pretty meaningless to you. And, at least for now, even if you do happen to use Facebook, then Graph Search is also pretty meaningless to you. It’s still just a twinkle in Zuck’s eye. But maybe, one day, it’ll matter.

Or not.

Because even if you ever find it useful in theory, and actually get to use it one day in practice, there’s still the question of just exactly how relevant your “friends” are to your everyday life, and just how many Likes were actually liked when the analytics meet the fan. In order for Graph Search to deliver meaningful data, Facebook’s data has to actually be meaningful, something which at present is highly debatable. Otherwise Graph Search is all just rubbish in = rubbish out, and you’d actually be better off with results from a generic internet search after all.

But it’s not cool to be realistic, so, “Huzzah for Facebook’s Graph Search, Big Data, Analytics, and all other related buzzwords! Yay for Social Media, saviors of the Informatics world!”

Was that convincing enough?

Yeah. Sorry. I didn’t buy it either.

Or maybe it should have read more like, “Let anyone but you reap the bounty of monetizing all of your data!“  Was that more believable?

In fact, really, the whole Facebook Graph Search thing smells something of red herring, if not rotten fish entirely, as Facebook’s announcement of Graph Search comes awfully coincidentally right on the heels of IBM’s announcement of “Smarter Analytics”, crunching the Big Data of “social media” like … err … Facebook.  Huh.  Imagine that!  So IBM announces that it’s crunching data from Facebook, Twitter, etc. and suddenly Facebook announces a new vaporware alpha-tested (at best) service that is searching their own data … finally.  It’s almost like it was some kind of knee-jerk me-too response, no?

So maybe that FacePhone PhoneBook thing really is still possible after all.

Though I doubt it.

Even Zuck can’t be that dumb.  Who would buy a Facebook phone when every smartphone out there has a Facebook app?  That’d be right daft!

Still, the rumor mongers can rejoice in their theoretical fancies being potentially extended for just a little more time.

And if you happen to be one of the very few Facebook users alleged to have access to Graph Search already, then you too can stalk friends of your friends for a date!  Or ask your friends who they’d recommend as a plumber … without that awful hassle of just asking your friends who they’d recommend as a plumber.  That social media, gotta love it!  Now there’s even less social interaction to be had!  What a great feature Graph Search is.  Or will be.  Or whatever.  Since its really still vaporware at this point.

It’s something I’ve often joked about doing, but never actually had the moral bankruptcy to make it reality. But while I was poking fun at the idea, someone else actually took it seriously. The world weeps.

A recent security audit of an unnamed United States critical infrastructure company turned up a surprise: The Chinese hackers piggy-backing on the work-from-home VPN connection of their best programmer turned out to actually be secretly doing the work of said top programmer for him. While the unnamed programmer was pulling in six figures and earning “best in company” awards for his expertise in C, C++, Perl, Java, Ruby, PHP, and Python he was actually sitting on his duff watching cat videos and shopping on eBay while real computer programmers in Shenyang, China used his two-factor authentication token that he FedExed to them to write his code for him at one-fifth of his salary.

It actually gets worse yet as bilking one company was not enough for him, and further investigation into the Programmer Who Wasn’t revealed that he’d simultaneously contracted himself out to other firms as well, pulling the same stunt in each case, netting himself several hundred thousand dollars in profit over the course of his faked career.

Of course, once found out, the Self-Made Manager soon found himself unemployed. But still all the richer for it. In fact, there’s not even mention of if his awards were actually taken away or not. For all we know, he may still be the best employee that unnamed company ever had … on paper.

And if he’d just been a little smarter about routinurg his friends in China through his home PC instead of giving them direct access to the unnamed company’s VPN under his name and with his token, he may never have been caught. I guess it’s a good thing their top programmer (apparently) wasn’t so great with computers then.

Most unfortunately, for security reasons, the names have been withheld to protect the innocent guilty.

Okay, so here’s an update for you. In theory most of the Numeric to NumPy conversion using NumPy’s oldnumeric compatibility layer works just as detailed previously. There are however two exceptions / problems that I’ve found since then.

Problem 1 – Savespace

If you used Numeric array.savespace, you’re SoL. NumPy supports that like it supports returning the USA to British rule. Or in other words, not at all. Not even slightly. And if you ask why, you’ll no doubt catch all sorts of flak for even daring to ask, apparently. As if consuming half of the memory isn’t desirable when you don’t need the accuracy. And as if using graphics cards as GPGPUs isn’t catching on in exactly the kinds of fields you’d want a numerical library, where single precision FLOPs still greatly outperform double precision FLOPs to sickening proportions. So no, no reasons whatsoever for NumPy to support savespace whatsoever. (And yes, I am indeed rolling my eyes here.)

If you heavily used the savespace feature your spacesaver arrays are all upconverted to double now, regardless. Which might not matter to you, other than consuming vast amounts of memory.

Or … if you dared to ever typecheck (I know it’s not really a “Python thing” to typecheck, but sometimes needs must, especially if you dared to C++ Boost your Python library), it just might mean banging your head against a wall for who knows how many lines of code.

If you’re 1) insane and 2) a Python flexibility extremist, you can theoretically create a workaround for this problem, assuming you don’t mind performance penalties. By inheriting from the numpy.ndarray class you can create your own class that does support savespace and spacesaver properly. Which is a lot of work, frankly. Because every math operator needs an overwrite because spacesaver is like a virus, infecting any arrays it comes into contact with. And then all you’ve really done is just fixed the class. The extreme part comes next: You also rewrite every single function that creates an array (though really if you’re converting from Numeric to NumPy, you probably only need to do the ones that Numeric had, and only the arguments that Numeric supported) to return your class instead of a straight ndarray. Oh, and the fun Pythonic step, then replace the class and method pointers in oldnumeric with your fixed versions. Which if you do at the very beginning of your code (say, in your own module where you import numpy.oldnumeric) as long as you keep that modified version of oldnumeric in Python’s memory, Python will “cheat” by loading that one instead of reloading the module, so your fix will affect all of your application. Or you could just fix the oldnumeric import in the NumPy side. Or, if you were especially daring, you could fix NumPy itself to add back this feature that just about anyone, except for the NumPy authors, seems to comprehend having value not just in the past, but also forward-looking towards the days when you CUDA had a V8.

Problem 2 – Contiguous

Here’s another one that’ll catch you by surprise, but probably only matter if you foolishly wrote compiled code such as in C++ with Boost to speed up your Python. For some reason there seems to be a bug in NumPy ndarray where even though array data should be contiguous … it just sometimes isn’t. So if you actually check for that / require that in your compiled code, you just might be surprised at failures that by all reasoning shouldn’t be failing that particular check.

Of course there is a nice easy way to work with non-contiguous array data using PyArray_ContiguousFromObject. It’s pretty simple, but does require cleaning up your new Python object with Py_DECREF if you want to prevent memory leaks. Which could mean restructuring your whole method, depending on if you used return to exit before the end of the function. On the plus side though, if your array is contiguous (which if you’re running into this bug, it should have been in the first place) then there’s only an almost negligible performance hit as PyArray_ContiguousFromObject won’t actually copy your data into a new array. Of course if you did run into this bug, then you’re right, you’re going to somewhere hit the performance penalty as this approach copies your array data. But hey, at least it’ll still run. Whereas not doing this workaround could leave you in all sorts of trouble if your NumPy ndarray data isn’t contiguous when it should have been.

So in conclusion … WTF?!?!?!

Can you upgrade your Python code from Numeric to NumPy easily? Err … maybe. Hopefully? Kind of. It all depends on just what features of Numeric you used, because NumPy (and with it oldnumeric) clearly does not encapsulate 100% of Numeric. In the end, you might just find that rewriting a million lines of mixed Python and C++ code to use straight NumPy is about as much work as trying to cheat by using NumPy’s rather sorely incompatible oldnumeric. Why oldnumeric wasn’t written to be a lot more compatible to Numeric is beyond me. You’d expect that kind of incompatibility with straight NumPy, but not from a layer that’s sole purpose is to offer you backward compatibility. What was even the point?

Still, someone who didn’t use Numeric to extremes might find NumPy’s oldnumeric an easy solution. Maybe. I guess. Though I can’t imagine why you’d have been using Numeric in the first place instead of straight-up Python arrays … err … lists and tuples … if that’s the case.