Can I make UniCurses more Pythonic?

Question

I'm a hobbyist programmer teaching myself Python. As the curses module doesn't work on Windows, I've been looking at UniCurses, a cross-platform Curses implementation. I was disappointed to find that UniCurses functions bear little resemblance to the Python style I've come to love, probably due to legacy-support and historical reasons. For instance, to add text to a "window" within the terminal, you call waddstr(WINDOW, str, [attr]) or mvwaddstr(WINDOW, y, x, str, [attr]). There are dozens of these cryptically-named functions which require passing the window as a parameter, and don't treat the window as a object with methods, instance variables etc.

I would prefer to write in a more Pythonic style, where methods are called on window and panel objects e.g. window_instance.add_string(string, [attr]), ideally providing optional x and y parameters to the method to incorporate mvwaddstr() in the same method definition as waddstr().

The means of implementing this that comes to mind would be defining a class for the window construct like so:

import unicurses 
# this would normally be 'from unicurses import * ' but I'm trying to being explicit here

...

class PseudoWindow(object):
    def __init__(self, num_cols,num_lines, begin_x, begin_y):
        self.id = unicurses.newwin(nlines, ncols, begin_y, begin_x) 
        # use this value in unicurses functions

    def __del__(self):
        unicurses.delwin(self.id)

    def add_string(self, string, [attr], x = None, y = None)
        if x is None and y is None:
            unicurses.waddstr(self.id, string, [attr])
        else:
            unicurses.mvwaddstr(self.id, string, y, x, [attr])

    # wrap further unicurses functions into methods of PseudoWindow as required

As an inexperienced programmer, the mental cost of switching from one vernacular to another is somewhat high, and wrapping these functions in a more familiar syntax would seem to be a big quality-of-life benefit. Am I missing something about how UniCurses is meant to be used? What are the downsides and pitfalls to wrapping the API in a further layer of abstraction in this fashion? Is there an alternative to this approach that would still allow me to use the standard object oriented Python syntax?