-
Notifications
You must be signed in to change notification settings - Fork 30
Predict app #121
base: dev
Are you sure you want to change the base?
Predict app #121
Conversation
- Add the abstract class Validator - Add the class PredictRequestValidator for validating single predict requests - Add fastai to requirements
- Use Validator in predict single - Add abort function to Validator
- Add PredictZipRequestValidator to module requests
- Handle file through file class - File is removed in the destructor - Use in predict_single
- Add ZipArchive to handle zips - Add predict multiple method to Predictor - Remove unused utils - Change File to set file or pathname - Change predict_zip in app
- Add docstrings for new classes - Remove unused imports
- Remove imports from __init__ - Fix circle import from File and app
d60aa76
to
74ed977
Compare
Got it, thanks! Will review at my earliest opportunity. |
684e535
to
9e3ec64
Compare
9e3ec64
to
31201ac
Compare
Hey @gsganden, is there anything else you would change in my PR? I would be very happy with some advice and comments on my changes. Thanks very much :) |
It might take me a little while, but I will get to it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution! You and I have different coding styles that we'll need to reconcile. Overall, I favor more functional approaches. I'm open to accepting PRs that are not the way I would have done it, but I also want the overall design to be unified and idiomatic. There are also some places (particularly in the file and zipfile handling) where just using Python's standard library and built-in capabilities will result in code that other Python developers will find easier to understand.
How would you like to proceed? I'd be happy for you to take another crack at it if you are willing. I could also take some of your contributions and adapt them in a more functional style when I get a chance.
autofocus/predict/app/models/File.py
Outdated
from werkzeug import secure_filename | ||
|
||
|
||
class File: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need our own file class -- Python has built-in ways to do these things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Especially for our use case, I wrote the File class, so it would remove the file upon destructing the object. This removes the need to manually handle this every time while handling a file.
I think maybe the naming here is the problem, so I renamed this class to be 'TemporaryFile'.
I would like to keep this class, since the functionality here is pretty awesome and makes the handling very simple. However it is your call, if you don't see the value.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we use https://docs.python.org/3/library/tempfile.html?
CLASSES = model.data.classes | ||
|
||
|
||
class Predictor: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we make these methods top-level functions? I don't see much benefit in having them together in a class rather than just a module, it requires another line of code for callers, and it seems to me less idiomatic Python.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I made them top-level functions now.
While developing the class I thought about adopting this class for other predictions as well. That was my thought behind this.
from ..utils import allowed_file | ||
|
||
|
||
class ZipArchive: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need our own ZipArchive class -- the standard library has these capabilities https://docs.python.org/3/library/zipfile.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the same as for the 'File' (now 'TemporaryFile'). It adds more functionality to the build in functions and can be reused.
ALLOWED_ZIP_FILES = {".zip"} | ||
|
||
|
||
class Validator(ABC): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class structure here seems to me to add more overhead than it is worth. All we need is one function to validate predict
requests, one to validate predict_multiple
requests, and appropriate calls to abort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point and changed this to be a single method now.
735a9aa
to
8b6ecc1
Compare
Hey @gsganden I revisited the code and made it more functional and removed most of the object orientation. However, I kept the File (now TemporaryFile) and ZipArchive as classes, as said before. If you really don't favor this approach, I would be willing to change it as well, but I think it adds a lot to the simplicity of the code and would favor to keep it. What do you think? |
from ..validation.predict import validate_predict_request | ||
|
||
|
||
predict_route = Blueprint("predict", __name__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've never used Blueprint
objects, but I'm intrigued. Can you point me to a resource that explains how they work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good. I think we can simplify it further by using the standard library tempfile
and zipfile
modules rather than creating custom classes. I'd also like to understand how Blueprint
works if you could point me to relevant resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good. I think we can simplify it further by using the standard library tempfile
and zipfile
modules rather than creating custom classes. I'd also like to understand how Blueprint
works if you could point me to relevant resources.
Feel free to open a PR before all of these items have been completed.
Pull Request Checklist
./.ci/local_checks.sh
passes locally. (The app must be running. SeeREADME.md
for instructions.)Maintainer's responsibilities:
_version.py
has been updated.CHANGELOG.md
has been updated.