Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #95420
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Subject | Re: return types from library api wrappers |
| Date | 2015-08-16 22:23 -0400 |
| References | <dcfc5584757c43589c9022c560418519@exch.activenetwerx.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.49.1439778227.4764.python-list@python.org> (permalink) |
On 8/16/2015 7:31 PM, Joseph L. Casale wrote:
> 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.
Current practice is a NamedTuple for python code or the C equivalent. I
forget the C name, but I believe it is used by os.stat
>>> os.stat('C:/programs')
os.stat_result(st_mode=16895, st_ino=1970324837036820,
st_dev=1816146727, st_nlink=1, st_uid=0, st_gid=0, st_size=4096,
st_atime=1437490766, st_mtime=1437490766, st_ctime=1313612988)
>>> s = os.stat('C:/programs')
>>> s.st_atime
1437490766.6669185
>>> s.st_atime = 3
Traceback (most recent call last):
File "<pyshell#11>", line 1, in <module>
s.st_atime = 3
AttributeError: readonly attribute
> 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.
I believe the above gives you both: custom class for type hinting and
properties.
--
Terry Jan Reedy
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: return types from library api wrappers Terry Reedy <tjreedy@udel.edu> - 2015-08-16 22:23 -0400
csiph-web