Hi Ezio,

"Regarding the output, I don't think is necessary to add it."

I left it in because of a discussion in core-mentorship, where they
mentioned that it would be beneficial to have it in. I pasted the exchange
below if you are interested.

Thanks for looking at it,

Johannes

-------------------------------------
Pasted content:

Message: 2
Date: Fri, 18 Nov 2011 04:15:03 +0200
From: Eli Bendersky <eliben@gmail.com>
To: Python Core Development Mentorship <core-mentorship@python.org>
Subject: Re: [Core-mentorship] What classes as an issue in
       documentation?
Message-ID:
       <CAF-Rda-U5Jya999K=FW6Xe8VGrSpj1pHq0EtcMZ277x2JDtv0Q@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

trying
> to gauge what is relevant and what is just a little overly picky.
>
> I applied the standard, I use when proofreading scientific texts of fellow
> researchers (which raises the bar into infinity as you may always
encounter
> someone who is willing to split hairs over a comma in the wrong position
> just to be right). I would be grateful, if you could just quickly scan
over
> the list and say in each case (I numbered them) if it is relevant or not.
>
> thanks a bundle.
>
> Johannes
>
> P.S. Also, one issue for all issues in one section (like Nick Coghlan
> suggested)
>
> ------------------------------
> Python v3.3a0 documentation ? The Python Standard Library ? 11. Data
> Persistence ?
>
> Section 11.1 pickle module
>
> #1
> 11.1.3. Module Interface
>
> exception pickle.UnpicklingError
>
> ??? Error raised when there a problem unpickling an object, such as a data
> corruption or a security violation.
> ??? It inherits PickleError.
>
> TYPO: Error raised when there IS a problem unpickling an object
>
> ------------------------------
> #2
> 11.1.3. Module Interface
>
> persistent_load(pid)
>
> ??? Raise an UnpickingError by default.
>
> TYPO: Should be "Unpick"l"ingError" as wrtten earlier in the section
>
> ------------------------------
--
> #3
> 11.1.4 What can be pickled and unpickled
>
> Note that functions (built-in and user-defined) are pickled by ?fully
> qualified? name reference, not by value.
> This means that only the function name is pickled, along with the name of
> module the function is defined in.
>
> TYPO: along with the name of "THE" module the function is defined in.
>
> --------------------------------
> #4
> 11.1.5.1. Persistence of External Objects
>
> In Windows XP SP3, example does not work out of the box as sqlite3 is not
> included when compiling python3.3a
> following the Getting Set Up directions in the Developer's Guide
>
> Is this an issue?
>
> Code works in Ubuntu 10.04 lucid.
>
> When run from Terminal, it gives the following output:
>
> Pickled records:
> [MemoRecord(key=1, task='give food to fish'),
> ?MemoRecord(key=2, task='prepare group meeting'),
> ?MemoRecord(key=3, task='fight with a zebra')]
> Unpickled records:
> [MemoRecord(key=1, task='learn italian'),
> ?MemoRecord(key=2, task='prepare group meeting'),
> ?MemoRecord(key=3, task='fight with a zebra')]
>
>
> ?Should that not be given afterwards as a reference to the user, so that
> (s)he knows, that the code is right?
>
> --------------------------------
> #5
> 11.1.6 Restricting Globals
>
> Thus it is possible to either forbid completely globals
>
> NOTE: should be "either completely forbid globals"
>

Johannes,

These look perfectly valid to me. Even the smallest typos mentioned
here are worth fixing. The next step is opening an issue in the
tracker (http://bugs.python.org/) and submitting a patch.

Eli

------------------------------

Message: 3
Date: Fri, 18 Nov 2011 13:17:11 +1000
From: Nick Coghlan <ncoghlan@gmail.com>
To: Python Core Development Mentorship <core-mentorship@python.org>
Subject: Re: [Core-mentorship] What classes as an issue in
       documentation?
Message-ID:
       <CADiSq7cH_inw_3MUM8huro4GFT=uT7XOF04DE-cSb+BnjKRumg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 18, 2011 at 12:15 PM, Eli Bendersky <eliben@gmail.com> wrote:
> Johannes,
>
> These look perfectly valid to me. Even the smallest typos mentioned
> here are worth fixing. The next step is opening an issue in the
> tracker (http://bugs.python.org/) and submitting a patch.

Although I'll note that even if you're not yet ready to make the patch
yourself, a detailed report like this one makes it very easy for
someone *else* to produce a patch, so the tracker issue is the most
important next step.

Lots of things have to happen for a change to get into the source
tree, and the reason we have tools like the tracker around is so that
the work can be coordinated amongst multiple people.

Even as core devs, we'll still often post changes we design, code and
commit ourselves as tracker issues for a while, just so we have a
venue to coordinate reviews and gather feedback.

Cheers,
Nick.