Robert Sachunsky

Results 941 comments of Robert Sachunsky

Note: we still have a problem with the docstrings in the superclass. They are useful for the API doc of core, but they are also used by `generate_processor_help` in concrete...

> Note: we still have a problem with the docstrings in the superclass. They are useful for the API doc of core, but they are also used by `generate_processor_help` in...

I found https://bugs.python.org/issue40257 and https://bugs.python.org/issue15582 touching on the docstring inheritance issue, but it's still unclear to me why Python behaves the way it does. I can see the point of...

BTW, the default 10% for the [new](https://github.com/OCR-D/core/pull/1240/commits/efe420138141a8c15b3967987c103753274edeb6) `OCRD_MAX_MISSING_OUTPUTS` may not be what we want. We could easily set -1 or 0 to change that to an opt-in.

@kba I would say it's time for b2! What I still don't like conceptually is that we set `Processor.workspace` during `Processor.process_workspace(workspace)`, but do not unset it (delattr) it afterwards. Also,...

> BTW, the default 10% for the [new](https://github.com/OCR-D/core/pull/1240/commits/efe420138141a8c15b3967987c103753274edeb6) `OCRD_MAX_MISSING_OUTPUTS` may not be what we want. We could easily set -1 or 0 to change that to an opt-in. Same goes...

Another backwards compatibility problem is behaviour for `--overwrite`: our v2 processors use their own `Workspace.add_file` calls, without setting `force=ocrd_utils.config.OCRD_EXISTING_OUTPUT == 'OVERWRITE'`. They expect the workspace to implicitly handle that via...

> Another backwards compatibility problem is behaviour for `--overwrite`: our v2 processors use their own `Workspace.add_file` calls, without setting `force=ocrd_utils.config.OCRD_EXISTING_OUTPUT == 'OVERWRITE'`. They expect the workspace to implicitly handle that...

@MehmedGIT > But if `initLogging` is not invoked then the logging `is` (maybe it's a `was` now, not sure) not working at all when core code is imported in another...