Update the Py3K docs to match PEP 3100, Core Language Changes.

[GoogleCodeExporter]

PEP 3100 documents most of the Python 3.0 plans.  While most of the
core language changes have been made, the documentation does not reflect
all of them.  Go over the Python 3.0 docs,

    http://docs.python.org/dev/3.0/

and make a list of all of the places that describe behavior incompatible
with Python 3.0.  Then update the documentation appropriately.

Completion:

Attach the results of an 'svn diff' (context diff) against the Python
source tree to this task, and send a brief description of your changes
to the ghop-python mailing list.

Relevant wiki pages:

 - DocumentationAndExampleGuidelines
 - WorkingOnDocumentation
 - Python3K

Task duration: please complete this task within 5 days (120 hours) of claiming 
it.

Original issue reported on code.google.com by the.good...@gmail.com on 27 Nov 2007 at 4:11

[GoogleCodeExporter]

I claim this Task.

Original comment by dfin...@gmail.com on 4 Dec 2007 at 4:36

[GoogleCodeExporter]

Original comment by georg.br...@gmail.com on 4 Dec 2007 at 4:40

• Changed state: Claimed
• Added labels: ClaimedBy-dfinnie

[GoogleCodeExporter]

This task is due Monday, December 10, 2007 at 04:55:00 UTC.

Original comment by doug.hel...@gmail.com on 4 Dec 2007 at 4:45

• Added labels: Due-20071210

[GoogleCodeExporter]

Well, that's not 120 hours.  Make that Sunday, December 9, 2007 at 16:45:00

Original comment by doug.hel...@gmail.com on 4 Dec 2007 at 4:48

• Added labels: Due-20071209
• Removed labels: Due-20071210

[GoogleCodeExporter]

I have begun to work on this task, about 15% done or something and so far these
questions have come up:
- For true division vs. classic division vs. integer division, there is a lot of
documentation that goes "if __future__.division is true, then this behavior,
otherwise this behavior."  It seems to me that I should leave these as is, but 
I want
to make sure.

For example, library/operator.rst:174 says, "Return ``a / b`` when
``__future__.division`` is in effect.  This is also  known as "true" division." 
 So
far, I have been leaving these as-is.  Is this the correct thing to do?

- The PEP says that list comprehensions would have to have parens around 
iterables so
[x for x in 1,2] would become [x for x in (1,2)].  Must a list comprehension 
have
square brackets around it or does "for i, v in enumerate("hi", "hello",
"hey):\nprint(i + " " + x)" also a list comprehension?

- For the builtin module being updated to be builtins, should I update the reST
metadata, for example in c-api/abstract.rst:100 where it says:
".. cfunction:: int PyObject_Cmp(PyObject *o1, PyObject *o2, int *result)

   .. index:: builtin: cmp <-- UPDATE THIS?

   Compare the values of *o1* and *o2* using a routine provided by *o1*, if one
   exists, otherwise with a routine provided by *o2*.  The result of the comparison
   is returned in *result*.  Returns ``-1`` on failure.  This is the equivalent of
   the Python statement ``result = cmp(o1, o2)``."

- The PEP states all functions named func_whatever we be renamed __whatever__.  
Is
this truly all functions or just the ones mentioned in Guido's mailing list post
(http://mail.python.org/pipermail/python-3000/2006-April/001175.html), namely
"'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc',
'func_globals', and 'func_name'"?

- Should I update the "whatsnew" sections (besides that for 3.0)?  So far I 
have not
been.

Thanks in advance for the answers to these questions!

Dan Finnie

(cross-posted to the mailing list,
<http://groups.google.com/group/ghop-python/browse_thread/thread/f0f6f00cbc3af38
c>,
if you would rather respond there)

Original comment by dfin...@gmail.com on 7 Dec 2007 at 1:26

[GoogleCodeExporter]

Original comment by doug.hel...@gmail.com on 7 Dec 2007 at 1:33

• Added labels: Due-20071209.1645, NeedsReview
• Removed labels: Due-20071209

[GoogleCodeExporter]

Finally, I'm satisfied with my changes.  I have uploaded a diff here:
<http://danfinnie.com/ghop/diff3k.rev4.txt>

Please look over it and tell me what you think.

Original comment by dfin...@gmail.com on 9 Dec 2007 at 9:25

[GoogleCodeExporter]

Phew, that's a lot! I can't look at the lot of it right now, but I'll take your 
word
for granted that it's finished, and judging by what I've read it's great. 
Setting to
Completed!

What about a coding task next - 260 or 262 come to mind... just kidding :D

Original comment by georg.br...@gmail.com on 9 Dec 2007 at 9:39

• Changed state: Completed
• Removed labels: Due-20071209.1645, NeedsReview

[GoogleCodeExporter]

Thanks for your confidence :-).

I was actually considering a coding task next.  I had thought I saw one about 
storing
emails in a database but I can't find it.  262, about the broken links, looks
intriguing.  Why the "just kidding?"

Original comment by dfin...@gmail.com on 10 Dec 2007 at 1:30

[GoogleCodeExporter]

You're thinking of #225, which was claimed ;(

Original comment by the.good...@gmail.com on 10 Dec 2007 at 4:04

[GoogleCodeExporter]

I wouldn't dare prescribing your next task. However, I'll be happy if you take 
it :D

Original comment by georg.br...@gmail.com on 10 Dec 2007 at 6:13

[GoogleCodeExporter]

Original comment by georg.br...@gmail.com on 12 Dec 2007 at 7:51

• Added labels: NeedsCommit

[GoogleCodeExporter]

Committed r60492. Thanks again!

Original comment by georg.br...@gmail.com on 1 Feb 2008 at 12:01

• Removed labels: NeedsCommit