Hi Martin,
You are likely doing something wrong:
a) I assume it's VS 7.1 (i.e. VS.NET 2003); VS 2002 is not supported
at all
b) you probably didn't install vsextcomp, but you should.
In fact, you don't need all of it, but you do need the cl.exe and
link.exe wrappers it comes with -
I would agree with the point that python core should be considered
first, but I would also only see beneficial to leave the door open
to the need of other packages.
I have (briefly but intensely) worked on a revamp of pydoc earlier on
this year, and while collecting requirements from a number of
Georg Brandl [EMAIL PROTECTED] wrote:
over the last few weeks I've hacked on a new approach to Python's
documentation.
As Python already has an excellent documentation framework, the docutils,
with a
readable yet extendable markup format, reST, I thought that it should be
possible to
On 2007-05-21 12:30, Kristján Valur Jónsson wrote:
[Py_UNICODE being #defined as unsigned short on Windows]
I'd rather make it a platform-specific definition (for platform=Windows
API). Correct me if I'm wrong, but isn't wchar_t also available in VS
2003 (and even in VC6?). And doesn't it
-Original Message-
This was in C++, but the problem was really WCHAR, as used by much of
the
win32 API.
I'd rather make it a platform-specific definition (for
platform=Windows
API). Correct me if I'm wrong, but isn't wchar_t also available in VS
2003 (and even in VC6?). And
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
PEP: 365
Title: Adding the pkg_resources module
I'm really surprised that there
Kristján Valur Jónsson quoting me:
hrm - as above, I'm more concerned with the definition of
WCHAR - which
means my problem is related more to the Platform SDK version rather
than the
compiler. This is unfortunate - on one hand we do consider
'platform=Windows API', and WCHAR is very
-Original Message-
below appears to solve the problem, and given Martin's previous +1, I
decided to stop there. I failed in a quick attempt at replacing the
literal 2 with something involving sizeof. Does this look reasonable?
+1.
I should add that we have this local mod in our
Brett Martin beat me to my comment. =) Python's needs should come
Brett first, period. If Georg wants to add math support, fine. But
Brett honestly I would rather he spend his time on Python-specific
Brett stuff then get bogged down to support possible third parties.
I think
You must realize that people will use the core tools to create
documentation for third party packages which aren't in the core. If
you replace LaTeX with something else I think you need to keep math
in mind whether it's used in the core documentation or not.
Martin I
Hi Kristján,
First of all, I have put some work into pcbuild8 recently and it works
well.
It does! There are a few issues though, notably with distutils (and as
mentioned before, any other tools what may assume PCBuild - see below)
You quoting Martin:
I don't find the need to have separate
On Monday 21 May 2007, [EMAIL PROTECTED] wrote:
Then I submit that you are probably removing some significant piece of
functionality from the provided documentation toolchain which some people
probably rely on. After all, that's what LaTeX excels at. They will be
able to continue to use
At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as
well. Feedback welcome.
PEP: 365
Title: Adding the
On 2007-05-21 16:05, Phillip J. Eby wrote:
At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as
well. Feedback
Could this be a language-independent documenting toolkit? Could
we document LISP or Ruby code with it?
Might want to look at noweb, http://www.eecs.harvard.edu/~nr/noweb/:
``...noweb works ``out of the box'' with any programming language, and
supports TeX, latex, HTML, and troff back ends.''
We are developing a programming language here, not a typesetting
system.
Good point, Martin. Are you implying that the documentation should be
kept in LaTeX, a widely-accepted widely-disseminated stable
documentation language, which someone else maintains, rather than
ReST, which elements of
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you provided doesn't really explain the concepts, reading
the code helped a bit).
That doesn't really make
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you provided doesn't really explain the concepts, reading
Nick Craig-Wood schrieb:
Georg Brandl [EMAIL PROTECTED] wrote:
over the last few weeks I've hacked on a new approach to Python's
documentation.
As Python already has an excellent documentation framework, the docutils,
with a
readable yet extendable markup format, reST, I thought that it
Robert Kern schrieb:
Neal Becker wrote:
There is an effort as part of numpy to come up with a new system using
docstrings. It seems to me it would be unfortunate if these two efforts
were not coordinated.
I don't think so. The issue with numpy is getting our act together and making
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 21, 2007, at 12:28 AM, Martin v. Löwis wrote:
I disagree. The documentation infrastructure of Python should only
consider the needs of Python itself. If other people can use that
infrastructure for other purposes, fine - if they find that
[EMAIL PROTECTED] schrieb:
Brett Martin beat me to my comment. =) Python's needs should come
Brett first, period. If Georg wants to add math support, fine. But
Brett honestly I would rather he spend his time on Python-specific
Brett stuff then get bogged down to support
Fred L. Drake, Jr. schrieb:
On Monday 21 May 2007, [EMAIL PROTECTED] wrote:
Then I submit that you are probably removing some significant piece of
functionality from the provided documentation toolchain which some people
probably rely on. After all, that's what LaTeX excels at. They
On Sat, May 19, 2007 at 07:14:09PM +0200, Georg Brandl wrote:
For the impatient: the result can be seen at http://pydoc.gbrandl.de.
I think that looks great.
One comment I have, I don't know if it's relevant - it perhaps depends
on whether the Global Module Index is auto-generated or not. This
At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you
Jon Ribbens schrieb:
On Sat, May 19, 2007 at 07:14:09PM +0200, Georg Brandl wrote:
For the impatient: the result can be seen at http://pydoc.gbrandl.de.
I think that looks great.
One comment I have, I don't know if it's relevant - it perhaps depends
on whether the Global Module Index is
On Mon, May 21, 2007 at 09:23:47AM -0400, Fred L. Drake, Jr. wrote:
I'll be happy to pull the existing tools out into a separate distribution if
we move to something else for Python. There are too many users of the
existing tools to abandon.
That seems like a straightforward task.
The
I'm using the full-blown VS.NET 2003, as given to a number of python-dev
people by Microsoft a number of years ago. This appears to come with the
SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET
2003 is x86 only
I'm guessing vsextcomp doesn't
I don't find the need to have separate object directories convincing:
For building the Win32/Win64 binaries, I have separate checkouts
*anyway*, since all the add-on libraries would have to support
multi-arch builds, but I think they don't.
No they don't, but that doesn't mean that you need
On 2007-05-21 22:48, Phillip J. Eby wrote:
At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP
I think the people who have responded to my comment read too much into it.
Nowhere do I think I asked Georg to write an equation typesetter to include
in the Python documentation toolchain. I asked that math capability be
considered. I have no idea what tools he used to build his new
Martin I disagree. The documentation infrastructure of Python should
Martin only consider the needs of Python itself. If other people can
Martin use that infrastructure for other purposes, fine - if they find
Martin that it does not meet their needs, they have to look
Bill Janssen schrieb:
We are developing a programming language here, not a typesetting
system.
Good point, Martin. Are you implying that the documentation should be
kept in LaTeX, a widely-accepted widely-disseminated stable
documentation language, which someone else maintains, rather than
One comment I have, I don't know if it's relevant - it perhaps
depends on whether the Global Module Index is auto-generated or
not. This is the page I visit the most out of all the Python
documentation, and it's far too large and unwieldy. IMHO it would be
much better if
At 11:44 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 22:48, Phillip J. Eby wrote:
At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should
[EMAIL PROTECTED] wrote:
What would be my choices for add math to the documentation?
Where in the current documentation is there any math notation /at
all/?
Georg There is exactly one instance of LaTeX math in the whole docs,
Georg it's in the description of
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.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
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
Hi all,
Bug #1717900 has an example of a script that causes a (cryptic, IMO)
error during module cleanup since instances of a class just happen to
get destroyed after their class is destroyed, and the __del__ method
manipulates a class attribute. As I understand it this is expected
under the
On Mon, May 21, 2007, Jon Ribbens wrote:
One comment I have, I don't know if it's relevant - it perhaps depends
on whether the Global Module Index is auto-generated or not. This is
the page I visit the most out of all the Python documentation, and
it's far too large and unwieldy. IMHO it
Neal It happens that for math markup, there isn't really anything
Neal better (or more familiar) than latex.
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
On 5/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
One comment I have, I don't know if it's relevant - it perhaps
depends on whether the Global Module Index is auto-generated or
not. This is the page I visit the most out of all the Python
documentation, and it's far
On 5/21/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
I think the people who have responded to my comment read too much into it.
Nowhere do I think I asked Georg to write an equation typesetter to include
in the Python documentation toolchain. I asked that math capability be
considered. I
Hi Marc-Andre,
+1 from me.
If 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
#
Hi Martin,
I'm using the full-blown VS.NET 2003, as given to a number
of python-dev
people by Microsoft a number of years ago. This appears to
come with the
SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET
2003 is x86 only
Yes - I was
Kristján Valur Jónsson wrote:
First of all, I have put some work into pcbuild8 recently and it works
well. I am trying to drum up momentum for work on PCBuild8
next europython. See http://wiki.python.org/moin/EuroPython2007Sprints
-Original Message-
From: [EMAIL PROTECTED]
I
Yes, that is correct. I agree it will be rarely used by Python user's, but
believe it is a common scenario for people who maintain extensions or
libraries, particularly those who want debugging builds.
Ah, debugging builds. It's true that PCbuild does not support them for
AMD64, and it's also
Neal Becker writes:
Perhaps my comment was misunderstood. I have no objection to a new system,
and it does not have to be based on latex. I just hope there will be some
escape mechanism that allows math.
Docutils already provides the raw directive. I don't know if the
latex backend
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
On Tue, May 22, 2007 at 07:32:42AM +0200, Martin v. L?wis wrote:
- 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
50 matches
Mail list logo
