Re: [Python-Dev] Private header files (Was: Renaming Include/object.h)
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote: 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. 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. 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? 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 ___ 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] Private header files (Was: Renaming Include/object.h)
Neal Norwitz schrieb: 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. 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 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. 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. 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. 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 ___ 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 01:42, Brett Cannon wrote: On 1/2/07, M.-A. Lemburg [EMAIL PROTECTED] wrote: +Open Issues +=== + +Consolidate dependent modules together into a single module or package? ... +Consolidate certain modules with similar themes together in a package? +-- ... If you do follow this route, please take the chance to place the whole Python stdlib under a single package. That way we'll avoid name clashes with existing packages and modules now and in the future. That has been suggested before (including by me) and Guido has always shot it down. That's why I left it out of this proposal. Even if it is shot down again, it still deserves to be documented together with the reasons for being shot down. This is a one-in-a-lifetime chance, so it would be sad if it were not taken into account. The extra effort would be minimal - the renaming would have to be done using a script anyway and adding an extra 'from py import ' prefix to the modules wouldn't really make the renaming more complicated ;-) I was about to start writing an open issue on this since the biggest objection from Guido I could find on this topic is http://mail.python.org/pipermail/python-dev/2002-July/026409.html , but then it started to feel like a separate PEP to me. So I think I am going to pass on taking on this topic and let someone else tackle it in a PEP. Sorry, MAL, but I need to worry about my sanity on this one. =) Oh well, it seemed like a perfect fit for the scope of PEP 3108. Guido's reply seems to suggest that he's in favor of introducing a multi-package stdlib structure: I'm rejecting the proposal of a single top-level package named python. You've written that before, but you still haven't given any explanation of why a single package would be worse than a multi-level hierarchy of modules (e.g. grouped by application space). Because a single package doesn't have any other benefits besides getting out of the way from 3rd party developers. At least a proper hierarchy would have the other benefits of grouping. (But better make it a shallow hierarchy! remember Flat is better than nested.) AFAICT, he was only objecting having a single package without any extra restructuring. Then again, the post is from 2002 - so things may have changed. There have been a couple of attempts to reorg the stdlib into packages, but AFAIR, I see, all of them were withdrawn due to the problem of finding a suitable grouping (often enough, a module would be suitable for more than just one functional package, e.g. urllib would fit io as well as net) or lack of support from the developers. Now that we're discussing moving the include files into a subdirectory (for much the same reasons), I think it's time to reboot the discussion of a Python package with or without possible subpackages. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 04 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
Re: [Python-Dev] 2.5.1 plans
On 2007-01-04 07:59, Neal Norwitz wrote: 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. 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 +1 The patch is ready to be applied. The only reason it got delayed was the 2.5 release timing. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 04 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
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] Pydoc Improvements / Rewrite
Ron, I agree that pydoc could benefit a bit from some cleanup. As you point it out, the ability to write quick viewers would be very helpful. I came across that when wanting to develop script on a remote web server for which I only had FTP access: I ended up having to study pydoc more than I wanted in order to be able to build a display-the-doc cgi. However having two different modules might not be needed. Introspection is probably already available in the separate module 'inspect', and what a code pydoc would have to do is model the documentation (as a tree) and offer convenience function to navigate the data. Beside that, there would be sub-modules for the different viewers for the documentation data - the interactive console being just one of the viewers. Finally, I would suspect that an API-breaking modification of the module would need time to be accepted. May be the original author of pydoc is considering changes as well, and joining effort would be possible ? L. PS: I would also not go for a module name deliberately prefixed with _ (as some people might associate that with protected or private objects). ___ 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
It would be nice if this simple fix could be included (main branch and 2.5.1): https://sourceforge.net/tracker/?func=detailaid=1598181group_id=5470atid=105470 [ 1598181 ] subprocess.py: O(N**2) bottleneck I submitted the trivial fix almost two months ago, but apparently nobody feels responsible... Ralf - Original Message From: Neal Norwitz [EMAIL PROTECTED] To: Python Dev python-dev@python.org Sent: Wednesday, January 3, 2007 10:59:15 PM Subject: 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] Private header files (Was: Renaming Include/object.h)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 4, 2007, at 4:17 AM, Martin v. Löwis wrote: 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. 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- ___ 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] Pydoc Improvements / Rewrite
Laurent Gautier wrote: Ron, I agree that pydoc could benefit a bit from some cleanup. As you point it out, the ability to write quick viewers would be very helpful. I came across that when wanting to develop script on a remote web server for which I only had FTP access: I ended up having to study pydoc more than I wanted in order to be able to build a display-the-doc cgi. However having two different modules might not be needed. I think weather it is two modules or more, or a package, is still an open issue. Others have suggested it may be better for it to be package so I'm continuing in that direction. Introspection is probably already available in the separate module 'inspect', and what a code pydoc would have to do is model the documentation (as a tree) and offer convenience function to navigate the data. Beside that, there would be sub-modules for the different viewers for the documentation data - the interactive console being just one of the viewers. Pydoc currently uses functions from the inspect module along with directly accessing attributes and other information where it is available. It's not a replacement for the inspect module. My first attempt used an xml tree to store the information, but to make that work requires also storing a fair amount of meta information in the tree as well. I found parsing the tree and the meta information to be more complex than using an objective approach which is (to me) more readable and easier to extend. But if you want to try it again, please do. You may come up with something far better than I did. Finally, I would suspect that an API-breaking modification of the module would need time to be accepted. I was considering this for python 3.0, but one of the developers suggested it would be nice to have in python 2.6 and to move the discussion here. I think any API issues could be worked out. Are there any programs you know of, (yours?), that import pydoc besides the python console? May be the original author of pydoc is considering changes as well, and joining effort would be possible ? AUTHOR Ka-Ping Yee [EMAIL PROTECTED] CREDITS Guido van Rossum, for an excellent programming language. Tommy Burnette, the original creator of manpy. Paul Prescod, for all his work on onlinehelp. Richard Chamberlain, for the first implementation of textdoc. Ka-Ping reads python-dev but I'm cc'ing this to him just in case. (I Used his python-dev email address since I don't know if the above one is current.) Pydoc is a fairly complex program and it would definitely help if others took a look at various parts and made contributions and or suggestions to making it better. I may have also gotten a bit over my head, but I'm willing to stick it out and try to get it finished with any suggestions (and help) that any one is willing to give me. There are also too many important issues for me to be decided, so this isn't something that can be done in isolation. The download link again is: http://ronadam.com/dl/_pydoc.zip It's not fully functional yet, but does run. Some parts like the command line file output options still need to be reimplemented. Some output formatting still needs to be cleaned up, and the MRO tree parsing section still needs to be put back in. One question that I have at the moment is: * Would it be good to have the KEYWORD and TOPICS info as included data objects or files, and possibly use that to generate the python html (and other) documentation for these? (Instead of the other way around like it is now.) This would eliminate the requirement to install something extra in order for help on these items to work. L. PS: I would also not go for a module name deliberately prefixed with _ (as some people might associate that with protected or private objects). The underscore was just a temporary convenience to avoid the name conflict with the existing module. Weather to reuse the old name or use a new name is still one of the many open issues I think. Ron ___ 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] Private header files (Was: Renaming Include/object.h)
Barry Warsaw schrieb: 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. 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 ___ 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] Private header files (Was: Renaming Include/object.h)
On Thursday 04 January 2007 11:33, Martin v. Löwis wrote: 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. 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 ___ 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
On 1/4/07, Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote: It would be nice if this simple fix could be included (main branch and 2.5.1): https://sourceforge.net/tracker/?func=detailaid=1598181group_id=5470atid=105470 [ 1598181 ] subprocess.py: O(N**2) bottleneck I submitted the trivial fix almost two months ago, but apparently nobody feels responsible... I just reviewed the patch, which should help it get accepted. -Mike ___ 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 1/4/07, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2007-01-03 01:42, Brett Cannon wrote: On 1/2/07, M.-A. Lemburg [EMAIL PROTECTED] wrote: +Open Issues +=== + +Consolidate dependent modules together into a single module or package? ... +Consolidate certain modules with similar themes together in a package? +-- ... If you do follow this route, please take the chance to place the whole Python stdlib under a single package. That way we'll avoid name clashes with existing packages and modules now and in the future. That has been suggested before (including by me) and Guido has always shot it down. That's why I left it out of this proposal. Even if it is shot down again, it still deserves to be documented together with the reasons for being shot down. This is a one-in-a-lifetime chance, so it would be sad if it were not taken into account. The extra effort would be minimal - the renaming would have to be done using a script anyway and adding an extra 'from py import ' prefix to the modules wouldn't really make the renaming more complicated ;-) I was about to start writing an open issue on this since the biggest objection from Guido I could find on this topic is http://mail.python.org/pipermail/python-dev/2002-July/026409.html , but then it started to feel like a separate PEP to me. So I think I am going to pass on taking on this topic and let someone else tackle it in a PEP. Sorry, MAL, but I need to worry about my sanity on this one. =) Oh well, it seemed like a perfect fit for the scope of PEP 3108. I know, but I honestly just don't have the energy to deal with it. If you want to spear-head the discussion and help me add it to the PEP, then that's great. Guido's reply seems to suggest that he's in favor of introducing a multi-package stdlib structure: I'm rejecting the proposal of a single top-level package named python. You've written that before, but you still haven't given any explanation of why a single package would be worse than a multi-level hierarchy of modules (e.g. grouped by application space). Because a single package doesn't have any other benefits besides getting out of the way from 3rd party developers. At least a proper hierarchy would have the other benefits of grouping. (But better make it a shallow hierarchy! remember Flat is better than nested.) AFAICT, he was only objecting having a single package without any extra restructuring. Yep. PEP 3108 does have some basic package suggestions in the Open Issues section and people seem to support them. I will be making a separate push for them on python-3000 once the whole discussion of what modules to remove has settled down. Then again, the post is from 2002 - so things may have changed. Maybe. There have been a couple of attempts to reorg the stdlib into packages, but AFAIR, I see, all of them were withdrawn due to the problem of finding a suitable grouping (often enough, a module would be suitable for more than just one functional package, e.g. urllib would fit io as well as net) or lack of support from the developers. Yep, that's what has happened. Now that we're discussing moving the include files into a subdirectory (for much the same reasons), I think it's time to reboot the discussion of a Python package with or without possible subpackages. Well, perhaps other people want to show support if they like the idea? I am personally split down the middle either way. -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] Private header files (Was: Renaming Include/object.h)
On 4 Jan, 2007, at 17:56, Fred L. Drake, Jr. wrote: On Thursday 04 January 2007 11:33, Martin v. Löwis wrote: 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. 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. 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 -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/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic 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] Private header files (Was: Renaming Include/object.h)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 4, 2007, at 2:36 PM, Ronald Oussoren wrote: On 4 Jan, 2007, at 17:56, Fred L. Drake, Jr. wrote: On Thursday 04 January 2007 11:33, Martin v. Löwis wrote: 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. 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. 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. 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- ___ 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
Brett Cannon wrote: [ ... ] Yep. PEP 3108 does have some basic package suggestions in the Open Issues section and people seem to support them. I will be making a separate push for them on python-3000 once the whole discussion of what modules to remove has settled down. Then again, the post is from 2002 - so things may have changed. Maybe. There have been a couple of attempts to reorg the stdlib into packages, but AFAIR, I see, all of them were withdrawn due to the problem of finding a suitable grouping (often enough, a module would be suitable for more than just one functional package, e.g. urllib would fit io as well as net) or lack of support from the developers. Yep, that's what has happened. I can't believe that we need to be flummoxed by the necessity of having the same package appear at two (or more!) different places in the package naming hierarchy. I suspect lack of support is more due to developers feeling there are more profitable ways to spend their time. Now that we're discussing moving the include files into a subdirectory (for much the same reasons), I think it's time to reboot the discussion of a Python package with or without possible subpackages. Well, perhaps other people want to show support if they like the idea? I am personally split down the middle either way. It would be an excellent idea to clean up the standard library space. It should be possible in most cases to provide backwards-compatible implementations of the current modules (at least the pure Python ones) by doing an import * from the appropriate new-style package. Some such compatibility mechanism will be essential if the re-org is to happen in an acceptable way before Py3k. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com ___ 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
On Thu, Jan 04, 2007 at 10:22:54AM -0800, Mike Klaas wrote: [ 1598181 ] subprocess.py: O(N**2) bottleneck I submitted the trivial fix almost two months ago, but apparently nobody feels responsible... Is Peter Astrand still actively maintaining the module? I've been assigning subprocess bugs to him on the theory that he'll fix them. If he's not around, we can apply patches to subprocess. (The problem with subprocess in particular would be the difficulty of testing changes that affect both Windows and POSIX code; I think relatively few developers use both Windows and Unix.) We should also try to make an effort to go through the tracker and look for bug fixes and patches suitable for 2.5.1. --amk ___ 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] Pydoc Improvements / Rewrite
Hi Ron and Laurent, I welcome attempts to improve pydoc (especially since I don't have much time to work on improving it myself). I definitely agree that moving to CSS is long overdue, though I would like some input on the style of the produced pages. It's probably a good idea to explain how pydoc got to be the way that it is. The module boundary between inspect and pydoc is a pretty clear one, intended to isolate pydoc from future changes to Python's introspection features (such as attributes on internal types like frames and functions). On the other hand, I've often seen the question of why pydoc does both text and HTML generation instead of generating some intermediate data structure from which both kinds of output are produced. The answer is: I tried it. The result turned out to be longer than I expected and needlessly more complicated than what we have now. It may be that a better job could have been done, but I think there is a rational basis for why it turned out that way. The Python objects themselves already are a data structure containing all of the information we need. I discovered that translating this data structure into another data structure and then producing text or HTML was more work than simply producing text or HTML. With CSS, the last step gets even easier and so the intermediate stage becomes even less necessary. Also, the intermediate step required me to essentially invent an API, and I decided that I trusted the stability of Python's API more than that of some API I invented just for this. This is not to say that text and HTML generation can't be separated; it's just a caution against attempting to overgeneralize by creating an intermediate format. I'm glad you backed away from XML (or I'd have warned you that processing the XML would be a lot of extra work). The inspect module was intended to pull out as much as possible of the extraction functionality that's shared by the text and HTML documentation generators. But pydoc is still big. At the time I was proposing pydoc for addition to the standard library, I didn't want to pollute the top-level module namespace with too many names, so I tried hard to minimize the number of modules. And of course it has grown since then with bits of new functionality and support for new language features in Python. But now if a package is being considered, it makes sense to split out some of the pieces (as you have done), such as the web server, the search function, and the interactive interpreter help prompt. It may even enable pydoc to provide search from the interactive help prompt, which would be a nice feature! The package could contain several modules for ease of maintenance, while still providing a single, convenient command for running pydoc from the Unix prompt. -- ?!ng ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 418 open ( +5) / 3522 closed ( +1) / 3940 total ( +6) Bugs: 959 open (+13) / 6405 closed ( +5) / 7364 total (+18) RFE : 250 open ( +2) / 245 closed ( -1) / 495 total ( +1) New / Reopened Patches __ update to PEP 344 - exception attributes (2007-01-02) CLOSED http://python.org/sf/1626538 opened by Jim Jewett backticks will not be used at all (2007-01-03) http://python.org/sf/1627052 opened by Jim Jewett Fix for #1601399 (urllib2 does not close sockets properly) (2007-01-03) http://python.org/sf/1627441 opened by John J Lee Win32: Fix build when you have TortoiseSVN but no .svn/* (2007-01-04) http://python.org/sf/1628061 opened by Larry Hastings Win32: Add bytesobject.c to pythoncore.vcproj (2007-01-04) http://python.org/sf/1628062 opened by Larry Hastings socket.readline() interface doesn't handle EINTR properly (2007-01-04) http://python.org/sf/1628205 opened by Maxim Sobolev Patches Closed __ update to PEP 344 - exception attributes (2007-01-02) http://python.org/sf/1626538 closed by ping New / Reopened Bugs ___ sqlite3 documentation omits: close(), commit(), autocommit (2006-12-30) http://python.org/sf/1625205 opened by kitbyaydemir re module documentation on search/match is unclear (2006-12-31) http://python.org/sf/1625381 opened by Richard Boulton 'imp' documentation does not mention that lock is re-entrant (2006-12-31) http://python.org/sf/1625509 opened by Dustin J. Mitchell add ability to specify name to os.fdopen (2007-01-01) http://python.org/sf/1625576 opened by Mark Diekhans 'Installing Python Modules' does not work for Windows (2007-01-02) http://python.org/sf/1626300 opened by Christopher Lambacher Would you mind renaming object.h to pyobject.h? (2007-01-02) http://python.org/sf/1626545 opened by Anton Tropashko posixmodule.c leaks crypto context on Windows (2007-01-03) http://python.org/sf/1626801 opened by Yitz Gale website issue reporter down (2007-01-03) http://python.org/sf/1627036 opened by Jim Jewett mention side-lists from python-dev description (2007-01-03) http://python.org/sf/1627039 opened by Jim Jewett xml.dom.minidom parse bug (2007-01-03) CLOSED http://python.org/sf/1627096 opened by Pierre Imbaud xml.dom.minidom parse bug (2007-01-03) CLOSED http://python.org/sf/1627244 opened by Pierre Imbaud an extra comma in condition command crashes pdb (2007-01-03) http://python.org/sf/1627316 opened by Ilya Sandler Typo in module index for Carbon.CarbonEvt (2007-01-03) CLOSED http://python.org/sf/1627373 opened by Brett Cannon Status bar on OSX garbled (2007-01-03) http://python.org/sf/1627543 opened by sigzero RotatingFileHandler cannot recover from failed doRollover() (2007-01-03) http://python.org/sf/1627575 opened by Forest Wilkinson documentation error for startswith string method (2007-01-04) CLOSED http://python.org/sf/1627690 opened by Keith Briggs plat-mac videoreader.py auido format info (2007-01-04) http://python.org/sf/1627952 opened by Ryan Owen documentation error for startswith string method (2007-01-04) http://python.org/sf/1627956 opened by Keith Briggs Bugs Closed ___ test_logging hangs on cygwin (2006-04-06) http://python.org/sf/1465643 closed by sf-robot xml.dom.minidom parse bug (2007-01-03) http://python.org/sf/1627096 closed by loewis xml.dom.minidom parse bug (2007-01-03) http://python.org/sf/1627244 closed by nnorwitz Typo in module index for Carbon.CarbonEvt (2007-01-03) http://python.org/sf/1627373 closed by nnorwitz documentation error for startswith string method (2007-01-04) http://python.org/sf/1627690 closed by loewis Logging problem on Windows XP (2006-09-27) http://python.org/sf/1566280 closed by loewis New / Reopened RFE __ smarter temporary file object (2001-04-12) http://python.org/sf/415692 reopened by gvanrossum optparse store action should not gobble up next option (2007-01-03) http://python.org/sf/1627266 opened by Raghuram Devarakonda ___ 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] Pydoc Improvements / Rewrite
Ka-Ping Yee wrote: Hi Ron and Laurent, I welcome attempts to improve pydoc (especially since I don't have much time to work on improving it myself). I definitely agree that moving to CSS is long overdue, though I would like some input on the style of the produced pages. Additional input would be good. The html output I used is nearly pure nested definition lists with CSS styling to set the fonts, borders, and indents. It was A bit tricky in some places to keep it looking like the current pydoc pages. My mental target was something that would both look good printed and also fit in with Pythons current web site design while not changing it too much. Changing the CSS file to produce other output styled pages should not be that difficult. A little experimenting would be good in order to find where additional style tags in the html code may be needed. It's probably a good idea to explain how pydoc got to be the way that it is. The module boundary between inspect and pydoc is a pretty clear one, intended to isolate pydoc from future changes to Python's introspection features (such as attributes on internal types like frames and functions). On the other hand, I've often seen the question of why pydoc does both text and HTML generation instead of generating some intermediate data structure from which both kinds of output are produced. The answer is: I tried it. The result turned out to be longer than I expected and needlessly more complicated than what we have now. It may be that a better job could have been done, but I think there is a rational basis for why it turned out that way. Yes, I found it was a trade off from one type of complexity to another. And I didn't like importing something that will probably go through more changes like xmltree. The Python objects themselves already are a data structure containing all of the information we need. I discovered that translating this data structure into another data structure and then producing text or HTML was more work than simply producing text or HTML. With CSS, the last step gets even easier and so the intermediate stage becomes even less necessary. Also, the intermediate step required me to essentially invent an API, and I decided that I trusted the stability of Python's API more than that of some API I invented just for this. This is not to say that text and HTML generation can't be separated; it's just a caution against attempting to overgeneralize by creating an intermediate format. I'm glad you backed away from XML (or I'd have warned you that processing the XML would be a lot of extra work). The inspect module was intended to pull out as much as possible of the extraction functionality that's shared by the text and HTML documentation generators. But pydoc is still big. At the time I was proposing pydoc for addition to the standard library, I didn't want to pollute the top-level module namespace with too many names, so I tried hard to minimize the number of modules. And of course it has grown since then with bits of new functionality and support for new language features in Python. And it will continue to grow as python does. Hopefully we can make the process of supporting new language features easier. But now if a package is being considered, it makes sense to split out some of the pieces (as you have done), such as the web server, the search function, and the interactive interpreter help prompt. It may even enable pydoc to provide search from the interactive help prompt, which would be a nice feature! I think that could be done without too much trouble. It only takes adding a new allcaps word FIND something or SEARCH something, in addition to KEYWORDS and TOPICS. The package could contain several modules for ease of maintenance, while still providing a single, convenient command for running pydoc from the Unix prompt. I was thinking of two convenient entry points. One for text and the interactive console and one for html, and the web browser interface. pyhelp and pydoc respectfully. There is also the possibility of splitting it into two much smaller packages, one for the command line and interactive help console. No html stuff or server stuff here. This could be better controlled and maintained as it's used in pythons console. Another plus is it will be easier to maintain as well. The other package (or module) would be an example of how to extend or build an application, an html formatter and help browser in this case, from the console help package. Cheers, Ron ___ 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] Pydoc Improvements / Rewrite
Ron Adam wrote: Improving pydoc has been suggested before by me and others. I've been working on a version that is probably 80% done and would like to get feed back at this point to determine if I'm approaching this in the best way. Just asking--are you going in a PEP-287-ly way as you work? If not, would your work make PEP 287 easier to implement? For those of us without eidetic memories, PEP 287 is use reStructuredText for docstrings: http://www.python.org/dev/peps/pep-0287/ Cheers, /larry/ ___ 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] crashing on shutdown due to warning at shutdown
I fixed the crash that was due to raising a warning on shutdown. I have heard about crashes at shutdown and wonder if this was the cause. There might be similar bugs lurking that assume PyModule_GetDict() always returns a valid pointer. It doesn't, it can return NULL. I'm not sure if the original problem existed or not, but after this fix on shutdown, I see: warning: DBTxn aborted in destructor. No prior commit() or abort(). I don't know if this is a real problem, a test problem, or what. 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] Pydoc Improvements / Rewrite
Larry Hastings wrote: Just asking--are you going in a PEP-287-ly way as you work? If not, would your work make PEP 287 easier to implement? Pydoc does no reformatting or changes to doc strings. They are displayed as is in plain text. About the only formatting that is done is to wrap long lines a bit better, such as 100 character length lines on a 80 character (or less) console window. In those cases, it tries to maintain the indent and break lines on white space. The html pages produced also makes html, rfc, and pep referfences into links. One of the goals is to make it easer to use it as a base for generating other types of formats. So it should also make it easier for someone (else) to implement a PEP-287 extended version for their own needs. For those of us without eidetic memories, PEP 287 is use reStructuredText for docstrings: http://www.python.org/dev/peps/pep-0287/ Thanks for the link. PEP 287 looks to be fairly general in that it expresses a general desire rather than a specification. Ron ___ 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] Pydoc Improvements / Rewrite
Ron Adam wrote: Larry Hastings wrote: For those of us without eidetic memories, PEP 287 is use reStructuredText for docstrings: http://www.python.org/dev/peps/pep-0287/ Thanks for the link. PEP 287 looks to be fairly general in that it expresses a general desire rather than a specification. Apologies for the digression, but I have a comment on this. Rather than fixing on a standard markup, I would like to see support for a __markup__ module variable which specifies the specific markup language that is used in that module. Doc processors could inspect that variable and then load the appropriate markup translator. Why? Because its hard to get everyone to agree on which markup language is best for documentation. I personally think that reStructuredText is not a good choice, because I want to add markup that adds semantic information, whereas reStructuredText deals solely with presentation and visual appearance. (In other words, I'd like to be able to define machine-readable metadata that identifies parameters, return values, and exceptions -- not just hyperlinks and text styles.) Having used a lot of different documentation markup languages, and written a few of them, I prefer non-invasive semantic markup as seen in markup processors such as Doc-o-matic and NaturalDocs. (By non-invasive, I mean that the markup doesn't detract in any way from the readability of the marked-up text. Doc-o-matic's markup language is very powerful, and yet unless you know what you are looking for you'd think its just regular prose.) I have a prototype (called DocLobster) which does similar types of processing on Python docstrings, but I haven't publicized it because I didn't feel like competing against ReST. However, I realize that I'm in the minority with this opinion; I don't want to force anyone to conform to my idea of markup, but at the same time I'd prefer not to have other people dictate my choice either. Instead, what I'd like to see is a way for multiple markup languages to coexist and compete with each other on a level playing field, instead of one being chosen as the winner. -- Talin ___ 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] crashing on shutdown due to warning at shutdown
On Thu, Jan 04, 2007 at 09:35:16PM -0800, Neal Norwitz wrote: I fixed the crash that was due to raising a warning on shutdown. I have heard about crashes at shutdown and wonder if this was the cause. There might be similar bugs lurking that assume PyModule_GetDict() always returns a valid pointer. It doesn't, it can return NULL. I'm not sure if the original problem existed or not, but after this fix on shutdown, I see: warning: DBTxn aborted in destructor. No prior commit() or abort(). I don't know if this is a real problem, a test problem, or what. n Its a courtesy warning, it should not cause harm. could it possibly be from Lib/bsddb/test/test_1413192.py which makes no attempt at cleaning up on purpose? -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] Pydoc Improvements / Rewrite
Ron Adam wrote: Thanks for the link. PEP 287 looks to be fairly general in that it expresses a general desire rather than a specification. I thought it was pretty specific. I'd summarize PEP 287 by quoting entry #1 from its goals of this PEP section: * To establish reStructuredText as a standard structured plaintext format for docstrings (inline documentation of Python modules and packages), PEPs, README-type files and other standalone documents. Talin wrote: Rather than fixing on a standard markup, I would like to see support for a __markup__ module variable which specifies the specific markup language that is used in that module. Doc processors could inspect that variable and then load the appropriate markup translator. I guess I'll go for the whole-hog +1.0 here. I was going to say +0.8, citing There should be one---and preferably only one---obvious way to do it.. But I can see organizations desiring something besides ReST, like if they already had already invested in their own internal standardized markup language and wanted to use that. This makes the future clear; the default __markup__ in 2.6 would be plain, so that all the existing docstrings work unmodified. At which point PEP 287 becomes write a ReST driver for the new pydoc. Continuing my dreaming here, Python 3000 flips the switch so that the default __markup__ is ReST, and the docstrings that ship with Python are touched up to match---or set explicitly to plain if some strange necessity required it. (And when do you unveil DocLobster?) Cheers, /larry/ ___ 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] kill the cbsoutdoor.co.uk autoresponder
Whoever is subscribed to python-dev with a broken corporate autoresponder that sends everyone who posts to the list this useless response multiple times please unsubscribe yourself. Its highly annoying and entirely useless since its not even identifying the list subscriber(s) deserving the blame. -g On Fri, Jan 05, 2007 at 06:28:35AM +, [EMAIL PROTECTED] wrote: Dear Recipient, We have now changed our company name to CBS Outdoor Limited. My new email address is therefore [EMAIL PROTECTED] Your email has been redirected but please amend your address book accordingly. Thank you. CBS Outdoor Limited [EMAIL PROTECTED] www.cbsoutdoor.co.uk The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed, and may also be privileged. If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error, please e-mail the sender by replying to this message. CBS Outdoor Ltd reserves the right to monitor e-mail communications from external/internal sources for the purposes of ensuring correct and appropriate use of CBS Outdoor facilities. ___ 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] Pydoc Improvements / Rewrite
Larry Hastings wrote: Ron Adam wrote: Thanks for the link. PEP 287 looks to be fairly general in that it expresses a general desire rather than a specification. I thought it was pretty specific. I'd summarize PEP 287 by quoting entry #1 from its goals of this PEP section: * To establish reStructuredText as a standard structured plaintext format for docstrings (inline documentation of Python modules and packages), PEPs, README-type files and other standalone documents. Talin wrote: Rather than fixing on a standard markup, I would like to see support for a __markup__ module variable which specifies the specific markup language that is used in that module. Doc processors could inspect that variable and then load the appropriate markup translator. I guess I'll go for the whole-hog +1.0 here. I was going to say +0.8, citing There should be one---and preferably only one---obvious way to do it.. But I can see organizations desiring something besides ReST, like if they already had already invested in their own internal standardized markup language and wanted to use that. This makes the future clear; the default __markup__ in 2.6 would be plain, so that all the existing docstrings work unmodified. At which point PEP 287 becomes write a ReST driver for the new pydoc. Continuing my dreaming here, Python 3000 flips the switch so that the default __markup__ is ReST, and the docstrings that ship with Python are touched up to match---or set explicitly to plain if some strange necessity required it. (And when do you unveil DocLobster?) Well, I'd be more interested in working on it once there's something to plug it into - I didn't really want to write a whole pydoc replacement, just a markup transformer. One issue that needs to be worked out, however, is the division of responsibility between markup processor and output formatter. Does a __markup__ plugin do both jobs, or does it just do parsing, and leave the formatting of output to the appropriate HTML / text output module? How does the HTML output module know how to handle non-standard metadata? Let me give an example: Suppose you have a simple markup language that has various section tags, such as Author, See Also, etc.: Description: A long description of this thing whatever it is. Parameters: fparam - the first parameter sparam - the second parameter Raises: ArgumentError - when invalid arguments are passed. Author: Someone See Also: PyDoc ReST So the parser understands these various section headings - how does it tell the HTML output module that 'Author' is a section heading? Moreover, in the case of Parameters and Exceptions, the content of the section is parsed as a table (parameter, description) which is stored as a list of tuples, whereas the content of the Description section is just a long string. I guess the markup processor has to deliver some kind of DOM tree, which can be rendered either into text or into HTML. CSS can take over from that point on. -- Talin ___ 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
