Skip to content

Change NAMESPACE_BEGIN and NAMESPACE_END macros into PYBIND11_NAMESPACE_BEGIN and PYBIND11_NAMESPACE_END #2283

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

Merged

Conversation

YannickJadoul
Copy link
Collaborator

Straightforward PR, implementing suggestion from #2199.

Closes #2199.

@wjakob
Copy link
Member

wjakob commented Jul 8, 2020

This is a no-brainer, feel free to merge once the CI passes.

@bstaletic
Copy link
Collaborator

So CI is broken. Partially because PyPy is broken since yesterday, like we discussed.

The other error is:

+brew upgrade python
Error: python not installed

@YannickJadoul
Copy link
Collaborator Author

The other error is:

+brew upgrade python
Error: python not installed

Sigh. How does Travis keep on changing what's default installed with homebrew??

@YannickJadoul YannickJadoul force-pushed the fix-namespace-macro-collisions branch from b33874c to 7a8cc07 Compare July 8, 2020 15:05
@bstaletic
Copy link
Collaborator

Messages from brew install python:

==> Caveats
Python has been installed as
  /usr/local/opt/[email protected]/bin/python3
You can install Python packages with
  /usr/local/opt/[email protected]/bin/pip3 install <package>
They will install into the site-package directory
  /usr/local/opt/[email protected]/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages

So it installed python 3.8, not 3.7. This could explain the error:

ld: library not found for -lpython3.7m

@henryiii
Copy link
Collaborator

henryiii commented Jul 8, 2020

Homebrew finally finished the Python 3.7 to 3.8 transition, was merged yesterday, so this isn't really Travis' fault.

@YannickJadoul
Copy link
Collaborator Author

Thanks, @bstaletic and @henryiii. Not behind my laptop, currently. Feel free to push a fix to my branch!

.travis.yml Outdated
@@ -149,7 +149,7 @@ matrix:
- os: osx
name: Python 3.7, c++14, AppleClang 9, Debug build
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Description is still 3.7

Copy link
Collaborator

Choose a reason for hiding this comment

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

How did I miss that? I'll have to checkout & force push now...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I can do it in a few hours as well!

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done.

@YannickJadoul
Copy link
Collaborator Author

Thanks Henry!

Something fishy still happened before, btw, because CMake was called with -DPYBIND11_PYTHON_VERSION=3.7 and reported

-- Found PythonInterp: /usr/local/bin/python3.7 (found suitable version "3.7.5", minimum required is "3.7") 
-- Found PythonLibs: python3.7m

That's why I didn't look further at HomeBrew's installation...

@henryiii
Copy link
Collaborator

henryiii commented Jul 8, 2020

python became [email protected], [email protected] became python and was allowed to override the links in /usr/local/. It looks to me that 3.7 didn't become keg-only, though I rather would have thought it should have. python3.7 is still installed and still available.

@henryiii henryiii force-pushed the fix-namespace-macro-collisions branch from 84eca63 to 7c16b80 Compare July 8, 2020 20:17
@henryiii henryiii force-pushed the fix-namespace-macro-collisions branch from 7c16b80 to 681ebc4 Compare July 8, 2020 20:17
@YannickJadoul
Copy link
Collaborator Author

YannickJadoul commented Jul 8, 2020

Ah, right, thanks for the explanation! I don't know brew's thát well :)

@bstaletic
Copy link
Collaborator

Someone could cancel the second to last appveyor run and save this PR ~20 minutes.

@YannickJadoul
Copy link
Collaborator Author

