
In #1626545, Anton Tropashko requests that object.h should be renamed, because it causes conflicts with other software. I would like to comply with this requests for 2.6, assuming there shouldn't be many problems with existing software as object.h shouldn't be included directly, anyway. What do you think? Regards, Martin

On 1/3/07, Fred L. Drake, Jr. <fdrake@acm.org> wrote:
Maybe this should be done in a more systematic fashion? E.g. by giving all "internal" header files a "py_" prefix? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 1/3/07, Guido van Rossum <guido@python.org> wrote:
I was thinking the same, and I'm sure Neal Norwitz is/was too (he suggested this a few times in the past, at least outside of python-dev.) There are a few headers that might be in 'legitimate' use right now (as in, there is no way to do what they need to do without including those seemingly internal headers) but personally I think breaking source compatibility and requiring portable code that needs access to those to #if/#ifdef around it, to be a reasonable price to pay. (Only for header files that should really be internal, of course, not ones that are oft-used outside the core.) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Mostly structmember.h and structseq.h, less often code.h, compile.h, frameobject.h, marshal.h. Aside from the ones that are already prefixed with 'py' and not included by Python.h (pythread.h, pyexpat.h maybe?) I'm not sure which should really be public. Both structmember.h and structseq.h are generally useful to extension modules -- I've used both, although I don't think I would have used structseq if I wasn't already quite aware of it. The rest is useful only for extension modules that want to muck about with internals (like profilers, debuggers, custom marshalmunching and nasty extension modules that want to hook into Python internals that are not easily hooked into) and they will have to deal with less backward compatibility at the source and binary level anyway -- let them fix their imports. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On 1/3/07, Thomas Wouters <thomas@python.org> wrote:
Wow, I didn't realize I was that much of a broken record. :-) I don't even remember talking to Thomas about it, only Guido. I definitely would like to see all private header files clearly denoted by their name or directory. I saw Jack's comment about Apple's naming scheme, but I'm ignoring that for the moment. I have bad memories from the Motif days of including everything with one file. I prefer to see includes with the directory. This provides a sort of namespace: #include "python/foo.h" Though, if the user only has to include a single Python.h like currently, this wouldn't make as much sense. I don't recall the same problems in Python that existed when using Motif. Here are some options (python/ can be omitted too): #include "python/public.h" #include "python/internal/foo.h" #include "python/private/foo.h" #include "python/_private.h" I don't really like prefixing with py_ because from a user's perspective I interpret py_ to be a public header that gives me a namespace. I prefer a directory that indicates its intent because it can't be misunderstood. IIRC Guido didn't want to introduce a new directory. In that case my second choice is to prefix the filename with an underscore as a leading underscore often is interpreted as private. Going along with this change I would like to see all identifiers in public header files prefixed with [_]Py. And public header files shouldn't be able to include private header files (by convention). Or we should have some other way of denoting which files must prefix all their identifiers and which can use anything because they are only used in Python code. For example, right now node (struct _node) is exported in node.h in 2.4. I think it moved in 2.5, but it's still exported IIRC. n

Neal Norwitz schrieb:
What is a private header file, and does Python have any? I can see why Modules/sre.h is "private": it won't get installed at all, so users can't include them. For everything in Include, I think users can, and will, include them directly, unless they get them through Python.h. Regards, Martin

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
By private, I mean internal only to python and don't need to prefix their identifiers with Py and are subject to change without backwards compatibility. Include/graminit.h is one example of what I mean. Some others are: bitset.h, grammar.h, opcode.h, metagrammar.h, errcode.h Others are kinda questionable (they have some things that are definitely public, others I'm not so sure about): code.h, parsetok.h, pyarena.h, longintrepr.h, osdefs.h, pgen.h, node.h These are just some examples of what I mean. These may be in include because they are used between two top level directories, but not meant to be exported. There could be other reasons too. n

Neal Norwitz schrieb:
Ah. This seems to be a requirement completely different from the one I'm talking about. By this definition, object.h is *not* an internal header file, yet I want it to be renamed. As for this issue: how about moving all such private header files out of Include entirely? The parser-related ones should go into Parser, for example (grammar.h, bitset.h, graminit.h, metagrammar.h, errcode.h). This would leave us with opcode.h only.
Thomas said that at least code.h must stay where it is. What is the reason that you want them to be renamed? Regards, Martin

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Agreed. I was mixing two things that aren't necessarily related because I see the same possible solution. I'm also using this one example as a good opportunity to clean up more things. Let me try to explain a bit more below.
Sorry, I wasn't trying to imply that these should necessarily be renamed, only that the internal portions be moved elsewhere. I guess I should explain my mental model first which might make things clearer. Then again, I'm tired, so who knows if it will explain anything. :-) I'm a Python embedder and I want to know what's available to me. I look in Include and see a ton of header files. Do I need all these? What do I *need* and what can I *use*? I only want to see the public stuff that is available to me. Thus I want anything that has internal/implementation details/etc out of my sight to reduce my learning curve. I don't ever want to learn about something I won't need nor include anything I won't need. That's one part. Another part of my mental model is that I'm a Python developer and I'm modifying a header file that is implementation specific. I need to share it among different subdiretories (say Python and Objects). So I really need to stick the header file in a common place, Include/ is it. I don't want to export anything, but I don't know if other third party developers will use the header or not. Or maybe I need to include some implementation details in another public header. I'll probably be lazy and just make a single header which has some internal and some public stuff. I want clear rules on when identifiers need to be prefixed. If it's internal (e.g., in an internal directory or prefixed with _), it can have any name and can't be included from any non-internal header. I can also change it in a point release. If anyone uses anything from here, they are on their own. If I see any identifier in a non-internal header, it must be public and therefore prefixed with Py or _Py. The Python headers are pretty good about prefixing most things. But they could be better. I think it gets harder to maintain without the rules though. Finally, by putting everything in directories and always including a directory in the header file, like: #include "python/python.h" #include "python/internal/foo.h" There can never be an include file name collision as what started this thread. It also provides a simple way of demonstrating what's public and what is not. It addresses all my complaints. There are only a few rules and they are simple. But I am addressing several points that are only loosely related which I what I think generated some confusion. Adding the directory also makes clear were the header file comes from. If you see: #include "node.h" you don't know if that's a python node.h, from some other part of the code or a third party library. Not to try to confuse things even more, but I will point out something Google does that is only indirectly related. Google requires importing modules. You aren't supposed to import classes. You wouldn't do: from foo.bar import Message # ... msg = Message(...) You would do: from foo import bar # ... msg = bar.Message(...) This makes it clear where Message comes from, just like adding a python prefix to all header file names makes it clear where the header file lives. Both are good for traceability, though in different ways. This technique makes it easier to manage larger code bases, particularly when there are multiple libraries used. n

Neal Norwitz schrieb:
Ideally, you should look at the documentation. It should have everything you can use, and only that. I know that this currently doesn't work, for two reasons: - the documentation is incomplete, i.e. it omits things that people do use on a regular basis - people read header files, even if the documentation was complete
There could be another standard directory for header files also, like Python.
I don't want to export anything, but I don't know if other third party developers will use the header or not.
I find that debatable. I see no reason not to export everything, unless a stable ABI is also an objective (which it may be). If people really want to get to the internals, they can access structures even if they aren't defined in a header file, by replicating the structure definition in their own code. There should be a "mostly stable" API, certainly, and this is the one that is documented. Other things in the header files aren't "internal", they are just undocumented and thus may change without notice.
I want clear rules on when identifiers need to be prefixed.
Always, unless they are static functions. Even an "internal" function must be prefixed, as you may otherwise get conflicts when embedding Python. At the moment, only the AST exports symbols that aren't properly mangled. [internal symbols]
I can also change it in a point release. If anyone uses anything from here, they are on their own.
No. There shouldn't be any possible ABI breakage in a point release.
As specified, above, it is incompatible with the current API. I think #include <Python.h> should be preserved. I personally see no problem with a single header file, and would prefer that include to indicate all API that we are committed to document and keep "mostly stable". Regards, Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 4, 2007, at 4:17 AM, Martin v. Löwis wrote:
I agree. I don't mind if Python.h is just a wrapper around #includes from python/*.h. I think we should add structmember.h and structseq.h to Python.h and perhaps move everything else into a 'python' subdirectory. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZ0pfnEjvBPtnXfVAQKuyAP+J8Tm3z4am5BOfXCSJIeHsA1tEddeniuM dqSUAPUQUag9WkvkAreQYXu3iRC26e52mJ0B8eceqiuBa16WPILb0CvRFCBoW2fc /FAg4EROlMBhrE/MWVSfGSi76bL+4CwaogmHOnsvyCDEppA420C/8Zkz1VZYiGGd T+Ppo1ZVsHA= =b/Fm -----END PGP SIGNATURE-----

Barry Warsaw schrieb:
For the python subdirectory, there is the issue that the framework includes in OSX magically look for python.framework when searching for python/foo.h, which they find, so that may get us the wrong version. Somebody would have to study the details here, first. Regards, Martin

On Thursday 04 January 2007 11:33, Martin v. Löwis wrote:
If everything public gets included from Python.h, perhaps python/object.h and friends could become pythonX.Y/object.h; I'm not sure this will solve the Mac OS framework magic issue, though, not being a Mac OS developer. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

On 4 Jan, 2007, at 17:56, Fred L. Drake, Jr. wrote:
That would solve the problem, however I don't think there is one. An experiment seems to indicate that the include path is prefered over the magic inclusion of framework headers (see the trace below). I haven't checked yet if the behaviour shown below is intentional, but I'd be surprised if it isn't. $ mkdir include $ mkdir include/Python $ cat > include/Python/object.h <<EOF #error "my header included" EOF $ cat > demo.c <<-EOF #include <Python/object.h> EOF $ $ cc -c demo.c In file included from demo.c:1: /System/Library/Frameworks/Python.framework/Headers/object.h:227: error: parse error before ‘FILE’ /System/Library/Frameworks/Python.framework/Headers/object.h:353: error: parse error before ‘PyType_IsSubtype’ ... more errors removed, this clearly includes a header from the python framework $ $ cc -I include -c t.c In file included from demo.c:1: include/Python/object.h:1:2: error: #error "my error" Therefore moving all headers into a directory named Python would cause no problems users that use the normal way of linking with python and would even allow users to use the python framework as a normal framework. Ronald

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 4, 2007, at 2:36 PM, Ronald Oussoren wrote:
I think that's basically correct: framework includes are searched after normal includes. You might be able to confuse things if you used -F/-framework options, because I believe those are interleaved with -I paths, but then if you add -F presumably you should know what you're doing. Thanks for testing this. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZ1abHEjvBPtnXfVAQJQtAP/XgGgI2z7xUGJlxBGfZiggIEtxRYzJObn TVl/2r7tJ58QCwTzc+eI/m18gcfi85q+hmS1hPc9tjq0ICiqZGjSI9hpSsq0Uqva WXKFscmvnNyZLrhemy8AjHSbA7dKKBGKBmqycjEt26am4LetoCD/HCt44+AaoI3d SIzFFiSKw/4= =4FpY -----END PGP SIGNATURE-----

Martin v. Löwis wrote:
I've a partially related question... why isn't the module structure in an include file .h and is instead in Objects/moduleobject.c ? For the cached lookup optimization I copied the definition but that's surely a bad way to do it.... I however wondered if there were good reasons for module objects for not being published. Andrea

>> > In #1626545, Anton Tropashko requests that object.h should be >> > renamed, because it causes conflicts with other software. ... Guido> Maybe this should be done in a more systematic fashion? E.g. by Guido> giving all "internal" header files a "py_" prefix? Grand Renaming, part deux? ;-) Skip

Guido van Rossum schrieb:
Maybe this should be done in a more systematic fashion? E.g. by giving all "internal" header files a "py_" prefix?
Yet another alternative would be to move all such header files into a py/ directory, so you would refer to them as #include "py/object.h" Any preferences? Regards, Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 3, 2007, at 2:29 PM, Martin v. Löwis wrote:
I think I prefer this, although I'd choose "python/object.h" just for explicitness. But if you go with a header prefix, then the shorter "py_" is fine. FWIW, I tried to do a quick grep around some of our code and I found that the only "internal" header we include is structmember.h. Why is that not part of Python.h again? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZwJ+nEjvBPtnXfVAQL55wP/SxjN9/ncb86KnhRMUf24U6fp+u5JrpN3 irJfi/3tf9iXFtHXPkvkc4hEM9DkF8pa+jYDICG1pZ2J0YQD/AcSuB52WoWDwBtn BIKt1QmJvxgWZLW+dAekWhgSD95laPw+72iCwBvFlIP3+IXtF/Fw9AtuxiGwQzE3 R71j5tZAde4= =nA9B -----END PGP SIGNATURE-----

On Wed, Jan 03, 2007 at 02:54:34PM -0500, Barry Warsaw wrote:
+1 on using the python/*.h subdirectory. +0.2 on renaming only the whined about .h file. +0.1 on using a py_ prefix for all .h files. I prefer the python/*.h subdirectory method. py_ in the filename is ugly and annoying even if it does solve the immediate issue. Other packages that install header files commonly put them all within a named subdirectory. -Greg

On 3-Jan-2007, at 23:17 , Gregory P. Smith wrote:
+1 on using the python/*.h subdirectory.
I'm a bit concerned about the "python/*.h": could it cause trouble in combination with Apple's framework naming convention (#include <QuickTime/Quicktime.h> magically gets the header out of the quicktime framework) and the case-insensitiveness of the Mac filesystem? Will #include "python/blabla.h" always find that file along the -I paths, and not somehow accidentally start looking for /Library/Framework/Python.framework/ Headers/blabla.h? -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I like the idea of renaming the header files, but I expect there is a lot more opportunity for breaking code that you estimate. I did a search on google.com/codesearch and found seven external packages that include Python.h and object.h (before I gave up). I assume we expect people won't include it, because it is also included in object.h. But they do it. Is there documentation that says you shouldn't import it? Jeremy

On 2/25/07, Jeremy Hylton <jeremy@alum.mit.edu> wrote:
So rather than a simple rename, we should probably rename, change all references in the core to use the new name, and make a simple object.h that only does: #include "new_object.h"
I thought somewhere (embedding/extending doc?) it mentions that only Python.h should be included, but if we have a naming convention/directory structure, this becomes more obvious. Doc/ext/extending.tex: To support extensions, the Python API (Application Programmers Interface) defines a set of functions, macros and variables that provide access to most aspects of the Python run-time system. The Python API is incorporated in a C source file by including the header \code{"Python.h"}. (But it may not say nothing else should be included.) n

On 1/3/07, Fred L. Drake, Jr. <fdrake@acm.org> wrote:
Maybe this should be done in a more systematic fashion? E.g. by giving all "internal" header files a "py_" prefix? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 1/3/07, Guido van Rossum <guido@python.org> wrote:
I was thinking the same, and I'm sure Neal Norwitz is/was too (he suggested this a few times in the past, at least outside of python-dev.) There are a few headers that might be in 'legitimate' use right now (as in, there is no way to do what they need to do without including those seemingly internal headers) but personally I think breaking source compatibility and requiring portable code that needs access to those to #if/#ifdef around it, to be a reasonable price to pay. (Only for header files that should really be internal, of course, not ones that are oft-used outside the core.) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Mostly structmember.h and structseq.h, less often code.h, compile.h, frameobject.h, marshal.h. Aside from the ones that are already prefixed with 'py' and not included by Python.h (pythread.h, pyexpat.h maybe?) I'm not sure which should really be public. Both structmember.h and structseq.h are generally useful to extension modules -- I've used both, although I don't think I would have used structseq if I wasn't already quite aware of it. The rest is useful only for extension modules that want to muck about with internals (like profilers, debuggers, custom marshalmunching and nasty extension modules that want to hook into Python internals that are not easily hooked into) and they will have to deal with less backward compatibility at the source and binary level anyway -- let them fix their imports. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On 1/3/07, Thomas Wouters <thomas@python.org> wrote:
Wow, I didn't realize I was that much of a broken record. :-) I don't even remember talking to Thomas about it, only Guido. I definitely would like to see all private header files clearly denoted by their name or directory. I saw Jack's comment about Apple's naming scheme, but I'm ignoring that for the moment. I have bad memories from the Motif days of including everything with one file. I prefer to see includes with the directory. This provides a sort of namespace: #include "python/foo.h" Though, if the user only has to include a single Python.h like currently, this wouldn't make as much sense. I don't recall the same problems in Python that existed when using Motif. Here are some options (python/ can be omitted too): #include "python/public.h" #include "python/internal/foo.h" #include "python/private/foo.h" #include "python/_private.h" I don't really like prefixing with py_ because from a user's perspective I interpret py_ to be a public header that gives me a namespace. I prefer a directory that indicates its intent because it can't be misunderstood. IIRC Guido didn't want to introduce a new directory. In that case my second choice is to prefix the filename with an underscore as a leading underscore often is interpreted as private. Going along with this change I would like to see all identifiers in public header files prefixed with [_]Py. And public header files shouldn't be able to include private header files (by convention). Or we should have some other way of denoting which files must prefix all their identifiers and which can use anything because they are only used in Python code. For example, right now node (struct _node) is exported in node.h in 2.4. I think it moved in 2.5, but it's still exported IIRC. n

Neal Norwitz schrieb:
What is a private header file, and does Python have any? I can see why Modules/sre.h is "private": it won't get installed at all, so users can't include them. For everything in Include, I think users can, and will, include them directly, unless they get them through Python.h. Regards, Martin

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
By private, I mean internal only to python and don't need to prefix their identifiers with Py and are subject to change without backwards compatibility. Include/graminit.h is one example of what I mean. Some others are: bitset.h, grammar.h, opcode.h, metagrammar.h, errcode.h Others are kinda questionable (they have some things that are definitely public, others I'm not so sure about): code.h, parsetok.h, pyarena.h, longintrepr.h, osdefs.h, pgen.h, node.h These are just some examples of what I mean. These may be in include because they are used between two top level directories, but not meant to be exported. There could be other reasons too. n

Neal Norwitz schrieb:
Ah. This seems to be a requirement completely different from the one I'm talking about. By this definition, object.h is *not* an internal header file, yet I want it to be renamed. As for this issue: how about moving all such private header files out of Include entirely? The parser-related ones should go into Parser, for example (grammar.h, bitset.h, graminit.h, metagrammar.h, errcode.h). This would leave us with opcode.h only.
Thomas said that at least code.h must stay where it is. What is the reason that you want them to be renamed? Regards, Martin

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Agreed. I was mixing two things that aren't necessarily related because I see the same possible solution. I'm also using this one example as a good opportunity to clean up more things. Let me try to explain a bit more below.
Sorry, I wasn't trying to imply that these should necessarily be renamed, only that the internal portions be moved elsewhere. I guess I should explain my mental model first which might make things clearer. Then again, I'm tired, so who knows if it will explain anything. :-) I'm a Python embedder and I want to know what's available to me. I look in Include and see a ton of header files. Do I need all these? What do I *need* and what can I *use*? I only want to see the public stuff that is available to me. Thus I want anything that has internal/implementation details/etc out of my sight to reduce my learning curve. I don't ever want to learn about something I won't need nor include anything I won't need. That's one part. Another part of my mental model is that I'm a Python developer and I'm modifying a header file that is implementation specific. I need to share it among different subdiretories (say Python and Objects). So I really need to stick the header file in a common place, Include/ is it. I don't want to export anything, but I don't know if other third party developers will use the header or not. Or maybe I need to include some implementation details in another public header. I'll probably be lazy and just make a single header which has some internal and some public stuff. I want clear rules on when identifiers need to be prefixed. If it's internal (e.g., in an internal directory or prefixed with _), it can have any name and can't be included from any non-internal header. I can also change it in a point release. If anyone uses anything from here, they are on their own. If I see any identifier in a non-internal header, it must be public and therefore prefixed with Py or _Py. The Python headers are pretty good about prefixing most things. But they could be better. I think it gets harder to maintain without the rules though. Finally, by putting everything in directories and always including a directory in the header file, like: #include "python/python.h" #include "python/internal/foo.h" There can never be an include file name collision as what started this thread. It also provides a simple way of demonstrating what's public and what is not. It addresses all my complaints. There are only a few rules and they are simple. But I am addressing several points that are only loosely related which I what I think generated some confusion. Adding the directory also makes clear were the header file comes from. If you see: #include "node.h" you don't know if that's a python node.h, from some other part of the code or a third party library. Not to try to confuse things even more, but I will point out something Google does that is only indirectly related. Google requires importing modules. You aren't supposed to import classes. You wouldn't do: from foo.bar import Message # ... msg = Message(...) You would do: from foo import bar # ... msg = bar.Message(...) This makes it clear where Message comes from, just like adding a python prefix to all header file names makes it clear where the header file lives. Both are good for traceability, though in different ways. This technique makes it easier to manage larger code bases, particularly when there are multiple libraries used. n

Neal Norwitz schrieb:
Ideally, you should look at the documentation. It should have everything you can use, and only that. I know that this currently doesn't work, for two reasons: - the documentation is incomplete, i.e. it omits things that people do use on a regular basis - people read header files, even if the documentation was complete
There could be another standard directory for header files also, like Python.
I don't want to export anything, but I don't know if other third party developers will use the header or not.
I find that debatable. I see no reason not to export everything, unless a stable ABI is also an objective (which it may be). If people really want to get to the internals, they can access structures even if they aren't defined in a header file, by replicating the structure definition in their own code. There should be a "mostly stable" API, certainly, and this is the one that is documented. Other things in the header files aren't "internal", they are just undocumented and thus may change without notice.
I want clear rules on when identifiers need to be prefixed.
Always, unless they are static functions. Even an "internal" function must be prefixed, as you may otherwise get conflicts when embedding Python. At the moment, only the AST exports symbols that aren't properly mangled. [internal symbols]
I can also change it in a point release. If anyone uses anything from here, they are on their own.
No. There shouldn't be any possible ABI breakage in a point release.
As specified, above, it is incompatible with the current API. I think #include <Python.h> should be preserved. I personally see no problem with a single header file, and would prefer that include to indicate all API that we are committed to document and keep "mostly stable". Regards, Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 4, 2007, at 4:17 AM, Martin v. Löwis wrote:
I agree. I don't mind if Python.h is just a wrapper around #includes from python/*.h. I think we should add structmember.h and structseq.h to Python.h and perhaps move everything else into a 'python' subdirectory. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZ0pfnEjvBPtnXfVAQKuyAP+J8Tm3z4am5BOfXCSJIeHsA1tEddeniuM dqSUAPUQUag9WkvkAreQYXu3iRC26e52mJ0B8eceqiuBa16WPILb0CvRFCBoW2fc /FAg4EROlMBhrE/MWVSfGSi76bL+4CwaogmHOnsvyCDEppA420C/8Zkz1VZYiGGd T+Ppo1ZVsHA= =b/Fm -----END PGP SIGNATURE-----

Barry Warsaw schrieb:
For the python subdirectory, there is the issue that the framework includes in OSX magically look for python.framework when searching for python/foo.h, which they find, so that may get us the wrong version. Somebody would have to study the details here, first. Regards, Martin

On Thursday 04 January 2007 11:33, Martin v. Löwis wrote:
If everything public gets included from Python.h, perhaps python/object.h and friends could become pythonX.Y/object.h; I'm not sure this will solve the Mac OS framework magic issue, though, not being a Mac OS developer. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

On 4 Jan, 2007, at 17:56, Fred L. Drake, Jr. wrote:
That would solve the problem, however I don't think there is one. An experiment seems to indicate that the include path is prefered over the magic inclusion of framework headers (see the trace below). I haven't checked yet if the behaviour shown below is intentional, but I'd be surprised if it isn't. $ mkdir include $ mkdir include/Python $ cat > include/Python/object.h <<EOF #error "my header included" EOF $ cat > demo.c <<-EOF #include <Python/object.h> EOF $ $ cc -c demo.c In file included from demo.c:1: /System/Library/Frameworks/Python.framework/Headers/object.h:227: error: parse error before ‘FILE’ /System/Library/Frameworks/Python.framework/Headers/object.h:353: error: parse error before ‘PyType_IsSubtype’ ... more errors removed, this clearly includes a header from the python framework $ $ cc -I include -c t.c In file included from demo.c:1: include/Python/object.h:1:2: error: #error "my error" Therefore moving all headers into a directory named Python would cause no problems users that use the normal way of linking with python and would even allow users to use the python framework as a normal framework. Ronald

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 4, 2007, at 2:36 PM, Ronald Oussoren wrote:
I think that's basically correct: framework includes are searched after normal includes. You might be able to confuse things if you used -F/-framework options, because I believe those are interleaved with -I paths, but then if you add -F presumably you should know what you're doing. Thanks for testing this. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZ1abHEjvBPtnXfVAQJQtAP/XgGgI2z7xUGJlxBGfZiggIEtxRYzJObn TVl/2r7tJ58QCwTzc+eI/m18gcfi85q+hmS1hPc9tjq0ICiqZGjSI9hpSsq0Uqva WXKFscmvnNyZLrhemy8AjHSbA7dKKBGKBmqycjEt26am4LetoCD/HCt44+AaoI3d SIzFFiSKw/4= =4FpY -----END PGP SIGNATURE-----

Martin v. Löwis wrote:
I've a partially related question... why isn't the module structure in an include file .h and is instead in Objects/moduleobject.c ? For the cached lookup optimization I copied the definition but that's surely a bad way to do it.... I however wondered if there were good reasons for module objects for not being published. Andrea

>> > In #1626545, Anton Tropashko requests that object.h should be >> > renamed, because it causes conflicts with other software. ... Guido> Maybe this should be done in a more systematic fashion? E.g. by Guido> giving all "internal" header files a "py_" prefix? Grand Renaming, part deux? ;-) Skip

Guido van Rossum schrieb:
Maybe this should be done in a more systematic fashion? E.g. by giving all "internal" header files a "py_" prefix?
Yet another alternative would be to move all such header files into a py/ directory, so you would refer to them as #include "py/object.h" Any preferences? Regards, Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 3, 2007, at 2:29 PM, Martin v. Löwis wrote:
I think I prefer this, although I'd choose "python/object.h" just for explicitness. But if you go with a header prefix, then the shorter "py_" is fine. FWIW, I tried to do a quick grep around some of our code and I found that the only "internal" header we include is structmember.h. Why is that not part of Python.h again? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZwJ+nEjvBPtnXfVAQL55wP/SxjN9/ncb86KnhRMUf24U6fp+u5JrpN3 irJfi/3tf9iXFtHXPkvkc4hEM9DkF8pa+jYDICG1pZ2J0YQD/AcSuB52WoWDwBtn BIKt1QmJvxgWZLW+dAekWhgSD95laPw+72iCwBvFlIP3+IXtF/Fw9AtuxiGwQzE3 R71j5tZAde4= =nA9B -----END PGP SIGNATURE-----

On Wed, Jan 03, 2007 at 02:54:34PM -0500, Barry Warsaw wrote:
+1 on using the python/*.h subdirectory. +0.2 on renaming only the whined about .h file. +0.1 on using a py_ prefix for all .h files. I prefer the python/*.h subdirectory method. py_ in the filename is ugly and annoying even if it does solve the immediate issue. Other packages that install header files commonly put them all within a named subdirectory. -Greg

On 3-Jan-2007, at 23:17 , Gregory P. Smith wrote:
+1 on using the python/*.h subdirectory.
I'm a bit concerned about the "python/*.h": could it cause trouble in combination with Apple's framework naming convention (#include <QuickTime/Quicktime.h> magically gets the header out of the quicktime framework) and the case-insensitiveness of the Mac filesystem? Will #include "python/blabla.h" always find that file along the -I paths, and not somehow accidentally start looking for /Library/Framework/Python.framework/ Headers/blabla.h? -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

On 1/3/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I like the idea of renaming the header files, but I expect there is a lot more opportunity for breaking code that you estimate. I did a search on google.com/codesearch and found seven external packages that include Python.h and object.h (before I gave up). I assume we expect people won't include it, because it is also included in object.h. But they do it. Is there documentation that says you shouldn't import it? Jeremy

On 2/25/07, Jeremy Hylton <jeremy@alum.mit.edu> wrote:
So rather than a simple rename, we should probably rename, change all references in the core to use the new name, and make a simple object.h that only does: #include "new_object.h"
I thought somewhere (embedding/extending doc?) it mentions that only Python.h should be included, but if we have a naming convention/directory structure, this becomes more obvious. Doc/ext/extending.tex: To support extensions, the Python API (Application Programmers Interface) defines a set of functions, macros and variables that provide access to most aspects of the Python run-time system. The Python API is incorporated in a C source file by including the header \code{"Python.h"}. (But it may not say nothing else should be included.) n
participants (14)
-
"Martin v. Löwis"
-
Andrea Griffini
-
Barry Warsaw
-
Brett Cannon
-
Collin Winter
-
Fred L. Drake, Jr.
-
Gregory P. Smith
-
Guido van Rossum
-
Jack Jansen
-
Jeremy Hylton
-
Neal Norwitz
-
Ronald Oussoren
-
skip@pobox.com
-
Thomas Wouters