-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make give pyfdb more pythonic interfaces #15
base: develop
Are you sure you want to change the base?
Conversation
Hi @TomHodson, all issues with the building cicd pipeline aside: Is there any reason this MR is WIP? |
This looks fundamentally good. Can you clarify why the checks were failing (the logs have expired) |
seek must accept a whence parameters that takes values io.SEEK_SET, SEEK_CUR or SEEK_END The latter two are not implemented by the underlying fdb library so I have put a warning in.
8ffcc4d
to
667ebc6
Compare
This allows you you to call next(iterator) to just get the first entry without constructing the full stream.
667ebc6
to
95e3cc5
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #15 +/- ##
===========================================
- Coverage 33.00% 32.46% -0.54%
===========================================
Files 5 5
Lines 303 308 +5
===========================================
Hits 100 100
- Misses 203 208 +5 ☔ View full report in Codecov by Sentry. |
For DataReader to be considered file like it has to match the interface exactly, hence DataReader.read has to have a default argument for count(), it also needs to return a bytes object for all code paths.
This PR fixes two issues to try to make the objects returned by pyfdb behave more like native python objects.
Issue 1 DataRetriever does not inherit from io.BaseIO
Objects that represent a stream like pattern in python is usually derived from io.BaseIO or a child of that. pyodc, for example, checks if an object is derived from io.BaseIO in order to determine whether it should be treated like a filename and opened or treated like a stream object.
I change DataRetriever to inherit from io.RawIOBase and also slightly modiy DataRetriever.seek to implement the correct interface. There's a slight issue here in that really DataRetriever.seek should accept a parameter whence = io.SEEK_CUR or io.SEEK_END but for now I have just put a NotImplementedError in that path.
I have also added a default value for DataRetriever.read(count = -1) because this is required by the type checker and made it return an empty bytearray if count=0. After this the type checker is now happy to let you pass DataRetriever objects anyway a file object would go.
Issue 2 ListIterator is not an iterator
The way ListIterator is implemented is a valid pattern for creating iterables in python, however it has the downside that because
__next__
is not implemented you can't callnext(it)
to get just on value from the output of fdb.listI slightly refactor ListIterator to implement
__next__
.EDIT: I've now tested this and am happy that it's correct.