| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| Expand Up | @@ -11,6 +11,8 @@ branches: | |
|
|
||
| clone_depth: 50 | ||
|
|
||
| image: Visual Studio 2017 | ||
|
|
||
| environment: | ||
|
|
||
| global: | ||
| Expand Down | ||
| Back | FazBrowse Home | New Git URL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityBecause of lacking knowledge: will this cause problems for anyone possibly creating the Triangulation explicitly? Am I correct assuming that passing None is no longer feasible at this level?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityIn principle yes, but we do not expose this class out publicly (there is a Python-side Triangulation class in tri._triangulation that we re-export in tri/__init__.py).
I think it is OK both that we change this API without warning and that we have tests that touch private API.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityI'm not entirely happy with this internal conversion of None to empty tuple for optional integer arrays but I cannot think of an alternative that isn't worse. In the long run we will use std::optional but that is C++17. I wouldn't want to use any C++17 until SciPy does, but that may not be far away (https://docs.scipy.org/doc/scipy/dev/toolchain.html#c-language-standards).
In the meantime we can use std::optional by shipping our own optional.h but I wouldn't want to do that as if there is a problem with some obscure compiler we will be on our own. Or we could write our own bespoke np.array | None pybind11 converter class but that is much more esoteric C++ than we currently have. So the least bad option is to stick with the None to tuple until we are OK with using C++17.
Note to self: need to add explicit internal API tests for set_mask as this also accepts an optional array.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Qualityfwiw scipy seems to aim to bump to c++17 in the next (1.10) release, see scipy/scipy#16589.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.