Opened 5 years ago

Closed 5 years ago

#23494 closed enhancement (fixed)

Monkey-patch inspect.isfunction() to support Cython functions

Reported by: jdemeyer Owned by:
Priority: major Milestone: sage-8.1
Component: cython Keywords:
Cc: Merged in:
Authors: Jeroen Demeyer Reviewers: Erik Bray
Report Upstream: N/A Work issues:
Branch: 434e7c2 (Commits, GitHub, GitLab) Commit: 434e7c2fde4cd4df9d71c529c177d7fc06ce40ba
Dependencies: #23360 Stopgaps:

Status badges

Description

See ​http://opendreamkit.org/2017/06/09/CythonSphinx/

Change History (11)

comment:1 Changed 5 years ago by jdemeyer

  • Branch set to u/jdemeyer/ticket/23494

comment:2 Changed 5 years ago by jdemeyer

  • Commit set to 9e33fb9e5602ca24371477789421c3ac4182e35e
  • Status changed from new to needs_review

New commits:

​44030beUpgrade to Cython 0.26
​9e33fb9Monkey-patch inspect.isfunction() to support Cython functions

comment:3 follow-up: Changed 5 years ago by embray

  • Reviewers set to Erik Bray
  • Status changed from needs_review to positive_review

I'm not really sure how I feel about 

hasattr(type(obj), "__code__")

but I'm not completely opposed to it. I just don't know why we can't be more specific.

comment:4 in reply to: ↑ 3 Changed 5 years ago by jdemeyer

Replying to embray:

I'm not really sure how I feel about 

hasattr(type(obj), "__code__")

but I'm not completely opposed to it. I just don't know why we can't be more specific.

My code uses the "duck typing" philosophy. But I'm open for suggestions...

comment:5 follow-up: Changed 5 years ago by embray

I don't think there's actually a formal interface that defines __code__ as implying a function-like type, as in the sense that the presence of __iter__ implies an iterable. Of course, practically speaking it works fine for that purpose so I'm fine with it; I just mean I don't think there's a specification or anything beyond the fact that the function type itself happens to have a __code__ attribute (I could be wrong, but I haven't seen anything of the sort).

Maybe it would be good, as part of any proposal to overhaul Python's function types, if there were an ABC for functions in the sense of ​https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes

comment:6 Changed 5 years ago by jdemeyer

  • Status changed from positive_review to needs_work

Doctest failure (see patchbot)

comment:7 in reply to: ↑ 5 Changed 5 years ago by jdemeyer

Replying to embray:

I don't think there's actually a formal interface that defines __code__ as implying a function-like type, as in the sense that the presence of __iter__ implies an iterable. Of course, practically speaking it works fine for that purpose so I'm fine with it; I just mean I don't think there's a specification or anything beyond the fact that the function type itself happens to have a __code__ attribute (I could be wrong, but I haven't seen anything of the sort).

I think you are right. However, the __code__ attribute seems to work in practice for my purpose, even if it's not formally documented.

comment:8 Changed 5 years ago by jdemeyer

And in any case, such duck-typing is better than the isinstance() check that the official inspect module does.

comment:9 Changed 5 years ago by git

  • Commit changed from 9e33fb9e5602ca24371477789421c3ac4182e35e to 434e7c2fde4cd4df9d71c529c177d7fc06ce40ba

Branch pushed to git repo; I updated commit sha1. New commits:

​434e7c2Fix doctest for sage_getsource()

comment:10 Changed 5 years ago by jdemeyer

  • Status changed from needs_work to positive_review

Trivial fix.

comment:11 Changed 5 years ago by vbraun

  • Branch changed from u/jdemeyer/ticket/23494 to 434e7c2fde4cd4df9d71c529c177d7fc06ce40ba
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.