[David Goodger]
Could be. I don't see HTML+PythonDoc as a significant improvement
over LaTeX.
[Fredrik Lundh]
Really?
Yes, really.
Your reply makes it obvious that you don't understand the issues involved
here, nor how the goals address them.
(Snipping heavily below due to lack of
Martin v. Löwis wrote:
Please let me know what you think.
Regards,
Martin
PEP: XXX
Title: Using ssize_t as the index type
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
Ka-Ping Yee wrote:
In a fair number of cases, Python doesn't follow its own recommended
naming conventions. Changing these things would break backward
compatibility, so they are out of the question for Python 2.*, but
it would be nice to keep these in mind for Python 3K.
Constants in
Fredrik Lundh wrote:
well, one thing seems to missing from your PEP: in several modules, you've
changed the cast used in the type table. e.g.
...
is this change backwards compatible ?
See the section Conversion guidelines. I prefer the approach taken in
the patch below, i.e. remove the casts
Travis E. Oliphant wrote:
Sounds wonderful. Would love to see this in Python 2.5. This will fix
important 64-bit issues. Perhaps someone could explain to me what the
difference between Py_ssize_t and Py_intptr_t would be? Is this not a
satisfactory Py_ssize_t already?
Practically, yes.
Tim Peters wrote:
Better to use a new gibberish character and deprecate the old one?
Otherwise I'm afraid we'll be stuck supporting PY_SIZE_T_CLEAN
forever, and it's not good to have the meaning of a format string
depend on the presence or absence of a #define far away in the file.
See my
Brett Cannon wrote:
I am fine with changing the built-in types, but changing the built-in
singletons just looks *really* odd to me. So odd that I just don't
want to see them changed. I mean when I think of constants, I think
of a variable that references an object and that reference never
On Fri, 30 Dec 2005, Reinhold Birkenfeld wrote:
Ka-Ping Yee wrote:
Constants in all caps:
NONE, TRUE, FALSE, ELLIPSIS
That's ugly.
I know it looks ugly to you now. But there's a good reason why we use
capitalization for class names -- anyone reading code who comes across
a
Brett Cannon wrote:
I am fine with changing the built-in types, but changing the built-in
singletons just looks *really* odd to me. So odd that I just don't
want to see them changed. I mean when I think of constants, I think
of a variable that references an object and that reference never
Ka-Ping Yee wrote:
Actually, I thought some of them would become reserved words in P3k,
anyway.
That would be cool. If so, it would make sense for them to be all in
lowercase.
And rename None to null in the process :-)
Regards,
Martin
___
On Fri, 30 Dec 2005, Martin v. Löwis wrote:
Ka-Ping Yee wrote:
That would be cool. If so, it would make sense for them to be all in
lowercase.
And rename None to null in the process :-)
Is there a really good reason to do that? It's not obvious to me.
-- ?!ng
Ka-Ping Yee wrote:
On Fri, 30 Dec 2005, Martin v. Löwis wrote:
Ka-Ping Yee wrote:
That would be cool. If so, it would make sense for them to be all in
lowercase.
And rename None to null in the process :-)
Is there a really good reason to do that? It's not obvious to me.
That was
I've been dodging this thread because I don't really have much to add,
apart from a documentation end user point of view...
On Fri, 2005-12-30 at 09:25 +0100, Fredrik Lundh wrote:
[...]
Another goal is highly biased toward XML-style markup:
* Make it trivial to do basic rendering to
On Friday 30 December 2005 06:31, Ka-Ping Yee wrote:
Is there a really good reason to do that? It's not obvious to me.
No more than there is to rename None to none or NONE.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
Python-Dev mailing
On Fri, 30 Dec 2005, Fred L. Drake, Jr. wrote:
On Friday 30 December 2005 06:31, Ka-Ping Yee wrote:
Is there a really good reason to do that? It's not obvious to me.
No more than there is to rename None to none or NONE.
For that, there is a reason: None is not a class.
-- ?!ng
I think the discussion is coming to a clear conclusion here not to do
this (except for the standard library classes like anydbm.error). I'm
piping in with my own -1 (for all the sane reasons) to hopefully stop
this thread quickly. We don't need more noise here.
--Guido
On 12/29/05, Ka-Ping Yee
On Fri, Dec 30, 2005 at 10:16:43AM -0500, Barry Warsaw wrote:
On Thu, 2005-12-29 at 22:29 -0600, Ka-Ping Yee wrote:
In a fair number of cases, Python doesn't follow its own recommended
naming conventions. Changing these things would break backward
compatibility, so they are out of the
[David Goodger]
The second sentence lacks a rationale. What's wrong with --
dashes? What's silly about ``quotes''?
[Fredrik Lundh]
don't you know *anything* about typography ?
Yes, for a layman, I know plenty. I am not a typographer though.
Simply put, your list of goals provides no
I haven't followed the thread, so many I'm repeating things.
Has anyone considered using e.g. MediaWiki (the wiki used for
Wikipedia) for Python documentation ?
I'm asking because this wiki has proven to be ideally suited
for creating complex documentation tasks and offers many features
which
David Goodger wrote:
The problem is that the WORKFLOW doesn't work.
So fix the workflow. Something like Ian Bicking's Commentary system,
or something more specific to Python's docs, seems to fit the bill.
I'll just note that Commentary works on any HTML, so it doesn't matter
what the
On 12/30/05, Robey Pointer [EMAIL PROTECTED] wrote:
On 29 Dec 2005, at 18:58, David Goodger wrote:
[Fredrik Lundh]
I'm beginning to fear that I've wasted my time on a project
that nobody's interested in.
[David Goodger]
Could be. I don't see HTML+PythonDoc as a significant
Grant Crawley wrote:
no worriesI assume that we will be gaming till somewhat late?
Well, Monday's a public holiday, so. . .
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
Ian Bicking wrote:
Anyway, another even more expedient option would be setting up a
separate bug tracker (something simpler to submit to than SF) and
putting a link on the bottom of every page, maybe like:
http://trac.python.org/trac/newticket?summary=re:+/path/to/doccomponent=docs
--
Sorry about that folks - finger trouble in the mail client ;)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
24 matches
Mail list logo
