Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
However, I think people ask much too often for a debugging build; in many cases, they could work happily with a release build that supports debugging. Depending on the problem you try to solve, you may or may not need debug information for pythonxy.dll as well, or just for your extension module. While that is true in theory, I often find it is not the case in practice, generally due to the optimizer. Depending on what magic the compiler has done, it can be very difficult to set breakpoints (conditional or otherwise), inspect variable values, etc. It is useful in some cases, but very often I find myself falling back to a debug build after attempting to debug a local release build. I think there are several other cases in distutils to support special cases (e.g. the DISTUTILS_USE_SDK environment variable); if people want to see their setup supported, AND ARE WILLING TO CONTRIBUTE: more power to them. Yes, but I believe its also important to solicit feedback on the best way to achieve their aims. In this particular case, I believe it would have been misguided for me to simply check in whatever was necessary to have distutils work from the PCBuild8 directory. I hope it is clear that I am willing to contribute the outcome of these discussions... Cheers, Mark ___ 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] The docs, reloaded
Hoi,
Fred L. Drake, Jr. fdrake at acm.org writes:
On Monday 21 May 2007, A.M. Kuchling wrote:
Disadvantages:
* reST markup isn't much simpler than LaTeX.
* reST doesn't support nested markup, which is used in the current
documentation.
For a lightweight markup language that is human readable (which rst certainly
is) the syntax is surprisingly powerful. You can nest any block tag and I'm not
sure how often you have to nest roles and stuff like that. The goal of the new
docs is a less complex syntax and currently nothing beats reStructuredText in
terms of readability and possibilities.
rst is simpler than latex:
LaTeX:
\item[\code{*?}, \code{+?}, \code{??}] The \character{*},
\character{+}, and \character{?} qualifiers are all \dfn{greedy}; they
match as much text as possible. Sometimes this behaviour isn't
desired; if the RE \regexp{.*} is matched against
\code{'H1title/H1'}, it will match the entire string, and not just
\code{'H1'}. Adding \character{?} after the qualifier makes it
perform the match in \dfn{non-greedy} or \dfn{minimal} fashion; as
\emph{few} characters as possible will be matched. Using \regexp{.*?}
in the previous expression will match only \code{'H1'}.
Here the same in rst:
``*?``, ``+?``, ``??``
The ``'\*'``, ``'+'``, and ``'?'`` qualifiers are all :dfn:`greedy`;
they match as much text as possible. Sometimes this behaviour isn't
desired; if the RE :regexp:`.\*` is matched against
``'H1title/H1'``, it will match the entire string, and not just
``'H1'``. Adding ``'?'`` after the qualifier makes it perform the
match in :dfn:`non-greedy` or :dfn:`minimal` fashion; as *few*
characters as possible will be matched. Using :regexp:`.\*?` in the
previous expression will match only ``'H1'``.
Regards,
Armin
___
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] The docs, reloaded
Armin Ronacher schrieb: Hoi, Fred L. Drake, Jr. fdrake at acm.org writes: On Monday 21 May 2007, A.M. Kuchling wrote: Disadvantages: * reST markup isn't much simpler than LaTeX. * reST doesn't support nested markup, which is used in the current documentation. For a lightweight markup language that is human readable (which rst certainly is) the syntax is surprisingly powerful. You can nest any block tag and I'm not sure how often you have to nest roles and stuff like that. The goal of the new docs is a less complex syntax and currently nothing beats reStructuredText in terms of readability and possibilities. Also, I believe there are efforts within docutils to make a limited amount of nested inline markup possible. Lea will probably be able to provide details. cheers, Georg ___ 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] The docs, reloaded
Fred L. Drake, Jr. schrieb: On Monday 21 May 2007, [EMAIL PROTECTED] wrote: Take a look at http://www.webfast.com/modindex/. It records request counts for the various pages and presents the most frequently requested pages in a section at the top of the page. I can make the script available if anyone wants it (it uses Myghty - Mason in Python.) This is very cool. ;-) Indeed, it would be a great addition! Georg ___ 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] Adventures with x64, VS7 and VS8 on Windows
Hi Mark, +1 from me. I think this is simply a bug introduced with the UCS4 patches in Python 2.2. unicodeobject.h already has this code: #ifndef PY_UNICODE_TYPE /* Windows has a usable wchar_t type (unless we're using UCS-4) */ # if defined(MS_WIN32) Py_UNICODE_SIZE == 2 # define HAVE_USABLE_WCHAR_T # define PY_UNICODE_TYPE wchar_t # endif # if defined(Py_UNICODE_WIDE) # define PY_UNICODE_TYPE Py_UCS4 # endif #endif But for some reason, pyconfig.h defines: /* Define as the integral type used for Unicode representation. */ #define PY_UNICODE_TYPE unsigned short /* Define as the size of the unicode type. */ #define Py_UNICODE_SIZE SIZEOF_SHORT /* Define if you have a useable wchar_t type defined in wchar.h; useable means wchar_t must be 16-bit unsigned type. (see Include/unicodeobject.h). */ #if Py_UNICODE_SIZE == 2 #define HAVE_USABLE_WCHAR_T #endif disabling the default settings in the unicodeobject.h. Yes, that does appear strange. The following patch works for me, keeps Python building and appears to solve my problem. Any objections? Looks fine to me. Mark Index: pyconfig.h === --- pyconfig.h (revision 55487) +++ pyconfig.h (working copy) @@ -491,22 +491,13 @@ /* Define if you want to have a Unicode type. */ #define Py_USING_UNICODE -/* Define as the integral type used for Unicode representation. */ -#define PY_UNICODE_TYPE unsigned short - /* Define as the size of the unicode type. */ -#define Py_UNICODE_SIZE SIZEOF_SHORT +/* This is enough for unicodeobject.h to do the right thing on Windows. */ +#define Py_UNICODE_SIZE 2 -/* Define if you have a useable wchar_t type defined in wchar.h; useable - means wchar_t must be 16-bit unsigned type. (see - Include/unicodeobject.h). */ -#if Py_UNICODE_SIZE == 2 -#define HAVE_USABLE_WCHAR_T - /* Define to indicate that the Python Unicode representation can be passed as-is to Win32 Wide API. */ #define Py_WIN_WIDE_FILENAMES -#endif /* Use Python's own small-block memory-allocator. */ #define WITH_PYMALLOC 1 ___ 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/mal%40egenix.com -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 22 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,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Adventures with x64, VS7 and VS8 on Windows
-Original Message- From: Martin v. Löwis [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 05:33 To: Steve Holden Cc: Kristján Valur Jónsson; Mark Hammond; [EMAIL PROTECTED]; python-dev@python.org Subject: Re: Adventures with x64, VS7 and VS8 on Windows Addressing only the issues of PCBuild8 and 64-bit architectures, I have tried to establish free buildbot support for the 64-bit architectures without any real success. Should the PSF be considering paying for infrastructure that will support 64-bit build reporting? You can bring it up to the board, of course. However, given that all other buildbot machines were contributed by volunteers, the fact that nobody volunteers to contribute buildbot machines for PCbuild8 indicates that there is not a lot of interest in that build infrastructure. Most people just install whatever it is that they are offered to download. For me, the most compelling reason to provide the new builds is the 15% performance benefit. If there are no technical and corporate difficulties, such as firewalls and security, I am sure that CCP can provide a VisualStudio2005 buildbot for our needs. Wasn't there some issue that each buildbot can only provide a single build? Here is a place where cross-compilation comes into its own again. Kristjan ___ 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] Adventures with x64, VS7 and VS8 on Windows
-Original Message- Nobody proposed to ditch cross-compilation. I very much like cross-compilation, I do all Itanium and AMD64 in cross-compilation. I just want the *file structure* of the output to be the very same for all architectures, meaning that they can't coexist in a single source directory. Surely there are differences between architectures? PC uses MSI after all. Why can't linux be under trunk/linux and pc 86 under trunk/pcbuild8/win32PGO and 64 under trunk/pcbuild8/x64pgo? We shouldn't let bad tools keep us from new ways of doing things, rather we should fix and update the tools. No, you use two checkouts, of course. That´s just silly. And two visual studios open, and edit the file in two places too? I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier. No matter what the next compiler is (VS 2005 or VS 2007/2008), it's still *a lot* of work until the VS 2005 build can be used for releasing Python. For example, there is no support for the SxS installation of msvcr8.dll, using the MSI merge module. Well, there is some work, which is why I am proposing the Europython sprint to do it. But we are almost there. And that work will be useful for Orcas, when that comes along. And btw, there is no need to install the msvcr8.dll. We can distribute them as a private assembly. then they (and the manifest) exist in the same directory as python2x.dll. This is a supported distribution mode and how we distribute the runtime with EVE. Not sure whether anything really is needed. Python works fine on Vista. If you are an administrator. A limited user will have problems installing it and then running it. 1) supplying python.dll as a Side By Side assembly What would that improve? Well, it should reduce dll-hell problems of applications that ship with python2x.dll. You ship with and link to your own and tested dll. We have some concerns here, for example, now that we are moving away from embedding python in our blue.dll and using python25.dll directly, that this exposes a vulnerability to the integrity of the software. 2) Changing python install locations To conform with Windows rules and get a Vista approved logo. Install in the ProgramFiles folder. Just as C does. Ah, and this also means that we could install both 32 bit and 64 bit versions, another plus. 3) Supporting shadow libraries, where .pyc files end up in a different hierarchy from the .py files. (useful for many things beside VISTA) Yes, and people had written PEPs for it which failed due to lack of follow up. Interesting. We are definitely interested in that. You see, Someone installs a game or accounting software using vista. He then runs as a limited user. Python insists on saving its .pyc files in the installation folder, but this is not something that is permitted on Vista. 4) Signing the python dlls and executables Hmm. Again, easing the installation experience for vista users. So that they don't get a red box about an unknown application requiring administrator privileges. Sure, and have they reported problems with Python on Vista (problems specific to Vista?) Certainly. We are working on them, of course. Chiefly, we have had to change where we save all kinds of temporary files. And we have to be careful that all our .py files ship as .pyc files. And we are versioning, and signing all executables, providing user level manifests and fixing up the install processes to be more compliant. I am just saying that this is something that a standard python distro might want to do too. Kristjan ___ 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] The docs, reloaded
Armin Ronacher writes:
rst is simpler than latex:
LaTeX:
\item[\code{*?}, \code{+?}, \code{??}] The \character{*},
\character{+}, and \character{?} qualifiers are all \dfn{greedy}; they
match as much text as possible. Sometimes this behaviour isn't
desired; if the RE \regexp{.*} is matched against
\code{'H1title/H1'}, it will match the entire string, and not just
\code{'H1'}. Adding \character{?} after the qualifier makes it
perform the match in \dfn{non-greedy} or \dfn{minimal} fashion; as
\emph{few} characters as possible will be matched. Using \regexp{.*?}
in the previous expression will match only \code{'H1'}.
Here the same in rst:
``*?``, ``+?``, ``??``
The ``'\*'``, ``'+'``, and ``'?'`` qualifiers are all :dfn:`greedy`;
they match as much text as possible. Sometimes this behaviour isn't
desired; if the RE :regexp:`.\*` is matched against
``'H1title/H1'``, it will match the entire string, and not just
``'H1'``. Adding ``'?'`` after the qualifier makes it perform the
match in :dfn:`non-greedy` or :dfn:`minimal` fashion; as *few*
characters as possible will be matched. Using :regexp:`.\*?` in the
previous expression will match only ``'H1'``.
IMO that pair of examples shows clearly that, in this application,
reST is not an improvement over LaTeX in terms of readability/
writability of source. It's probably not worse, although I can't help
muttering EIBTI. In particular I find the ``'...'`` construct
horribly unreadable because it makes it hard to find the Python syntax
in all the reST.
I don't think that's an argument against switching to reST, though.
Georg's site speaks for itself. Kudos!
___
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] Adventures with x64, VS7 and VS8 on Windows
-Original Message- It seems the best thing might be to modify the PCBuild8 build process so the output binaries are in the ../PCBuild' directory - this way distutils and others continue to work fine. Does that sound reasonable? I think Kristjan will have to say a word here: I think he just likes it the way it is right now. That would rather suggest that build_ext needs to be changed. Someone mentioned the idea to have a bat file do it. I like that idea. There is already a build.bat file which will build whatever configuration you choose (platform and configuration). Extending it to subsequently copy the resulting binaries up one level is easy. Perhaps this is an acceptable compromise? Kristjan ___ 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] The docs, reloaded
Hoi, Stephen J. Turnbull stephen at xemacs.org writes: IMO that pair of examples shows clearly that, in this application, reST is not an improvement over LaTeX in terms of readability/ writability of source. It's probably not worse, although I can't help muttering EIBTI. In particular I find the ``'...'`` construct horribly unreadable because it makes it hard to find the Python syntax in all the reST. Well. That was a bad example. But if you look at the converted sources and open the source file you can see that rst is a lot cleaner that latex for this type of documentation. Regards, Armin ___ 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] The docs, reloaded
It would appear that while we slept Jens Mortensen was busy at work on his
rst2{latex,latexmath,mathml}.py scripts:
http://docutils.sourceforge.net/sandbox/jensj/latex_math/
Note the date on the files. It seems to work pretty well, and as others
have pointed out, LaTeX notation is probably more familiar to people
interested in math display than anything else.
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] The docs, reloaded
[EMAIL PROTECTED] wrote:
It would appear that while we slept Jens Mortensen was busy at work on his
rst2{latex,latexmath,mathml}.py scripts:
http://docutils.sourceforge.net/sandbox/jensj/latex_math/
Note the date on the files. It seems to work pretty well, and as others
have pointed out, LaTeX notation is probably more familiar to people
interested in math display than anything else.
I know almost nothing about docutils internals. How do I 'install' the above?
___
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] Module cleanup improvement
Hi Alan, On Mon, May 21, 2007 at 08:17:02PM -0400, Alan McIntyre wrote: Adding a step C1.5 which removes only objects that return true for PyInstance_Check seems to prevent the problem exhibited by this bug (I tried it out locally on the trunk and it doesn't cause any problems with the regression test suite). Is there any reason that adding such a step to module cleanup would be a bad idea? On another level, would there be interest here for me to revive my old attempt at throwing away this messy procedure, which only made sense in a world where reference cycles couldn't be broken? Nowadays the fact that global variables suddenly become None when the interpreter shuts down is a known recipe for getting obscure messages from still-running threads, for example. This has one consequence that I can think about: if we consider a CPython in which the cycle GC has been disabled by the user, then many __del__'s would not be called any more at interpreter shutdown. Do we care? A bientot, Armin ___ 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] Adventures with x64, VS7 and VS8 on Windows
Someone mentioned the idea to have a bat file do it. I like that idea. There is already a build.bat file which will build whatever configuration you choose (platform and configuration). Extending it to subsequently copy the resulting binaries up one level is easy. Perhaps this is an acceptable compromise? Sure - that will work for me. I'll check this out and contact you by private mail for further guidance. Cheers, Mark attachment: winmail.dat___ 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] The docs, reloaded
Stephen J. Turnbull wrote:
IMO that pair of examples shows clearly that, in this application,
reST is not an improvement over LaTeX in terms of readability/
writability of source. It's probably not worse, although I can't help
muttering EIBTI. In particular I find the ``'...'`` construct
horribly unreadable because it makes it hard to find the Python syntax
in all the reST.
It's interesting how perceptions can differ - I find heavily marked up
latex tends to blur into a huge wall of text when I try to read it
because of all of the {} and \ characters everywhere. With reST, on the
other hand, I find the use of the relatively 'light' backquote and colon
characters to delineate the markup breaks things up sufficiently that I
can easily ignore the markup in order to read what has actually been
written.
So in Armin's example, I found the reST version *much* easier to read.
Whether that difference in perception is due simply to my relative lack
of experience in using LaTeX, or to something else, I have no idea.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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] The docs, reloaded
[EMAIL PROTECTED] wrote: True enough. There is MathML and its offspring, ASCIIMathML, which are probably worth looking at. http://www.w3.org/Math/ http://www1.chapman.edu/~jipsen/asciimath.html I have no idea if either one has backend support for presentation outside the web, MathML is the language used for equations in Open Document Format (aka ISO 26300). I don't know what extra typesetting tricks (if any) they wrap around it, though. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] The docs, reloaded
On 5/22/07, Armin Ronacher [EMAIL PROTECTED] wrote: * reST markup isn't much simpler than LaTeX. * reST doesn't support nested markup, which is used in the current documentation. For a lightweight markup language that is human readable (which rst certainly is) the syntax is surprisingly powerful. You can nest any block tag and I'm not sure how often you have to nest roles and stuff like that. The goal of the new docs is a less complex syntax and currently nothing beats reStructuredText in terms of readability and possibilities. About possibilities: I'm sorry but that is simply not true. LaTeX provides the full power of macro expansion, while ReST is a fixed (almost, roles are an exception) syntax which has its own set of problems and ambiguities. It is far from perfect, and definitely does not have the flexibility that LaTeX provides. Some of the syntax cannot be nested (try to combine ** with literals). rst is simpler than latex: That, and the ability to already parse it from Python and more easily convert to other formats (one of LaTeX's weaknesses), are the only benefits that I can see to switching away from LaTeX. I have to admit I'm afraid we would be moving to a lesser technology, and the driver for that seems to be people's reluctance to work with the more powerful, more complex tool. Not saying it is invalid (it's about people, in the end), but I still don't see what's the big problem with LaTeX. ___ 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] The docs, reloaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 22, 2007, at 10:37 AM, Martin Blais wrote: That, and the ability to already parse it from Python and more easily convert to other formats (one of LaTeX's weaknesses), are the only benefits that I can see to switching away from LaTeX. I have to admit I'm afraid we would be moving to a lesser technology, and the driver for that seems to be people's reluctance to work with the more powerful, more complex tool. Not saying it is invalid (it's about people, in the end), but I still don't see what's the big problem with LaTeX. I'm a fan of LaTeX (and latex, er, oops :) too, but what appeals to me most about moving to reST is that the tool chain simplifies considerably. Even with a nice distro packaging system it can be a PITA to get all the tools you need to build the documentation properly installed. A pure-Python solution, even a lesser one, would be a win if we can still produce top quality online and written documentation from one source. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRlMC7XEjvBPtnXfVAQJoFQQAjvYsXamif459t34X4Bn00G0S1b3qeM1Y PhwdAC5cuCpMoopVl+9vtjjcP4Np9P0buY09H+mLwv0nAZRNF7HT3xDr/U65FiX+ Aa7B9+3jVqRGg1+R6oYRKuPUmcLrBFESy6thKkw9audVsT5jgpBM9m9Y405QSIEU MvK7hYrYBqQ= =Jdbt -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] The docs, reloaded
On Tuesday 22 May 2007, Barry Warsaw wrote: considerably. Even with a nice distro packaging system it can be a PITA to get all the tools you need to build the documentation properly installed. A pure-Python solution, even a lesser one, would be a win if we can still produce top quality online and written documentation from one source. The biggest potential wins I see for a new system are: - more contributions - platform-independent processing I remain sceptical on being able to achieve the first, but there some hope for it. The later should make things easier for people who are willing to put the work into contribution, which is valuable in its own right. -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] The docs, reloaded
Neal I know almost nothing about docutils internals. How do I Neal 'install' the above? Me either. Here's what I did: * download and expand the latest docutils snapshot * replicate Jens's work in a directory called math at the top level of the docutils directory * edited setup.py to get them installed: diff -u setup.py.~1~ setup.py --- setup.py.~1~2007-03-21 18:45:38.0 -0500 +++ setup.py2007-05-22 07:07:25.0 -0500 @@ -115,6 +115,9 @@ 'tools/rst2xml.py', 'tools/rst2pseudoxml.py', 'tools/rstpep2html.py', + 'math/tools/rst2latex.py', + 'math/tools/rst2latexmath.py', + 'math/tools/rst2mathml.py', ],} Distutils setup parameters. * ran python setup.py install That's probably more than necessary, but with the math subdir I can easily move the whole thing to a new snapshot and the setup.py change lets me install them transparently. 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] The docs, reloaded
Hoi, Martin Blais blais at furius.ca writes: About possibilities: I'm sorry but that is simply not true. LaTeX provides the full power of macro expansion, while ReST is a fixed (almost, roles are an exception) syntax which has its own set of problems and ambiguities. I was speaking of rst in comparison with other lightweight markup languages. (textile, markdown, wiki syntax). That, and the ability to already parse it from Python and more easily convert to other formats (one of LaTeX's weaknesses), are the only benefits that I can see to switching away from LaTeX. I have to admit I'm afraid we would be moving to a lesser technology, and the driver for that seems to be people's reluctance to work with the more powerful, more complex tool. Not saying it is invalid (it's about people, in the end), but I still don't see what's the big problem with LaTeX. The problem with latex is that it requires more knowledge thus the amount of people that can contribute is a lot lower. It's a lot harder to generate a searchindex, do interlinking, generate a dynamic documentation with comments etc. Don't get me wrong, LaTeX is a powerful tool and I use it for every bigger document i type. I just think it's not the best choice for documenting scripting languages. Regards, Armin ___ 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] The docs, reloaded
Fred The biggest potential wins I see for a new system are: Fred - more contributions Fred - platform-independent processing Fred I remain sceptical on being able to achieve the first, but there Fred some hope for it. You at least take away a common excuse for lack of contributions. True whiners will just come up with new ones (e.g., the documentation isn't available in Sanskrit yet or the dog ate my changes before I could type them into the computer). ;-) 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] The docs, reloaded
- If you make a mistake in LaTeX, you will get a cryptic error which is usually a little difficult to figure out (if you're not used to it). You can an error though. FWIW, the pure Python program in Tools/scripts/texchecker.py does a pretty good job of catching typical LaTeX mistakes and giving high-quality error reporting. Raymond ___ 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] The docs, reloaded
Armin Ronacher schrieb: That, and the ability to already parse it from Python and more easily convert to other formats (one of LaTeX's weaknesses), are the only benefits that I can see to switching away from LaTeX. I have to admit I'm afraid we would be moving to a lesser technology, and the driver for that seems to be people's reluctance to work with the more powerful, more complex tool. Not saying it is invalid (it's about people, in the end), but I still don't see what's the big problem with LaTeX. The problem with latex is that it requires more knowledge thus the amount of people that can contribute is a lot lower. It's a lot harder to generate a searchindex, do interlinking, generate a dynamic documentation with comments etc. This could of course be done with LaTeX as well, but the current toolchain uses latex2html which is written and customized in Perl -- I'd never try to do anything with it. Don't get me wrong, LaTeX is a powerful tool and I use it for every bigger document i type. I just think it's not the best choice for documenting scripting languages. Who's documenting a scripting language? Georg ___ 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] The docs, reloaded
Hoi, Georg Brandl g.brandl at gmx.net writes: Who's documenting a scripting language? Wanted to say agile :D Regards, Armin ___ 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] The docs, reloaded
[EMAIL PROTECTED] schrieb: Fred The biggest potential wins I see for a new system are: Fred - more contributions Fred - platform-independent processing Fred I remain sceptical on being able to achieve the first, but there Fred some hope for it. You at least take away a common excuse for lack of contributions. True whiners will just come up with new ones (e.g., the documentation isn't available in Sanskrit yet or the dog ate my changes before I could type them into the computer). ;-) But that's at least funnier than before :) Georg ___ 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] The docs, reloaded
[EMAIL PROTECTED] wrote: Fred The biggest potential wins I see for a new system are: Fred - more contributions Fred - platform-independent processing Fred I remain sceptical on being able to achieve the first, but there Fred some hope for it. You at least take away a common excuse for lack of contributions. True whiners will just come up with new ones (e.g., the documentation isn't available in Sanskrit yet or the dog ate my changes before I could type them into the computer). ;-) But doesn't *everyone* now know that documentation contributions don't have to be marked up? It's certainly been said enough. Maybe that fact should be more prominent in the documentation? Then we'll just have to worry about getting people to read it ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden -- Asciimercial - Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.comsquidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -- Thank You for Reading ___ 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] The docs, reloaded
- If you make a mistake in LaTeX, you will get a cryptic error which is usually a little difficult to figure out (if you're not used to it). You can an error though. FWIW, the pure Python program in Tools/scripts/texchecker.py does a pretty good job of catching typical LaTeX mistakes and giving high-quality error reporting. With that tool, I've been making doc contributions for years and not needed my own LaTeX build. Also, I did not need to learn LaTeX itself. It was sufficient to read a little of Documenting Python and then model the markup from existing docs. In contrast, whenever I've tried to build a complex ReST document, it was *always* a struggle. Copying from existing docs doesn't help much there because the cues are more subtle. As Martin pointed out, most errors slide-by because the mis-markup is typically read as valid, unmarked-up text. I find myself having to continously build and view and html file as I write. I like ResT for light-weight work but think it is not ready for prime-time with respect to more complex requirements. Fred is also correct in that we don't seem to have people rushing to contribute docs (more than a line or two). For a long-time, we've always said that it is okay to submit plain text doc contributions and that another person downstream would do the mark-up. We've had few takers. Raymond ___ 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] The docs, reloaded
- If you make a mistake in LaTeX, you will get a cryptic error which is usually a little difficult to figure out (if you're not used to it). You can an error though. FWIW, the pure Python program in Tools/scripts/texchecker.py does a pretty good job of catching typical LaTeX mistakes and giving high-quality error reporting. With that tool, I've been making doc contributions for years and not needed my own LaTeX build. Also, I did not need to learn LaTeX itself. It was sufficient to read a little of Documenting Python and then model the markup from existing docs. In contrast, whenever I've tried to build a complex ReST document, it was *always* a struggle. Copying from existing docs doesn't help much there because the cues are more subtle. As Martin pointed out, most errors slide-by because the mis-markup is typically read as valid, unmarked-up text. I find myself having to continously build and view and html file as I write. I like ResT for light-weight work but think it is not ready for prime-time with respect to more complex requirements. Fred is also correct in that we don't seem to have people rushing to contribute docs (more than a line or two). For a long-time, we've always said that it is okay to submit plain text doc contributions and that another person downstream would do the mark-up. We've had few takers. Raymond ___ 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] The docs, reloaded
- If you make a mistake in LaTeX, you will get a cryptic error which is usually a little difficult to figure out (if you're not used to it). You can an error though. FWIW, the pure Python program in Tools/scripts/texchecker.py does a pretty good job of catching typical LaTeX mistakes and giving high-quality error reporting. With that tool, I've been making doc contributions for years and not needed my own LaTeX build. Also, I did not need to learn LaTeX itself. It was sufficient to read a little of Documenting Python and then model the markup from existing docs. In contrast, whenever I've tried to build a complex ReST document, it was *always* a struggle. Copying from existing docs doesn't help much there because the cues are more subtle. As Martin pointed out, most errors slide-by because the mis-markup is typically read as valid, unmarked-up text. I find myself having to continously build and view and html file as I write. I like ResT for light-weight work but think it is not ready for prime-time with respect to more complex requirements. Fred is also correct in that we don't seem to have people rushing to contribute docs (more than a line or two). For a long-time, we've always said that it is okay to submit plain text doc contributions and that another person downstream would do the mark-up. We've had few takers. Raymond ___ 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] The docs, reloaded
- If you make a mistake in LaTeX, you will get a cryptic error which is usually a little difficult to figure out (if you're not used to it). You can an error though. FWIW, the pure Python program in Tools/scripts/texchecker.py does a pretty good job of catching typical LaTeX mistakes and giving high-quality error reporting. With that tool, I've been making doc contributions for years and not needed my own LaTeX build. Also, I did not need to learn LaTeX itself. It was sufficient to read a little of Documenting Python and then model the markup from existing docs. In contrast, whenever I've tried to build a complex ReST document, it was *always* a struggle. Copying from existing docs doesn't help much there because the cues are more subtle. As Martin pointed out, most errors slide-by because the mis-markup is typically read as valid, unmarked-up text. I find myself having to continously build and view and html file as I write. I like ResT for light-weight work but think it is not ready for prime-time with respect to more complex requirements. Fred is also correct in that we don't seem to have people rushing to contribute docs (more than a line or two). For a long-time, we've always said that it is okay to submit plain text doc contributions and that another person downstream would do the mark-up. We've had few takers. Raymond ___ 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] The docs, reloaded
Martin Blais schrieb: On 5/22/07, Nick Coghlan [EMAIL PROTECTED] wrote: So in Armin's example, I found the reST version *much* easier to read. Whether that difference in perception is due simply to my relative lack of experience in using LaTeX, or to something else, I have no idea. - If you make a mistake in LaTeX, you will get a cryptic error which is usually a little difficult to figure out (if you're not used to it). You can an error though. - If you make a mistake in ReST, you will often get no warning nor error, and not the desired output. If you were to use the amount of markup in that example, you would have to check your text with rst2xml frequently to make sure it groks what you're trying to say. (And I've been there: I wrote an entire project who relies specifically on this, on precise structures generated by docutils (http://furius.ca/nabu/). It's *very* easy to make subtle errors that generate something else than what you want.) That is correct, but can be helped with nice preview features. ReST works well only when there is little markup. Writing code documentation generally requires a lot of markup, you want to make variables, classes, functions, parameters, constants, etc.. (A better avenue IMHO would be to augment docutils with some code to automatically figure out the syntax of functions, parameters, classes, etc., i.e., less markup, and if we do this in Python we may be able to use introspection. This is a challenge, however, I don't know if it can be done at all.) While writing the converter, I stumbled about a few locations where the LaTeX markup cannot be completely converted into reST, and a few locations where invalid reST was generated and not warned about. However, both of those problems occurred far less often than I'd anticipated. Georg ___ 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] The docs, reloaded
On Tuesday 22 May 2007, Georg Brandl wrote: But that's at least funnier than before :) It's not our job to make whiner-babies sound funny. -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] The docs, reloaded
Raymond Hettinger schrieb:
- If you make a mistake in LaTeX, you will get a cryptic error which
is usually a little difficult to figure out (if you're not used to
it). You can an error though.
FWIW, the pure Python program in Tools/scripts/texchecker.py does a
pretty good job of catching typical LaTeX mistakes and giving high-quality
error reporting. With that tool, I've been making doc contributions for years
and not needed my own LaTeX build.
I'm not saying that LaTeX is hard for most of us, I say that it is *perceived*
to be hard by many.
And as soon as you dig into the deep support infrastructure, it gets
very confusing. Just look at this bug fix I made some time ago:
http://mail.python.org/pipermail/python-checkins/2007-April/059637.html
Also, I did not need to learn LaTeX itself. It was sufficient to read a
little
of Documenting Python and then model the markup from existing docs.
ISTM that this is possible with the new markup too. I wrote a great part of the
new Documenting Python document, and after reading that one should be prepared
enough to write reST just as well.
In contrast, whenever I've tried to build a complex ReST document,
it was *always* a struggle. Copying from existing docs doesn't help
much there because the cues are more subtle.
I can't see many differences. If I can translate a \begin{classdesc}{...}
environment, I can also translate a .. class:: directive for my new item.
As Martin pointed out,
most errors slide-by because the mis-markup is typically read as
valid, unmarked-up text. I find myself having to continously build and
view and html file as I write. I like ResT for light-weight work but think
it is not ready for prime-time with respect to more complex requirements.
Are the docs really that complex? I mean, look at the typical source of
a converted page. The most common things are information units, i.e.
.. class::
directives, code snippets and plain old text. Cross-references work
flawlessly.
You may also ask Thomas Heller about documenting Python modules in reST.
AFAIR the ctypes docs were written with it and converted to LaTeX
afterwards.
Fred is also correct in that we don't seem to have people rushing to
contribute docs (more than a line or two). For a long-time, we've
always said that it is okay to submit plain text doc contributions and
that another person downstream would do the mark-up. We've had
few takers.
Sometimes it's the way you present the ability to change things that
affects how many people actually do it.
Finding the location that tells you how to suggest changes, and opening
a new bug in the infamous SF tracker is not really something people do
happily. A click here to suggest a change link that leads to a pseudo-
edit-form, complete with preview facility, might prove more effective.
cheers,
Georg
___
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] The docs, reloaded
On Tue, May 22, 2007 at 06:13:36PM +0200, Georg Brandl wrote: Finding the location that tells you how to suggest changes, and opening a new bug in the infamous SF tracker is not really something people do happily. A click here to suggest a change link that leads to a pseudo- edit-form, complete with preview facility, might prove more effective. Indeed. I know my instinctive reaction to the Python docs is oh, this is not something which the public can contribute to. Something more like the PHP-style public annotations might be good - with an appropriate moderation / voting system on the annotations it could possibly be very good. ___ 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] The docs, reloaded
You at least take away a common excuse for lack of contributions. True whiners will just come up with new ones (e.g., the documentation isn't available in Sanskrit yet or the dog ate my changes before I could type them into the computer). ;-) Steve But doesn't *everyone* now know that documentation contributions Steve don't have to be marked up? It's certainly been said Steve enough. Sure, but that doesn't stop the true whiners. ;-) 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] The docs, reloaded
On Tue, May 22, 2007 at 11:45:04AM -0500, [EMAIL PROTECTED] wrote: - - You at least take away a common excuse for lack of contributions. - True whiners will just come up with new ones (e.g., the - documentation isn't available in Sanskrit yet or the dog ate my - changes before I could type them into the computer). ;-) - - Steve But doesn't *everyone* now know that documentation contributions - Steve don't have to be marked up? It's certainly been said - Steve enough. - - Sure, but that doesn't stop the true whiners. ;-) Nothing stops the true whiners ;). I think new and exciting ways of viewing, searching, annotating, linking to/from, and indexing the docs are more important than new formats for (not) writing the docs. For example, this rocks! :: http://pydoc.gbrandl.de/search.html?q=os.patharea=default There have been (good) efforts to wikify the docs in the past. IMO what would make them really work would be to have docs.python.org, the official Python docs location, start hosting these efforts. As long as that location is static, I think the majority of users will ignore other efforts. cheers, --titus p.s. Are there good directions for installing the toolchain for current docs building anywhere? I've tried once or twice, but despite a lot of LaTeX experience I could never get everything hooked up right. ___ 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] The docs, reloaded
Titus Brown wrote: On Tue, May 22, 2007 at 11:45:04AM -0500, [EMAIL PROTECTED] wrote: - - You at least take away a common excuse for lack of contributions. - True whiners will just come up with new ones (e.g., the - documentation isn't available in Sanskrit yet or the dog ate my - changes before I could type them into the computer). ;-) - - Steve But doesn't *everyone* now know that documentation contributions - Steve don't have to be marked up? It's certainly been said - Steve enough. - - Sure, but that doesn't stop the true whiners. ;-) Nothing stops the true whiners ;). I think new and exciting ways of viewing, searching, annotating, linking to/from, and indexing the docs are more important than new formats for (not) writing the docs. For example, this rocks! :: http://pydoc.gbrandl.de/search.html?q=os.patharea=default It would be more impressive if the search string returned hits ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden -- Asciimercial - Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.comsquidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -- Thank You for Reading ___ 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] The docs, reloaded
On Tue, May 22, 2007 at 01:19:36PM -0400, Steve Holden wrote: For example, this rocks! :: http://pydoc.gbrandl.de/search.html?q=os.patharea=default It would be more impressive if the search string returned hits ... Also if it was not completely reliant on JavaScript... (Maybe it's not finished yet?) ___ 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] The docs, reloaded
IMO that pair of examples shows clearly that, in this application, reST is not an improvement over LaTeX in terms of readability/ writability of source. It's probably not worse, although I can't help muttering EIBTI. In particular I find the ``'...'`` construct horribly unreadable because it makes it hard to find the Python syntax in all the reST. Well. That was a bad example. But if you look at the converted sources and open the source file you can see that rst is a lot cleaner that latex for this type of documentation. In your examples, I think the ReST version can be cleaned up quite a bit. First by using the .. default-role:: literal directive so that you can type `foo()` instead of using double back quotes and then you can remove the redundant semantic markup. Like this: `\*?`, `+?`, `??` The `*`, `+` and `?` qualifiers are all *greedy*; they match as much text as possible. Sometimes this behaviour isn't desired; if the RE `.*` is matched against `'H1title/H1'`, it will match the entire string, and not just `'H1'`. Adding `?` after the qualifier makes it perform the match in *non-greedy* or *minimal* fashion; as *few* characters as possible will be matched. Using `.*?` in the previous expression will match only `'H1'`. The above is the most readable version. For example, semantic markup like :regexp:`.\*` doesn't serve any useful purpose. The end result is that the text is typesetted with a fixed-width font, no matter if you prepend :regexp: to it or not. -- mvh Björn ___ 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] The docs, reloaded
Steve Holden schrieb: Titus Brown wrote: On Tue, May 22, 2007 at 11:45:04AM -0500, [EMAIL PROTECTED] wrote: - - You at least take away a common excuse for lack of contributions. - True whiners will just come up with new ones (e.g., the - documentation isn't available in Sanskrit yet or the dog ate my - changes before I could type them into the computer). ;-) - - Steve But doesn't *everyone* now know that documentation contributions - Steve don't have to be marked up? It's certainly been said - Steve enough. - - Sure, but that doesn't stop the true whiners. ;-) Nothing stops the true whiners ;). I think new and exciting ways of viewing, searching, annotating, linking to/from, and indexing the docs are more important than new formats for (not) writing the docs. For example, this rocks! :: http://pydoc.gbrandl.de/search.html?q=os.patharea=default It would be more impressive if the search string returned hits ... This is a JavaScript based search, which will only be (optionally) integrated in the offline version. The online version will get a more sophisticated search. We've just finished to implement the quick dispatcher in the repository. A request to http://docs.python.org/os.path would then redirect to the appropriate module page, as well as http://docs.python.org/?q=os.path Something like http://docs.python.org/?q=os.paht (note the misspelling) would lead to a page with close matching results, os.path being the first of them. (The web app is based on wsgiref, with a few wrappers around it...) cheers, Georg ___ 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] The docs, reloaded
BJörn Lindqvist schrieb: IMO that pair of examples shows clearly that, in this application, reST is not an improvement over LaTeX in terms of readability/ writability of source. It's probably not worse, although I can't help muttering EIBTI. In particular I find the ``'...'`` construct horribly unreadable because it makes it hard to find the Python syntax in all the reST. Well. That was a bad example. But if you look at the converted sources and open the source file you can see that rst is a lot cleaner that latex for this type of documentation. In your examples, I think the ReST version can be cleaned up quite a bit. First by using the .. default-role:: literal directive so that you can type `foo()` instead of using double back quotes and then you can remove the redundant semantic markup. Like this: I've already assigned the default role to `var` since it's used most frequently. Having two ways of spelling literal code is wasting markup, for me. The above is the most readable version. For example, semantic markup like :regexp:`.\*` doesn't serve any useful purpose. The end result is that the text is typesetted with a fixed-width font, no matter if you prepend :regexp: to it or not. Yes, there are a few semantic roles that may be obsolete. Georg ___ 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] Introduction and request for commit access to the sandbox.
On 5/21/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
With that said, I would to request svn access to the sandbox for my
work. I will use this access only for modifying stuff in the directory
I will be assigned to. I would like to use the username avassalotti
and the attached SSH2 public key for this access.
I have added your key. As we have a strict first.last account policy,
I named it alexandre.vassalotti; please correct me if I misspelled it.
Thanks!
One last thing, if you know semantic differences (other than the
obvious ones) between the C and Python versions of the modules I need
to merge, please let know. This will greatly simplify the merge and
reduce the chances of later breaking.
Somebody noticed on c.l.p that, for cPickle,
a) cPickle will start memo keys at 1; pickle at 0
b) cPickle will not put things into the memo if their refcount is
1, whereas pickle puts everything into the memo.
Noted. I think I found the thread on c.l.p about it:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/68c72a5066e4c9bb/b2bc78f7d8d50320
Not sure what you'd consider obvious, but I'll mention that cStringIO
obviously is constrained in what data types you can write (namely,
byte strings only), whereas StringIO allows Unicode strings as well.
Yes. I was already aware of this. I just hope this problem will go
away with the string unification in Python 3000. However, I will need
to deal with this, sooner or later, if I want to port the merge to
2.x.
Less obviously, StringIO also allows
py s = StringIO(0)
py s.write(10)
py s.write(20)
py s.getvalue()
'1020'
That is probably due to the design of cStringIO, which is separated
into two subparts StringI and StringO. So when the constructor of
cStringIO is given a string, it builds an output object, otherwise it
builds an input object:
static PyObject *
IO_StringIO(PyObject *self, PyObject *args) {
PyObject *s=0;
if (!PyArg_UnpackTuple(args, StringIO, 0, 1, s)) return NULL;
if (s) return newIobject(s);
return newOobject(128);
}
As you see, cStringIO's code also needs a good cleanup to make it,
at least, conforms to PEP-7.
-- Alexandre
___
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] Adventures with x64, VS7 and VS8 on Windows
I'd be happy to install Windows and the latest VisualStudio on a 64-bit VMware image. I just can't be responsible for day-to-day administration of the buildslave; Windows requires too much attention for me to do that. Thanks for the offer. Perhaps Kristjan is interested in setting up a buildslave on such an installation. 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
[Python-Dev] The docs, reloaded
Martin v. Löwis schrieb: That docutils happens to be written in Python should make little difference - it's *not* part of the Python language project, and is just a tool for us, very much like latex and latex2html. Not entirely. When I first started looking at python, I read a lot of documentation. Now I don't read it so much; the time when I could easily suggest doc changes without explicitly setting time aside has passed. At that time, the barriers to submitting were fairly large; these are the ones I remember: (1) Not realizing that I *could* submit changes, and they would be welcome. (2) Not understanding it well enough to document it correctly. (3) Not having easy access to the source -- I didn't want to to retype it, or to edit html only to find out it was maintained in some other format. Even once I found the cvs repository, the docs weren't in the main area. (4) Not having an easy way to submit the changes quickly. (5) Wanting to check my work, in case I was wrong. I have no idea how to fix (1) and (2). Putting them on a wiki improves the situation with (3) and (4). (5) is at least helped by keeping the formatting requirements as simple as possible (not sure if ReST does this or not) and by letting me verify them before I submit. Getting docutils is already a barrier; I would like to see a stdlib module (not script hidden off to the side) for verification and conversion. I don't think I installed docutils myself until I started to write a PEP. But once I did download and install and figure out how to call it ... at least it generally worked, and ran with something (python) I was already using. Getting a 3rd party tool that ends up requiring fourth party tools (such as LaTex, but then I need to a viewer, or the old toolchain that required me to install Perl) ... took longer than my attention span. This was despite the fact that I had already used all the needed tools in previous years; they just weren't installed on the machines I had at the time ... and installing them on windows was something that would *probably* work *eventually*. If I had been new to programming, it would have been even more intimidating. -jJ ___ 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] Adventures with x64, VS7 and VS8 on Windows
While that is true in theory, I often find it is not the case in practice, generally due to the optimizer. Depending on what magic the compiler has done, it can be very difficult to set breakpoints (conditional or otherwise), inspect variable values, etc. It is useful in some cases, but very often I find myself falling back to a debug build after attempting to debug a local release build. What I typically do is to disable optimization in a release build. It then essentially becomes a debug build, except that _DEBUG is not defined, so that it doesn't incorporate the debug CRT. This, in turn, means that you can mix such a debug build readily with non-debug binaries. I think there are several other cases in distutils to support special cases (e.g. the DISTUTILS_USE_SDK environment variable); if people want to see their setup supported, AND ARE WILLING TO CONTRIBUTE: more power to them. Yes, but I believe its also important to solicit feedback on the best way to achieve their aims. In this particular case, I believe it would have been misguided for me to simply check in whatever was necessary to have distutils work from the PCBuild8 directory. I hope it is clear that I am willing to contribute the outcome of these discussions... Sure - all understood, and all fine. It's certainly good to build consensus first, but in cases of should we support that borderline case of build setup as long as I'm willing to maintain it, the answer should always be yes (*), irrespective of the merits of the specific proposal. Heck, we would even accept patches to support HP-UX better :-) Regards, Martin (*) assuming it doesn't break anything P.S. I think there have been cases where I haven't been that supportive wrt. build issues. However, in this case I really feel go ahead. ___ 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] Adventures with x64, VS7 and VS8 on Windows
Surely there are differences between architectures? PC uses MSI after all. Why can't linux be under trunk/linux and pc 86 under trunk/pcbuild8/win32PGO and 64 under trunk/pcbuild8/x64pgo? That couldn't work for me. I try avoid building on a network drive, and with local drives, I just can't have a Windows build and a Linux build on the same checkout - they live on separate file systems, after all (Linux on ext3, Windows on NTFS, with multi-boot switching between them). That´s just silly. And two visual studios open, and edit the file in two places too? I have about 10 checkouts of Python, on different machines, with no problems. I don't feel silly doing so. I don't *use* them simultaneously, of course - I cannot work on two architectures simultaneously, anyway. I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier. You might be; I will be sad. It comes for a price, and with little benefit. Disk space is cheaper than my time to fight build processes. And btw, there is no need to install the msvcr8.dll. We can distribute them as a private assembly. then they (and the manifest) exist in the same directory as python2x.dll. Yes, but then python2x.dll goes into system32, and so will msvcr8.dll, no? Not sure whether anything really is needed. Python works fine on Vista. If you are an administrator. A limited user will have problems installing it and then running it. Is there a bug report for that? 1) supplying python.dll as a Side By Side assembly What would that improve? Well, it should reduce dll-hell problems of applications that ship with python2x.dll. You ship with and link to your own and tested dll. We have some concerns here, for example, now that we are moving away from embedding python in our blue.dll and using python25.dll directly, that this exposes a vulnerability to the integrity of the software. Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release? 2) Changing python install locations To conform with Windows rules and get a Vista approved logo. Install in the ProgramFiles folder. Only over my dead body. *This* is silly. Just as C does. Ah, and this also means that we could install both 32 bit and 64 bit versions, another plus. What about the registry? Interesting. We are definitely interested in that. You see, Someone installs a game or accounting software using vista. He then runs as a limited user. Python insists on saving its .pyc files in the installation folder, but this is not something that is permitted on Vista. But that's not a problem, is it? Writing silently fails, i.e. it just won't save the pyc files. Happens all the time on Unix. Sure, and have they reported problems with Python on Vista (problems specific to Vista?) Certainly. We are working on them, of course. But, of course, they have not been reported. 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] [Distutils] Adventures with x64, VS7 and VS8 on Windows
I have a set of extensions that use SWIG to wrap my own C++ library. This library, on a day-to-day basis is built against VS8 since the rest of our product suite is. Right now I have no way to work with this code using VS8 since the standard distribution is built against VS7 which uses a different CRT. This is an absolute nightmare in practice since I currently have to maintain VS7 projects in parallel with the standard VS8 ones simply so that I can run and test my python code. If you know well enough what you are doing, and avoid using unsupported cases, you *can* mix different CRTs. Building using the current projects I seem to get everything in the PCBuild8 / PCBuild dirs. How can I work with what is build? Python works correctly out of its build directory. You can just run it from there. Is there a shell script to build a final distribution tree? Not sure what you mean by tree. Distribution is in a single MSI file, not in a tree, and the tree that gets created on the target machine (of the MSI file) never exists on the source machine. If not, is there a simple way to build an MSI similar to the one found on the Python.org site for the official releases but using the PCBuild8 stuff? No, but it should be possible to adopt Tools/msi to package pcbuild8 instead. Just make sure you are using different GUIDs as the ProductCode. 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] Adventures with x64, VS7 and VS8 on Windows
If there are no technical and corporate difficulties, such as firewalls and security, I am sure that CCP can provide a VisualStudio2005 buildbot for our needs. Wasn't there some issue that each buildbot can only provide a single build? Yes, but you can have multiple buildbot slaves on a single machine. They all create separate checkouts. 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] The docs, reloaded
On Tue, 22 May 2007, Steve Holden wrote: But doesn't *everyone* now know that documentation contributions don't have to be marked up? It's certainly been said enough. Maybe that fact should be more prominent in the documentation? Then we'll just have to worry about getting people to read it ... I think the issue is instant gratification. You don't get the satisfaction of seeing your changes unless you're willing to write them in LaTeX, and that's a pretty big barrier -- a lot of what motivates open source volunteers is the sense of fulfillment. (Hence, by the same nature, Wiki-like editing with instant changes visible online will probably greatly increase contributions.) -- ?!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
Re: [Python-Dev] The docs, reloaded
In your examples, I think the ReST version can be cleaned up quite a bit. First by using the .. default-role:: literal directive so that you can type `foo()` instead of using double back quotes and then you can remove the redundant semantic markup. Like this: I've already assigned the default role to `var` since it's used most frequently. Having two ways of spelling literal code is wasting markup, for me. Reassign it then. :) `var` makes italic text but you can use *var* for that instead. Minor point I know, but it would make reading ReST source just a tiny bit easier. -- mvh Björn ___ 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] Module cleanup improvement
On another level, would there be interest here for me to revive my old attempt at throwing away this messy procedure, which only made sense in a world where reference cycles couldn't be broken? I definitely think Py3k, at least, should use such an approach - especially with PEP 3121, which should allow to incorporate variables stored in extension module's globals to participate in GC. 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] The docs, reloaded
Hoi, Additionally to the offline docs that Georg published some days ago there is also a web version which currently looks and works pretty much like the offline version. There are however some differences that are worth knowing: - Cleaner URLs. You can actually guess them because we took the idea the PHP people had and check for similar pages if a page does not exist. We do however redirect if there was a match so that the URL stays unique. - The search doesn't require JavaScript (but is currently disabled due to a buggy stemmer and indexer) That's it for now, you can try it online at http://pydoc.gbrandl.de:3000/ Regards, Armin ___ 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] Module cleanup improvement
[Armin Rigo] On another level, would there be interest here for me to revive my old attempt at throwing away this messy procedure, which only made sense in a world where reference cycles couldn't be broken? Definitely. Nowadays the fact that global variables suddenly become None when the interpreter shuts down is a known recipe for getting obscure messages from still-running threads, for example. This has one consequence that I can think about: if we consider a CPython in which the cycle GC has been disabled by the user, then many __del__'s would not be called any more at interpreter shutdown. Do we care? I don't believe this is a potential issue in CPython. The user-exposed gc.enable() / gc.disable() only affect automatic cyclic gc -- they flip a flag that has no bearing on whether an /explicit/ call to gc.collect() will try to collect trash (it will, unless a collection is already in progress, regardless of the state of the enabled flag). Py_Finalize() calls the C spelling of gc.collect() (PyGC_Collect), and I don't believe that can be user-disabled. ___ 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 : 364 open ( +2) / 3769 closed ( +3) / 4133 total ( +5) Bugs: 986 open (+18) / 6701 closed ( +9) / 7687 total (+27) RFE : 258 open ( +2) / 287 closed ( +1) / 545 total ( +3) New / Reopened Patches __ syslog syscall support for SysLogLogger (2007-05-02) http://python.org/sf/1711603 reopened by luke-jr Remove backslash escapes from tokanize.c. (2007-05-16) http://python.org/sf/1720390 opened by Ron Adam Allow T_BOOL in PyMemberDef definitions (2007-05-17) http://python.org/sf/1720595 opened by Angelo Mottola fix 1668596: copy datafiles properly when package_dir is ' ' (2007-05-17) http://python.org/sf/1720897 opened by Raghuram Devarakonda Build on QNX (2007-05-20) http://python.org/sf/175 opened by Matt Kraai Curses Menu (2007-05-21) http://python.org/sf/1723038 opened by Fabian Frederick Patches Closed __ Removal of Tuple Parameter Unpacking [PEP3113] (2007-03-10) http://python.org/sf/1678060 closed by bcannon Class Decorators (2007-02-28) http://python.org/sf/1671208 closed by jackdied Allow any mapping after ** in calls (2007-03-23) http://python.org/sf/1686487 closed by gbrandl New / Reopened Bugs ___ build_clib --build-clib/--build-temp option bugs (2007-05-14) http://python.org/sf/1718574 opened by Pearu Peterson glibc error: corrupted double linked list (CPython 2.5.1) (2007-05-14) http://python.org/sf/1718942 opened by Yang Zhang new functools (2007-05-15) http://python.org/sf/1719222 opened by Aaron Brady Python package support not properly documented (2007-05-15) http://python.org/sf/1719423 opened by Michael Abbott tarfile stops expanding with long filenames (2007-05-16) http://python.org/sf/1719898 opened by Christian Zagrodnick No docs for PyEval_EvalCode and related functions (2007-05-16) http://python.org/sf/1719933 opened by Joseph Eagar sets module documentation: example uses deprecated method (2007-05-16) CLOSED http://python.org/sf/1719995 opened by Jens Quade Compiler is not thread safe? (2007-05-16) http://python.org/sf/1720241 opened by ??PC?? PyGILState_Ensure does not acquires GIL (2007-05-16) http://python.org/sf/1720250 opened by Kuno Ospald Tkinter + thread + urllib = crashes? (2007-05-17) http://python.org/sf/1720705 opened by Hirokazu Yamamoto docu enhancement for logging.handlers.SysLogHandler (2007-05-17) http://python.org/sf/1720726 opened by rhunger Please make sqlite3.Row iterable (2007-05-17) CLOSED http://python.org/sf/1720959 opened by phil automatic imports (2007-05-17) http://python.org/sf/1720992 opened by Juan Manuel Borges Caño ERROR - Microsoft Visual C++ Runtime Library (2007-05-18) http://python.org/sf/1721161 reopened by dariounipd ERROR - Microsoft Visual C++ Runtime Library (2007-05-18) http://python.org/sf/1721161 opened by darioUniPD code that writes the PKG-INFO file doesnt handle unicode (2007-05-18) http://python.org/sf/1721241 opened by Matthias Klose make testall shows many glibc detected malloc corruptions (2007-05-18) http://python.org/sf/1721309 reopened by gbrandl make testall shows many glibc detected malloc corruptions (2007-05-18) http://python.org/sf/1721309 opened by David Favor test_bsddb3 malloc corruption (2007-05-18) CLOSED http://python.org/sf/1721313 opened by David Favor emphasize iteration volatility for dict (2007-05-18) CLOSED http://python.org/sf/1721368 opened by Alan emphasize iteration volatility for set (2007-05-18) CLOSED http://python.org/sf/1721372 opened by Alan Small case which hangs (2007-05-18) http://python.org/sf/1721518 opened by Julian Todd A subclass of set doesn't always have __init__ called. (2007-05-19) http://python.org/sf/1721812 opened by David Benbennick email.FeedParser.BufferedSubFile improperly handles \r\n (2007-05-19) http://python.org/sf/1721862 opened by Sye van der Veen IDLE hangs in popup method completion (2007-05-19) http://python.org/sf/1721890 opened by Andy Harrington NamedTuple security issue (2007-05-20) CLOSED http://python.org/sf/1722239 reopened by tiran NamedTuple security issue (2007-05-20) CLOSED http://python.org/sf/1722239 opened by Christian Heimes Thread shutdown exception in Thread.notify() (2007-05-20) http://python.org/sf/1722344 opened by Yang Zhang urlparse.urlunparse forms file urls incorrectly (2007-05-20) http://python.org/sf/1722348 opened by Thomas Folz-Donahue Option -OO doesn't remove docstrings (2007-05-21) http://python.org/sf/1722485 opened by Grzegorz Adam Hankiewicz x = [[]]*2; x[0].append doesn't work (2007-05-21) CLOSED http://python.org/sf/1722956 opened by Jeff
Re: [Python-Dev] The docs, reloaded
On 5/22/07, Georg Brandl [EMAIL PROTECTED] wrote: Don't get me wrong, LaTeX is a powerful tool and I use it for every bigger document i type. I just think it's not the best choice for documenting scripting languages. Who's documenting a scripting language? Hehe I can't believe I just wrote that... ___ 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] The docs, reloaded
On 5/22/07, Martin Blais [EMAIL PROTECTED] wrote: ReST works well only when there is little markup. Writing code documentation generally requires a lot of markup, you want to make variables, classes, functions, parameters, constants, etc.. (A better avenue IMHO would be to augment docutils with some code to automatically figure out the syntax of functions, parameters, classes, etc., i.e., less markup, and if we do this in Python we may be able to use introspection. This is a challenge, however, I don't know if it can be done at all.) Just to follow-up on that idea: I don't think it would be very difficult to write a very small modification to docutils that interprets the default role with more smarts, for example, you can all guess what the types of these are about: `class Foo` (this is a class Foo) `bar(a, b, c) - str` (this is a function bar which returns a string) `name (attribute)` (this is an attribute) ...so why couldn't the computer solve that problem for you? I'm sure we could make it happen. Essentially, what is missing from ReST is less markup for documenting programs. By restricting the problem-set to Python programs, we can go a long way towards making much of this automatic, even without resorting to introspecting the source code that is being documented. ___ 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] Module cleanup improvement
Armin Rigo wrote: if we consider a CPython in which the cycle GC has been disabled by the user, then many __del__'s would not be called any more at interpreter shutdown. That can happen now anyway. Module clearing only cleans up cycles that go through the module dict. +1 from me on getting rid of module clearing at shutdown. -- 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] Need Survey Answers from Core Developers
On Saturday 19 May 2007, [EMAIL PROTECTED] wrote: Jeff 1) How is the project governed? How does the community make Jeffdecisions on what goes into a release? Consensus (most of the time) and GvR pronouncements for significant changes. There are situations where Guido has simply pronounced when the community seemed unable to settle on one solution. Decorators come to mind. Plus of course there's the minor detail of features needing to be implemented. If no-one steps up to complete something, it can just get deferred. See PEP 356's list of deferred features. Jeff 2) Does the language have a formal defined release plan? JeffI know Zope 3's release plan, every six months, but not that of JeffPython. Is there a requirement to push a release out the door Jeffevery N months, as some projects do, or is each release Jeffseparately negotiated with developers around a planned set Jeffof features? PEP 6? PEP 101? PEP 102? There is no hard-and-fast time schedule. I believe minor releases leave the station approximately every 18-24 months, micro releases roughly every six months. The goal is to have a major release (I consider 2.5, 2.6 c to be major, and 2.5.1, 2.5.2 c minor - this is how it's always been, afaik) when they're done. Typically this is around 18-24 months. There's not (yet?) a formal release plan for the minor/bugfix releases, but they've been every 6 months since late 2003. Obviously, if a major bug is found then a release happens sooner. Jeff 3) Some crude idea of how many new major and minor features were Jeffadded in the last release? Yes, I know this is difficult -- the Jeffidea it so get some measure of the evolution/stability of cPython Jeffre features. Jython and IronPython are probably changing rapidly Jeff-- cPython, not such much. We don't break down major or minor features, but according to the What's New In Python 2.5 doc: A search through the SVN change logs finds there were 353 patches applied and 458 bugs fixed between Python 2.4 and 2.5. (Both figures are likely to be underestimates.) The distinction between major and minor feature is pretty arbitrary, obviously. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] [Python-3000] Introduction and request for commit access to the sandbox.
On 5/22/07, Alexandre Vassalotti [EMAIL PROTECTED] wrote: As you see, cStringIO's code also needs a good cleanup to make it, at least, conforms to PEP-7. Alexandre, It would be great if you could break up unrelated changes into separate patches. Some of these can go in sooner rather than later. I don't know all the things that need to be done, but I could imagine a separate patch for each of: * whitespace normalization * function name modification * other formatting changes * bug fixes * changes to make consistent with StringIO I don't know if all those items in the list need to change, but that's the general idea. Separate patches will make it much easier to review and get benefits from your work earlier. I look forward to seeing your work! 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
