add support for file_bytes argument with managed_file_context()

[bosd]

This is an attempt to cherry-pick in the PR from #15.
Fixes: camelot-dev#170 and camelot-dev#245 and atlanhq/camelot#376
and atlanhq/camelot#331

Was really fighting with git and the merge commits on the fork of a fork and so on...
Cherry pick approach was the cleanest.

I hope to have solved the merge conflicts correctly.
Please review..

[foarsitter]

Some of my thoughts:

1. Adding the extra variable file_bytes feels for me more like an extra type for filepath.
2. In __init__ there are two places where we raise an InvalidArguments
3. filepath isn't used beyond open(self.filepath, "rb"), so why do we need a name attribute for file_bytes?
4. The naming of managed_file_context isn't directly clear to me, open() would, or even implement PDFHandler as contextmanager so we can do with self but I think with self.open() would be better
5. Is @contextmanager doing the cleanup magically or do we need to do that manually?

[maylorian]

Hi,

Is this something that's planned to be merged soon? We're trying to move away from the old camelot and to this repo but this one is what's holding us back.

Thanks.

[bosd]

I'm currently not working on this one.
Been a bit focused on household tasks in this repo.
Feel free to contribute and superspeed this pr.

[bosd]

@foarsitter Thanks for your review.
I was merely forward porting this to the new repo. Without looking very deep into it.
Now I investigate the code a bit more. But have to admit I dont understand this fully yet 😮‍💨

Some of my thoughts:

1. Adding the extra variable file_bytes feels for me more like an extra type for filepath.
2. In __init__ there are two places where we raise an InvalidArguments

Do you have an suggestion to refactor this code?

3. filepath isn't used beyond open(self.filepath, "rb"), so why do we need a name attribute for file_bytes?

Idk, I would assume that file_bytes has its own attribute, because it needs to be handled differently.
e.g. writtten to a temp file on disk if it's getting too large to fit into memory?

4. The naming of managed_file_context isn't directly clear to me, open() would, or even implement PDFHandler as contextmanager so we can do with self but I think with self.open() would be better
5. Is @contextmanager doing the cleanup magically or do we need to do that manually?

Yes, I think it is done automagically. AFAIK thats the purpose for the wrapper.
https://realpython.com/python-with-statement/

Or should there be a:

    finally:
        file.close()