Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix to work with the new Pythran API #2600

Closed
wants to merge 2 commits into from

Conversation

aguinet
Copy link
Contributor

@aguinet aguinet commented Sep 10, 2018

Pythran 0.9.0 has a new API regarding the shape of ndarrays. This PR supports this new API.

This must not be merged until Pythran 0.9.0 is out!

@aguinet
Copy link
Contributor Author

aguinet commented Sep 10, 2018

cc @serge-sans-paille

@serge-sans-paille
Copy link
Contributor

Thanks @aguinet. I'll update this thread once the new release is out.

@scoder
Copy link
Contributor

scoder commented Sep 13, 2018

Rather than breaking what's there and having to wait for users to install what's new, I think it would be better to have something that works with both the older and the new versions. @aguinet @serge-sans-paille, do you think that's possible? We know the Pythran version at translation time, right? Couldn't we base the distinction on that? (Or maybe even something at C++ compile time?)

@@ -130,7 +130,7 @@ def file_hash(filename):
def update_pythran_extension(ext):
if not PythranAvailable:
raise RuntimeError("You first need to install Pythran to use the np_pythran directive.")
pythran_ext = pythran.config.make_extension()
pythran_ext = pythran.config.make_extension(python=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this change is already needed for Pythran 0.8.7.

@@ -39,7 +39,7 @@ def pythran_type(Ty, ptype="ndarray"):
ctype = dtype.typedef_cname
else:
raise ValueError("unsupported type %s!" % dtype)
return "pythonic::types::%s<%s,%d>" % (ptype,ctype, ndim)
return "pythonic::types::%s<%s,pythonic::types::pshape<%s>>" % (ptype,ctype, ",".join(("long",)*ndim))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@serge-sans-paille @aguinet
What about this change, is this correct for Pythran 0.8.7 ? Does it work with older Pythran versions or is this a breaking change?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And, why does it use long instead of size_t or Py_ssize_t ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to use Py_ssize_t and it seems to work for me (on 64 bit Linux).

@scoder
Copy link
Contributor

scoder commented Sep 16, 2018

I integrated the changes manually, hopefully in a backwards compatible way.

@scoder scoder closed this Sep 16, 2018
@scoder scoder added this to the 0.29 milestone Sep 16, 2018
@serge-sans-paille
Copy link
Contributor

Rather than breaking what's there and having to wait for users to install what's new, I think it would be better to have something that works with both the older and the new versions. @aguinet @serge-sans-paille, do you think that's possible? We know the Pythran version at translation time, right? Couldn't we base the distinction on that? (Or maybe even something at C++ compile time?)

It's posisble to generate different code depending on the detected pythran.__version__. It's a new situation for pythran: there is no API contract on the C++ interface...

@scoder Yes, the change is correct for pythran 0.8.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants