Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Neal Norwitz [EMAIL PROTECTED] wrote: On 1/3/07, Thomas Wouters [EMAIL PROTECTED] wrote: On 1/3/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 1/3/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: 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. +1 Maybe this should be done in a more systematic fashion? E.g. by giving all internal header files a py_ prefix? 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.) 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. Was any course of action ever decided on for this issue, or was the consensus that it would break too much code? If the latter, what about making the change for Python 3000? Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
Collin Winter schrieb: Was any course of action ever decided on for this issue, or was the consensus that it would break too much code? If the latter, what about making the change for Python 3000? Neither, nor. If a grand renaming is not feasible, I'd atleast do something about object.h for Python 2.6. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 2/25/07, Jeremy Hylton [EMAIL PROTECTED] wrote:
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
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.
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).
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 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?
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote: 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. 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 What do you think? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
Andrea Griffini schrieb: 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. I guess it's included in the C file because that's the easiest way to implement it. AFAICT, it has been that way from the beginning. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
Martin v. Löwis wrote: Neal Norwitz schrieb: 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. What is a private header file, and does Python have any? 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: 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. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: 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. +1 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/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 1/3/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: 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. +1 Maybe this should be done in a more systematic fashion? E.g. by giving all internal header files a py_ prefix? 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 [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 12:38, Guido van Rossum wrote: Maybe this should be done in a more systematic fashion? E.g. by giving all internal header files a py_ prefix? Even better. +42 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wednesday 03 January 2007 14:29, Martin v. Löwis wrote: 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? None here; the goal is the only part I care about. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote: 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? Whatever is easier to make this happen. +1 for either solution from me. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
Thomas Wouters schrieb: (Only for header files that should really be internal, of course, not ones that are oft-used outside the core.) Which are these? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 3, 2007, at 2:29 PM, Martin v. Löwis wrote: 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? 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- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On Wed, Jan 03, 2007 at 02:54:34PM -0500, Barry Warsaw wrote: On Jan 3, 2007, at 2:29 PM, Martin v. L?wis wrote: 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? 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 +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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
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, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Thomas Wouters [EMAIL PROTECTED] wrote: On 1/3/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 1/3/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: 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. +1 Maybe this should be done in a more systematic fashion? E.g. by giving all internal header files a py_ prefix? 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.) 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
Neal Norwitz schrieb: 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Neal Norwitz schrieb: 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. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
