Re: [Python-Dev] The docs, reloaded

[Armin Ronacher]

Hoi,

Fred L. Drake, Jr.  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{'title'}, it will match the entire string, and not just
\code{''}.  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{''}.

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
   ``'title'``, it will match the entire string, and not just
   ``''``.  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 ``''``.

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

[Georg Brandl]

Armin Ronacher schrieb:
> Hoi,
> 
> Fred L. Drake, Jr.  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

[Georg Brandl]

Fred L. Drake, Jr. schrieb:
> On Monday 21 May 2007, [EMAIL PROTECTED] wrote:
>  > Take a look at .  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

[M.-A. Lemburg]

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

[Kristján Valur Jónsson]

> -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

[Kristján Valur Jónsson]

> -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

[Stephen J. Turnbull]

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{'title'}, it will match the entire string, and not just
 > \code{''}.  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{''}.
 > 
 > 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
 >``'title'``, it will match the entire string, and not just
 >``''``.  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 ``''``.

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

[Kristján Valur Jónsson]

> -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

[Armin Ronacher]

Hoi,

Stephen J. Turnbull  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

[skip]

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

[Neal Becker]

[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

[Armin Rigo]

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

[Mark Hammond]

> 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
<>___
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

[Nick Coghlan]

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

[Nick Coghlan]

[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

[Martin Blais]

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

[Martin Blais]

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.)

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.)
___
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

[Barry Warsaw]

-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

[Fred L. Drake, Jr.]

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.   
___
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

[skip]

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

[Armin Ronacher]

Hoi,

Martin Blais  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

[skip]

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

[Raymond Hettinger]

> - 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

[Georg Brandl]

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

[Armin Ronacher]

Hoi,

Georg Brandl  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

[Georg Brandl]

[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

[Steve Holden]

[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

[Raymond Hettinger]

> - 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

[Raymond Hettinger]

> - 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

[Raymond Hettinger]

> - 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

[Raymond Hettinger]

> - 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

[Georg Brandl]

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

[Fred L. Drake, Jr.]

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.   
___
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

[Georg Brandl]

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

[Jon Ribbens]

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

[skip]

>> 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

[Titus Brown]

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.path&area=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

[Steve Holden]

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.path&area=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

[Jon Ribbens]

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.path&area=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

[BJörn Lindqvist]

> > 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 `'title'`, it will match
  the entire string, and not just `''`. 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 `''`.

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

[Georg Brandl]

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.path&area=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

[Georg Brandl]

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.

[Alexandre Vassalotti]

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

[Martin v. Löwis]

> 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

[Jim Jewett]

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

[Martin v. Löwis]

> 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

[Martin v. Löwis]

> 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

[Martin v. Löwis]

> 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

[Martin v. Löwis]

> 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

[Ka-Ping Yee]

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

[BJörn Lindqvist]

> > 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

[Martin v. Löwis]

> 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

[Armin Ronacher]

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

[Tim Peters]

[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

[Kurt B. Kaiser]

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 Br

Re: [Python-Dev] The docs, reloaded

[Martin Blais]

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

[Martin Blais]

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

[Greg Ewing]

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

[Anthony Baxter]

On Saturday 19 May 2007, [EMAIL PROTECTED] wrote:
> Jeff> 1) How is the project governed?  How does the community
> make Jeff>decisions 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?
>
> Jeff>I know Zope 3's release plan, every six months, but
> not that of Jeff>Python.  Is there a requirement to push a
> release out the door Jeff>every N months, as some projects
> do, or is each release Jeff>separately negotiated with
> developers around a planned set Jeff>of 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 
> Jeff>added in the last release?  Yes, I know 
> this is difficult -- the 
> Jeff>idea it so get some measure of 
> the evolution/stability of cPython 
> Jeff>re 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.

[Neal Norwitz]

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

Re: [Python-Dev] The docs, reloaded

[Georg Brandl]

Armin Ronacher schrieb:
> 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)

Also, try

http://pydoc.gbrandl.de:3000/os.path.exists

and

___
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

[Georg Brandl]

Georg Brandl schrieb:
> Armin Ronacher schrieb:
>> 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)
> 
> Also, try
> 
> http://pydoc.gbrandl.de:3000/os.path.exists
> 
> and

http://pydoc.gbrandl.de:3000/os.paht.exists

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