Re: [Python-Dev] Private header files (Was: Renaming Include/object.h)
Neal Norwitz schrieb: > 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 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. > 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 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 ___ 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
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] 2.5.1 plans
The current schedule looks like it's shaping up to be: Wed, Jan 24 for 2.5.1c1 Wed Jan 31 for 2.5.1 It would be great if you could comment on some of the bug reports below. I think several already have patches/suggested fixes. These looks like they would be nice to fix:: http://python.org/sf/1579370 Segfault provoked by generators and exceptions http://python.org/sf/1377858 segfaults when using __del__ and weakrefs There is one outstanding issue I was notified of in private mail:: http://python.org/sf/1568240 Tix is not included in 2.5 for Windows It's not clear to me if this should be fixed, but it's got a high priority:: http://python.org/sf/1467929 %-formatting and dicts n -- On 12/25/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > I don't have a schedule in mind for 2.5.1 yet, however we should start > preparing for it. The release will probably happen sometime in > January if everyone is available. The branch has been pretty quiet, > so I'm not expecting too many problems. > > Once we figure out a date for release I'll follow up here. > > If you have any bugs or patches that should be addressed prior to > release, please assign them to me and bump the priority to 9. I'm not > sure that there are any bugs which absolutely must be fixed before > release, though there are a few that would be nice. > > Any other discussion for 2.5.1 necessary? > > 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, 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
On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: 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? 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 <[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 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 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 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
-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
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
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
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. ___ 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
>> > 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
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. ___ 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 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 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. ___ 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
[Python-Dev] Renaming Include/object.h
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 ___ 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] pep-3108.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 3, 2007, at 6:07 AM, M.-A. Lemburg wrote: > Regarding application specific package setups: > > In my experience it's better to have an application specific > sys.path setup function that manages this, rather than trying > to manipulate PYTHONPATH or trying to tweak Python's stdlib > site.py into using some particular way of setting up application > specific paths which then makes interop harder for all > applications using Python, rather than just the few that > require such setups. > > The application can then call this path setup function early > on in the startup phase to make sure that the rest of the > startup and the application's main code then imports the > right modules and packages. Oh, I totally agree MAL. It's what I've done in Mailman for ages. What makes it more complicated is when you have dozens of entry points (read: command line scripts), but it's solvable. I guess when I read "PYTHONPATH" I also read "sys.path", so now that I've slept a little, never mind! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZur2HEjvBPtnXfVAQIZjwP/Zbcz/aUooJtca/apUSkHwfhnTvMOLiiQ uoWOltYJnwqy3S9EYpUoan0rXBVPd04ygWf9tgZiioTaVHAuXYTLL7SikpiQTxge VxLQA6AegHlGMFgtuqTKNYDNeG2B9dlpHbT05ZSVqVaBeWi6E/ap/NNk7ufZ//pD 3F94t07yDaE= =OHMX -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] pep-3108.txt
On 2007-01-03 00:35, Barry Warsaw wrote: > On Jan 2, 2007, at 5:41 PM, M.-A. Lemburg wrote: > >> Note that as side-effect of this it becomes a lot harder to manipulate >> PYTHONPATH to trick Python into loading a standard module from a >> non-standard location, improving security and robustness of the >> Python installations. > > Sometimes though you want to do this, as when you want your application > to ensure it gets a particular version of a standard library module, > regardless of the version of Python being used. And now we're back to > application-specific site-packages ;). Well, I guess that's a rather particular use case and can probably only be safely implemented by the maintainer of the module or package in question ;-) In such (rare) cases, it should be possible to use one of the harder ways to achieve this: * monkey patching the package * using package.__path__ to redirect the in-package search * creating a private copy of the whole package which then has the modified modules and packages in place Regarding application specific package setups: In my experience it's better to have an application specific sys.path setup function that manages this, rather than trying to manipulate PYTHONPATH or trying to tweak Python's stdlib site.py into using some particular way of setting up application specific paths which then makes interop harder for all applications using Python, rather than just the few that require such setups. The application can then call this path setup function early on in the startup phase to make sure that the rest of the startup and the application's main code then imports the right modules and packages. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 03 2007) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
