On Nov 25, 11:17 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > This is all that is bad about Python in one problem: poor > > documentation, awkward package management, and backwards compatibility > > issues. It's almost enough to make me glad I use C++ at work. > > Since when is C++ the holy grail of backwards compatibility?
It's not, which is why I was being a little sarcastic. Still, it's better in this case. With a decent interface it's common for a library (dynamic or static) to remain usable across multiple revisions of a compiler and C runtime, by simply choosing not to pass complex structs across the boundary. Since nobody is changing the size of basic data types on you, things can be consistent. And at worst, even if you do end up recompiling the library, at least you didn't have to fire up a compiler for a separate programming language to do so. That's the major problem I have with this; to use a recent version Python effectively you need to have a complete C build environment set up. All because nobody bothered to set out a decent backwards compatibility system. > A minor version change is a sign for binary breakage. It's not python's > fault if 3rd-party-packages aren't up-to-date less than 2 months after > the release. Actually, it is largely Python's fault. Its interface is incredibly brittle, passing structs across the extension boundary which can vary subtly from release to release, compiler to compiler, platform to platform, when a little care could avoid this. Because it's implemented in terms of C structs and awful macros combining blind casts and unchecked dereferencing, any change to the internals of an object tends to break compatibility, usually in a catastrophic and uncontrolled way, even though the object functions identically in all other ways as before. This is pretty much the definition of a poor interface, unnecessarily burdening you with the costs of implementation details. There are several ways this could be handled better, if anybody actually cared enough to not force everybody to rebuild every extension each time there's an upgrade. One way would be to maintain explicit versioning for objects, keeping the quick-and-dirty conversions where the versions match and using slower conversion functions in other cases. This should be trivial, typically extracting the raw value from one type via Py_2_5_Whatever_AsWhatever and feed that into the relevant Py_2_6_Whatever_FromWhatever, raising exceptions where needed. How many low-level objects in any Python 2.x version could not be trivially coerced into their latest equivalent in such a manner? My guess is that you can count the exceptional cases on one hand. Another way would have been to remove all the direct variable accesses and use accessor functions which can be looked up at extension loading time, similar to how OpenGL does it. If a function is missing, raise an exception. Hardly the best performing option, but you only do it once per program execution, and if it's good enough for OpenGL I expect it's good enough for Python. Or provide a 'safe and slow' interface for those whose extensions don't need every bit of speed, using pickle-like semantics to pass your data, which is already guaranteed to be backwards compatible across releases. Hell, even just reserving a little empty space in each struct for future expansion could probably have prevented most breakages so far, given that it just looks like an extra int added here or there. This wouldn't help where people choose to pass things like FILE* around, but there could be a special case fix for that too. Any of these would be a small price to pay for avoiding the breakage that comes along every 18 months or so. At some point we have to wean ourselves off the ancient Unix philosophy of expecting every user to have a working C compiler to get anything done. > And I guess there is a reason for you chosing 2.6 - how do you expect > progress to happen *without* changes? I just expect people to be a bit more thoughtful about how to manage change. -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
