Opened 22 months ago

Closed 22 months 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) Commit: 434e7c2fde4cd4df9d71c529c177d7fc06ce40ba
Dependencies: #23360 Stopgaps:

Description

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

Change History (11)

comment:1 Changed 22 months ago by jdemeyer

  • Branch set to u/jdemeyer/ticket/23494

comment:2 Changed 22 months 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 22 months 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 22 months 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 22 months 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 22 months ago by jdemeyer

  • Status changed from positive_review to needs_work

Doctest failure (see patchbot)

comment:7 in reply to: ↑ 5 Changed 22 months 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 22 months 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 22 months 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 22 months ago by jdemeyer

  • Status changed from needs_work to positive_review

Trivial fix.

comment:11 Changed 22 months 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.