0

Did somebody already implement an open source bridge to make python programs work with PyTables 2.3.1 and PyTables 3.0.0 at the same time?

Although PyTables promises to work with the old API until 3.1.0, I encountered some glitches. For example, createArray takes a keyword argument object, whereas the new create_array relies on obj instead. So calling createArray with the object argument (using PyTables 3.0.0) is automatically translated to create_array(object=...) which fails with a Type Error. I could, of course, quickly fix this single glitch in my code, but I wonder if somebody implemented a full wrap for the old API to guarantee compatibility even beyond 3.1.0.

Thanks and cheers, Robert

SmCaterpillar
  • 6,683
  • 7
  • 42
  • 70

1 Answers1

1

You can read the migrating guide (in particular the Consistent create_xxx() signatures section) and the release notes to be aware of API changes, specially backward incompatible changes. You will see that the main think that could break compatibility is that some function/method parameters have been renamed to be more PEP8 compliant. I think the full bridge you are looking for doesn't exist yet, so you will have to manage that incompatibility changes by hand. Anyway you can use the pt2to3 tool for making your migration less painful.

UPDATE

You can ask for help to the PyTables Google groups: pytables-dev and pytables-users.

Vicent
  • 5,322
  • 2
  • 28
  • 36
  • Yes, I already read the migrating guide. The problem is I don't want to migrate but support both APIs in my program because pytables 3 is not widely used. Installing pytables involves compiling C code, which might be tricky sometimes. This is especially true for inexperienced users who tend to give up if `pip install tables` yields a giant wall of text on the console with many error statements in it. – SmCaterpillar Oct 07 '13 at 08:23
  • The completely backwards compatibility layer does not exist and arguably it shouldn't. What does exist is 99.5+% backwards compatible. That extra 0.5%, which you are hitting was changed for a very good reason. In the example you give, the builtin object type is overridden. This is/was totally unacceptable. It was not OK to have in the PyTables code base and I would consider it a bug whenever a user uses the object keyword part of the API. You should change to obj or call the function with an object argument, rather than a keyword argument. – Anthony Scopatz Oct 07 '13 at 14:15
  • @AnthonyScopatz I didn't know you are ubiquitous. Thanks for your crystal clear explanation. – Vicent Oct 07 '13 at 14:46
  • Yup @Vicent, I am everywhere there is PyTables. – Anthony Scopatz Oct 07 '13 at 17:00