-
Notifications
You must be signed in to change notification settings - Fork 3k
Add FileIO, InputFile, and OutputFile abstract base classes #3691
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
Changes from all commits
3069c51
a8ee9d6
1c3177d
bb55bb5
1731ff7
181c190
51ea645
fcb7dc4
cc490a5
7b625cf
25836bf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,100 @@ | ||
| # Licensed to the Apache Software Foundation (ASF) under one | ||
| # or more contributor license agreements. See the NOTICE file | ||
| # distributed with this work for additional information | ||
| # regarding copyright ownership. The ASF licenses this file | ||
| # to you under the Apache License, Version 2.0 (the | ||
| # "License"); you may not use this file except in compliance | ||
| # with the License. You may obtain a copy of the License at | ||
| # | ||
| # http://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # Unless required by applicable law or agreed to in writing, | ||
| # software distributed under the License is distributed on an | ||
| # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
| # KIND, either express or implied. See the License for the | ||
| # specific language governing permissions and limitations | ||
| # under the License. | ||
| """Base FileIO classes for implementing reading and writing table files | ||
|
|
||
| The FileIO abstraction includes a subset of full filesystem implementations. Specifically, | ||
| Iceberg needs to read or write a file at a given location (as a seekable stream), as well | ||
| as check if a file exists. An implementation of the FileIO abstract base class is responsible | ||
| for returning an InputFile instance, an OutputFile instance, and deleting a file given | ||
| its location. | ||
| """ | ||
|
|
||
| from abc import ABC, abstractmethod | ||
| from typing import Union | ||
|
|
||
|
|
||
| class InputFile(ABC): | ||
| """A base class for InputFile implementations""" | ||
|
|
||
| def __init__(self, location: str): | ||
| self._location = location | ||
|
|
||
| @abstractmethod | ||
| def __len__(self) -> int: | ||
| """Returns the total length of the file, in bytes""" | ||
|
|
||
| @property | ||
| def location(self) -> str: | ||
| """The fully-qualified location of the input file""" | ||
| return self._location | ||
|
|
||
| @property | ||
| @abstractmethod | ||
| def exists(self) -> bool: | ||
| """Checks whether the file exists""" | ||
|
|
||
| @abstractmethod | ||
| def open(self): | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there not a return type that we require here? What about
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think IOBase is probably heavy weight. Using protocols seems like the right thing here)?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems to require https://pypi.org/project/typing-extensions/ for python <= 3.7
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like that idea! @rdblue does this protocol capture the required methods? class InputStream(Protocol):
def read(self, n: int) -> bytes:
...
def readable(self) -> bool:
...
def close(self) -> None:
...
def seek(offset: int, whence: int) -> None:
...
def tell(self) -> int:
...
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thinking about this some more I think IOBase is a right option here. It would guarantee interop with python standard library. Also if you look at it's design I think it lends credence to my comment below about potentially having one file type which can be inspected to determine if it is readable and writeable. |
||
| """This method should return an instance of an seekable input stream.""" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit, be consistent ending doc-strings with periods or not.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also specify what should happen if the file doesn't exist. |
||
|
|
||
|
|
||
| class OutputFile(ABC): | ||
| """A base class for OutputFile implementations""" | ||
|
|
||
| def __init__(self, location: str): | ||
| self._location = location | ||
|
|
||
| @abstractmethod | ||
| def __len__(self) -> int: | ||
| """Returns the total length of the file, in bytes""" | ||
|
|
||
| @property | ||
| def location(self) -> str: | ||
| """The fully-qualified location of the output file""" | ||
| return self._location | ||
|
|
||
| @property | ||
| @abstractmethod | ||
| def exists(self) -> bool: | ||
| """Checks whether the file exists""" | ||
|
|
||
| @abstractmethod | ||
| def to_input_file(self) -> InputFile: | ||
| """Returns an InputFile for the location of this output file""" | ||
|
|
||
| @abstractmethod | ||
| def create(self, overwrite: bool = False): | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here, is there an IO type that this should return?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If not, we could create one that has the |
||
| """This method should return a file-like object. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. file-like object is a confusing given that these classes are also called File. Is it supposed supposed to only support write() methods?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I should add that I understand it because I am familiar with the python idiom of "file-like" and maybe most users of these class will be since, because after all this is python.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should I specify the required methods which I believe are """This method should return an object that matches the OutputStream protocol
...
"""OutputStream protocol from typing import Protocol
class OutputStream(Protocol):
def write(self, b: bytes) -> None:
...
def close(self) -> None:
...
def flush(self) -> None:
...
def tell(self) -> int:
...
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I think documenting via type returned here makes sense here if we want to go with protocol. |
||
|
|
||
| Args: | ||
| overwrite(bool): If the file already exists at `self.location` | ||
| and `overwrite` is False a FileExistsError should be raised. | ||
| """ | ||
|
|
||
|
|
||
| class FileIO(ABC): | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. doc string |
||
| @abstractmethod | ||
| def new_input(self, location: str) -> InputFile: | ||
| """Get an InputFile instance to read bytes from the file at the given location""" | ||
|
|
||
| @abstractmethod | ||
| def new_output(self, location: str) -> OutputFile: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a reason to distinguish between input and output files? it seems like for the most part the APIs are very similar? It seems if a file is going to be only readable or writeable having the implementatin throw not-implemented might be a better choice?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This gives the flexibility to the implementation. You can always implement both base classes, right?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess this might be more a philosophical question. There are two ways to achieve the flexibility:
My sense is that #2 is more of a java design pattern. I think (but I'm no expert) option #1 is more pythonic/dynamically typed language pattern. |
||
| """Get an OutputFile instance to write bytes to the file at the given location""" | ||
|
|
||
| @abstractmethod | ||
| def delete(self, location: Union[str, InputFile, OutputFile]) -> None: | ||
| """Delete the file at the given path""" | ||
Uh oh!
There was an error while loading. Please reload this page.