Sorry about that folks - finger trouble in the mail client ;)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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/doc&component=docs
> -
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
---
http:/
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
Ian Bicking wrote:
> Right now most people who might be willing to contribute to the Python
> documentation don't. Well, "most don't" is an understatement. "Hardly
> any" would be more accurate. If just a small portion of people could
> contribute fairly easily that would be a big step forwar
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
Here are the subject lines for two recent svn commit emails:
[Python-checkins] commit of r41847 - in python/trunk:
Lib/test/test__locale.py Python/as...
[Python-checkins] commit of r41848 - python/trunk/setup.py
^
`--- one extra space
There is an
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 wou
[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" provi
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 th
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 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 question for Python 2.*, but
> it would be nice to keep these in min
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
__
?!ng proposes:
> Constants in all caps:
> NONE, TRUE, FALSE, ELLIPSIS
>
> Classes in initial-caps:
> Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict,
> and lots of classes in the standard library, e.g.
> anydbm.error, csv.excel, imaplib.error, mutex.
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.
___
Python-Dev mailing list
Python-Dev@p
On Friday 30 December 2005 06:10, Ka-Ping Yee wrote:
> > In fact, I like it that the basic Python functions
>
> I didn't say anything about renaming functions. Functions in lowercase
> are one of the naming conventions that Python does follow consistently.
well, it is not consistent when looking
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 t
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
Nick Coghlan wrote:
> Samuele Pedroni wrote:
>
>>Michael Chermside wrote:
>>
>>>The F-bot writes:
>>>
>>>
in reality, some things are carefully thought out and craftily im-
plemented, some things are engineering tradeoffs made at a certain time,
and some things are just accidents -- bu
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:
>>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
___
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
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
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
Armin Rigo wrote:
> I guess you mean LONG_MAX instead of MAX_INT, in the event that ssize_t
> is larger than a long.
Right, changed.
> Also, distinguishing between PyInt_AsSsize_t()
> and PyLong_AsSsize_t() doesn't seem to be useful (a quick look in your
> branch makes me guess that they both acc
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, y
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 cas
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
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
>
> [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
31 matches
Mail list logo
