Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 100 additions & 0 deletions python/src/iceberg/io/base.py
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):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there not a return type that we require here? What about IOBase? @emkornfield do you have a suggestion for this?

Copy link
Contributor

Choose a reason for hiding this comment

The 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)?

Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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:
        ...

Copy link
Contributor

Choose a reason for hiding this comment

The 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."""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, be consistent ending doc-strings with periods or not.

Copy link
Contributor

Choose a reason for hiding this comment

The 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):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, is there an IO type that this should return?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If not, we could create one that has the __enter__ and __exit__ methods that make with automatically close the file?

"""This method should return a file-like object.
Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I specify the required methods which I believe are write, close, flush, and tell? Maybe also mention that close should flush. Or better yet just add a protocol here too with those methods and specify that protocol in the docstring for create?

"""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:
        ...

Copy link
Contributor

Choose a reason for hiding this comment

The 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):
Copy link
Contributor

Choose a reason for hiding this comment

The 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:
Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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:

  1. Provide a single class and have users only implement the methods they want (you can document a set of methods that should always be implemented together). Giving users run-time errors when not implemented.
  2. Separate the functionality into two different interfaces and require all methods be implemented.

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"""
Loading