Appveyor doesn't give collaborators access. It's on wjakob's account and we'd need an explicit invitation (which is probably not worth the trouble if we're switching to GHA soon enough).

@henryiii henryiii merged commit f980d76 into pybind:master Jul 8, 2020
@henryiii
Copy link
Collaborator

henryiii commented Jul 8, 2020

@wjakob already approved, so merged. Thanks!

@YannickJadoul YannickJadoul deleted the fix-namespace-macro-collisions branch July 8, 2020 22:17
@YannickJadoul
Copy link
Collaborator Author

3 minutes too late to merge! Thanks for the final fixes, @henryiii!

@patrikhuber
Copy link
Contributor

patrikhuber commented Aug 1, 2020

Hi,

I updated from an older pybind to the recent master today and was greeted with a bunch of compiler error messages. If I see it correctly, this is a change that came after the 2.5.0 release so I'm probably ahead of the curve. I couldn't find anything in the docs about it. I would strongly recommend to mention this in the Upgrade Guide https://pybind11.readthedocs.io/en/stable/upgrade.html.

Also the typecaster example in the docs https://pybind11.readthedocs.io/en/stable/advanced/cast/custom.html uses the manual namespace pybind11 { namespace detail { and not the macro. In fact, a search in the documentation for NAMESPACE_BEGIN or PYBIND11_NAMESPACE_BEGIN yields no (useful) results. I would recommend adding the macro to the docs and in particular to the custom type caster example?

Thank you all for working on and improving pybind11, it's one of the most awesome libraries/tools out there! :-)

@patrikhuber
Copy link
Contributor

patrikhuber commented Aug 1, 2020

I'm actually now wondering what this macro is for - as you still need to specify the actual name of the namespace, e.g.:

PYBIND11_NAMESPACE_BEGIN(pybind11)
PYBIND11_NAMESPACE_BEGIN(detail)

I can't see any benefits? It's not shorter (longer even) and you still need to remember and "manually" type the name of the actual namespace, so you might as well just type

namespace pybind11 {
namespace detail {

It would be useful if you could just do:

PYBIND11_NAMESPACE_BEGIN
// ... my typecaster code ...
PYBIND11_NAMESPACE_END

In that way, as a user/consumer of pybind11 I don't have to remember what namespace to define my stuff in, and if you pybind11 folks ever decide to change the namespace, my code is future proof. I originally thought that's what the purpose of the macro is, but now see that that's currently not the case.

@YannickJadoul
Copy link
Collaborator Author

This is an undocumented macro, though, so I'm not sure pybind11 is responsible for breaking undocumented stuff? ;-) (Then again, I also don't really know why the macros are actually there?)

There's also not a new release yet, and I don't think it's clear yet whether it will be a patch, minor, or major release, so it's hard to write this part of the docs (and anyway, it won't show up on the "stable" version of RTD!). Though I guess it could be a good plan to keep a list of changes to master, there (@henryiii did start a "pending" changelog, I believe).

I can't see any benefits?

Not sure why it's there, but there must be a reason?

It would be useful if you could just do:

PYBIND11_NAMESPACE_BEGIN
// ... my typecaster code ...
PYBIND11_NAMESPACE_END

That wouldn't really make sense, because it's in pybind11::detail, and adding detail by defaults will give other problems (because obviously, some things (actually, all "public" things) are nót in detail. The casters are the weird one out because you are allowed to create your own caster, but I believe pybind11 doesn't guarantee that the interface won't break, so that (and historical reasons) is why it's in detail.

PS: Expecting @bstaletic to pop up any time now, shouting "Hyrum's law".

@bstaletic
Copy link
Collaborator

A few thoughts.

  1. NAMESPACE_BEGIN and NAMESPACE_END are horrible macro names that should never appear in any code base.
  2. The docs don't mention it because there's no reason to.
  3. The docs use namespace pybind11 { namespace detail { because that's what is officially supported.
  4. Does pybind11 have users who depend on the exact definition of header guards?

I'm honestly surprised that anyone would try to depend on something like NAMESPACE_BEGIN. As it just doesn't come up in the docs or issues, except in some diffs, one would almost have to look for these macros and use something out of contract.

That said...

PS: Expecting @bstaletic to pop up any time now, shouting "Hyrum's law".

Exactly!

@henryiii
Copy link
Collaborator

henryiii commented Aug 1, 2020

Hyrum's law

That's exactly what I thought of when I saw this. :)

@henryiii
Copy link
Collaborator

henryiii commented Aug 1, 2020

I didn't remember the upgrade guide, thanks! Will make sure CMake related things go in there soon!

@patrikhuber
Copy link
Contributor

I see! Makes complete sense. I agree then it should not be mentioned in the docs or upgrade guide, as it's internal-use only. I've removed it from my type-casters and changed it to namespace pybind11 { namespace detail {.

I don't remember why I used that macro or where I found it, but I don't think I was specifically looking for it. If I had to venture a guess I would say that it (mistakenly, in that case) might have been part of some pybind11 example typecaster code somewhere a few years ago, and I copied it from there. But anything is possible.

Thanks a lot, and I guess "sorry for using undocumented stuff" :-).

@YannickJadoul
Copy link
Collaborator Author

Thanks for the friendly reminder that we need to start thinking about this upgrade guide ;-)

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.

NAMESPACE_BEGIN macro redefinition
5 participants