Path: csiph.com!eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
From: "Joseph L. Casale" <jcasale@activenetwerx.com>
To: "python-list@python.org" <python-list@python.org>
Subject: return types from library api wrappers
Thread-Topic: return types from library api wrappers
Thread-Index: AdDYLMgMzjLZAaGWQlyK96o3U5/i5w==
Date: Sun, 16 Aug 2015 23:31:30 +0000
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.47.1439768058.4764.python-list@python.org>
Lines: 26
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:95418

What's the accepted practice for return types from a c based API
Python wrapper? I have many methods which return generators
which yield potentially many fields per iteration. In lower level
languages we would yield a struct with readonly fields.

The existing implementation returns a dict which I am not fond of.
I'd rather return an object with properties, however all the guys
who use this api use IDE's and want the type hinting. So, options I
can think of are to create a load of classes and returning instances
of them, return named tuples or even terser would be to return
something like:

def api_method(foo, bar):
    """produces two return values, x and y."""
    ...
    return type('MyResult', (), {'__slots__': [], 'some_field': x, 'another=
_field': y})()

The last option humorously returns readonly fields.

However, the latter two don't help much for type hinting unless
someone knows something I don't about doc strings? As a Python user,
what is preferred?

Thanks,
jlc