And? What's the bug? Just import like from worksheet.worksheet import Worksheet, though I don't know why you'd want to to this. A many of the modules are really internals for the library and not really intended for direct use.
CharlieC, thank you for your thoughts.
Lets consider somebody has some adaptor which job is to provide identical interface for both xls and xlsx documents. The adaptor works like this if isinstance(some_document_sheet, Worksheet): use openpyxl lib, otherwise use xlrd.
In my humble opinion, backward compatibility violation is a bug. Feel free to correct me if i am wrong. But the way i feel it is that it should be a note in a changelist or some deprecation warning or something similar to this if the removal was done on purpose.
Well, that test would fail with both ReadOnlyWorksheet and WriteOnlyWorksheet, you're safer checking the workbook. I'm taking more of the workhorse classes private to give me a bit more freedom in refactoring, but I think this change was provoked by runnning flakes over the project. Flakes doesn't seem to like façade imports for some reason and I can't be bothered to spend time learning how to configure flakes!
I have thought about creating ABCs or Interfaces for some of the classes but seems to be overkill but would be open to a discussion of a stable API for consuming libraries and applications. I've had to break stuff (mainly styles) in the past but generally try and avoid it. I don't really think that removing a façade import really counts as breaking the API but realise any change in an upstream library that causes a break in your own causes trouble. But 2.6 was in beta with this change for several months.