From report at bugs.python.org  Sun Nov  1 01:20:15 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 Nov 2015 05:20:15 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446355215.71.0.892272038616.issue25523@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Yes, the Lib/test/decimaltestdata files do come from an external source. I don't see the harm in including them in the changes, but those changes will be overwritten when the files are next updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sun Nov  1 01:20:44 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 Nov 2015 05:20:44 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446355244.45.0.709847101096.issue25523@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I should have said what that source is: it's http://speleotrove.com/decimal/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sun Nov  1 02:39:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 01 Nov 2015 07:39:24 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446363564.28.0.489674911395.issue25523@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks everyone for the comments. Serhiy?s points:

I did this by using ?grep? and then manually editing all of the appropriate lines. So they were not generated by a script, but because it is a fairly mindless process I could have made human mistakes.

In multiprocessing.rst, socket.rst, I removed ?a? because I thought it matched the surrounding text, e.g. it already says nearby ?If .?.?. then OSError is raised?, rather than ?an OSError is raised?. I find the documentation uses both forms in many places, so I just try to keep things consistent with the nearby text.

In 3.2.rst, I thought it should be plural: ?total_ordering() will use existing equality and inequality methods?. I could reword it to something like ?will use an existing equality and inequality method? if you prefer. Either way seems valid to me.

In HISTORY, I removed ?a? from ?.?.?. is passed ill-formed input? because it seemed better (similar to ?is passed hot water?). But ?an ill-formed input? should also be fine if people prefer.

_hashopenssl.c: ?have a its own definition? is nonsense, hence I removed ?a?.

?An SMTP?: See Emanuel and David. The rest of the page uses ?an SMTP?, while I only found two instances of ?a SMTP?, which I made consistent.

Externally-supplied decimaltestdata: I did wonder about this. Looking at the history, I saw other local changes, but now I notice most are in a special ?extra.decTest? file. Anyway, as Mark says it is okay I will let my changes go ahead for the time being.

David: I have incorporated your suggestion for test_discovery.py into my local patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sun Nov  1 02:56:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Nov 2015 07:56:28 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446364588.89.0.177712534833.issue25523@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I had pointed to some of changes not because they look wrong to me, but for the case if there are human mistakes. After your acknowledgement all LGTM.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sun Nov  1 15:02:59 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Sun, 01 Nov 2015 20:02:59 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446408179.37.0.435572685487.issue25041@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Thank you very much for the feedback, Martin and Berker!
I'll start working on the revised patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Sun Nov  1 23:29:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Nov 2015 04:29:19 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <20151102042915.12527.52328@psf.io>


Roundup Robot added the comment:

New changeset d8ff13414deb by Martin Panter in branch '3.4':
Issue #25523: Correct "a" article to "an" article
https://hg.python.org/cpython/rev/d8ff13414deb

New changeset e279ab6753fd by Martin Panter in branch '3.5':
Issue #25523: Merge "a" to "an" fixes from 3.4 into 3.5
https://hg.python.org/cpython/rev/e279ab6753fd

New changeset 2347271172b3 by Martin Panter in branch '3.5':
Issue #25523: Further a-to-an corrections new in 3.5
https://hg.python.org/cpython/rev/2347271172b3

New changeset 96e61bb7f6e9 by Martin Panter in branch 'default':
Issue #25523: Merge a-to-an corrections from 3.5
https://hg.python.org/cpython/rev/96e61bb7f6e9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sun Nov  1 23:34:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Nov 2015 04:34:04 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446438844.41.0.894195312889.issue25523@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Mon Nov  2 02:34:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Nov 2015 07:34:15 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446449653.76.0.962938097227.issue25523@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with additional changes.

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file40925/a-an_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Mon Nov  2 04:47:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Nov 2015 09:47:46 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446457666.77.0.552751328495.issue25523@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Serhiy. My pass over the files missed most cases where there was a line break involved, and certain punctuation and markup, which you picked up on.

I skipped the /Lib/msilib/schema.py file in my patch because it was part of the data rather than a comment, and I wasn?t sure what it is for. It seems to be a generated file from some Windows source. But I see other people have made similar corrections, so it might be okay.

I left a couple of comments. Apart from those, the rest look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Mon Nov  2 08:07:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Nov 2015 13:07:10 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <20151102130706.504.2452@psf.io>


Roundup Robot added the comment:

New changeset 75df8b0a2cd1 by Serhiy Storchaka in branch '3.4':
Issue #25523: Further a-to-an corrections.
https://hg.python.org/cpython/rev/75df8b0a2cd1

New changeset 68edc7baeef7 by Serhiy Storchaka in branch '3.5':
Issue #25523: Merge a-to-an corrections from 3.4.
https://hg.python.org/cpython/rev/68edc7baeef7

New changeset a0d0f968b020 by Serhiy Storchaka in branch '3.5':
Issue #25523: Further a-to-an corrections new in 3.5.
https://hg.python.org/cpython/rev/a0d0f968b020

New changeset 72cca30f4707 by Serhiy Storchaka in branch 'default':
Issue #25523: Merge a-to-an corrections from 3.5.
https://hg.python.org/cpython/rev/72cca30f4707

New changeset e8f3c011e2b4 by Serhiy Storchaka in branch '2.7':
Issue #25523: Backported a-to-an corrections.
https://hg.python.org/cpython/rev/e8f3c011e2b4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From JPKowal at yahoo.com  Sun Nov  1 01:02:58 2015
From: JPKowal at yahoo.com (JPKowal at yahoo.com)
Date: Sun, 1 Nov 2015 00:02:58 -0500
Subject: [docs] (no subject)
Message-ID: <000001d11462$94ae3390$be0a9ab0$@yahoo.com>

Look here about CSV files

https://docs.python.org/3.3/library/csv.html


If you want to work with CSV files you are
essentially
dealing with small databases. Why THE FUCK do you
not give
any meaningful examples towards that goal.


Something like this that I had to go digging for
and took forever
to find (NOT ON YOUR SHITTY SITE OF COURSE)
 
THIS IS ONLY ONE EXAMPLE OUT OF 100's OF WHY YOUR
SITE IS WORTHLESS
 
 
FUCK YOU DICKHEADS!!!!!



for row in myreader:
    id, name, volt = row
    bus_id.append(id)
    bus_names.append(name)
    voltage.append(float(volt))
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151101/1735bff2/attachment-0001.html>

From k.damstra at hotmail.com  Sun Nov  1 07:22:20 2015
From: k.damstra at hotmail.com (K. Damstra)
Date: Sun, 1 Nov 2015 13:22:20 +0100
Subject: [docs] Outdated link
Message-ID: <BLU437-SMTP6239BB804D312FC6603A93F62D0@phx.gbl>

Sir, Madam,

There is an outdated link on the website
https://docs.python.org/2.7/library/tkinter.html .
The link "Programming Python" is found under "See also".

Kind regards, Klaas.


From vadmium+py at gmail.com  Mon Nov  2 04:36:38 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 02 Nov 2015 09:36:38 -0000
Subject: [docs] Correct "a" article to "an" article (issue 25523)
Message-ID: <20151102093638.8423.74077@psf.upfronthosting.co.za>

Reviewers: ,


http://bugs.python.org/review/25523/diff/15867/Doc/whatsnew/3.3.rst
File Doc/whatsnew/3.3.rst (right):

http://bugs.python.org/review/25523/diff/15867/Doc/whatsnew/3.3.rst#newcode2158
Doc/whatsnew/3.3.rst:2158: * repeating a single ASCII letter and getting
a substring of ASCII strings
I think it would read even better in the singular:

repeating a single ASCII letter and getting a substring of an ASCII
string . . .

http://bugs.python.org/review/25523/diff/15867/Lib/test/test_codecs.py
File Lib/test/test_codecs.py (right):

http://bugs.python.org/review/25523/diff/15867/Lib/test/test_codecs.py#newcode1247
Lib/test/test_codecs.py:1247: # An Arabic (Egyptian):
Looking at the other comments I think this is just meant to be the
letter A not the word ?a? :)

http://bugs.python.org/review/25523/diff/15867/Objects/longobject.c
File Objects/longobject.c (right):

http://bugs.python.org/review/25523/diff/15867/Objects/longobject.c#newcode4475
Objects/longobject.c:4475: /* no progress; do an Euclidean step */
I would pronounce this ?a yooclidean?, not ?an ooclidean? or something.
This could be controversial, so maybe leave it as it was.



Please review this at http://bugs.python.org/review/25523/

Affected files:
  Doc/distutils/packageindex.rst
  Doc/howto/descriptor.rst
  Doc/install/index.rst
  Doc/library/asyncio-protocol.rst
  Doc/library/contextlib.rst
  Doc/library/email.parser.rst
  Doc/library/glob.rst
  Doc/library/gzip.rst
  Doc/library/pickle.rst
  Doc/library/socket.rst
  Doc/library/tokenize.rst
  Doc/library/unittest.rst
  Doc/library/urllib.request.rst
  Doc/library/xml.dom.minidom.rst
  Doc/library/zlib.rst
  Doc/whatsnew/2.7.rst
  Doc/whatsnew/3.3.rst
  Include/unicodeobject.h
  Lib/asyncio/sslproto.py
  Lib/asyncio/transports.py
  Lib/ctypes/test/test_random_things.py
  Lib/http/cookiejar.py
  Lib/lib2to3/fixes/fix_metaclass.py
  Lib/msilib/schema.py
  Lib/test/libregrtest/cmdline.py
  Lib/test/test_asdl_parser.py
  Lib/test/test_codecs.py
  Lib/test/test_dict.py
  Lib/test/test_io.py
  Lib/test/test_socket.py
  Lib/test/test_userdict.py
  Lib/tkinter/__init__.py
  Misc/HISTORY
  Misc/NEWS
  Modules/_ssl.c
  Modules/itertoolsmodule.c
  Objects/longobject.c
  Objects/unicodeobject.c


diff -r 83fa2e9b0038 Doc/distutils/packageindex.rst
--- a/Doc/distutils/packageindex.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/distutils/packageindex.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -167,7 +167,7 @@ follows::
     username: <username>
     password: <password>
 
-The *distutils* section defines a *index-servers* variable that lists the
+The *distutils* section defines an *index-servers* variable that lists the
 name of all sections describing a repository.
 
 Each section describing a repository defines three variables:
diff -r 83fa2e9b0038 Doc/howto/descriptor.rst
--- a/Doc/howto/descriptor.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/howto/descriptor.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -319,7 +319,7 @@ Non-data descriptors provide a simple me
 patterns of binding functions into methods.
 
 To recap, functions have a :meth:`__get__` method so that they can be converted
-to a method when accessed as attributes.  The non-data descriptor transforms a
+to a method when accessed as attributes.  The non-data descriptor transforms an
 ``obj.f(*args)`` call into ``f(obj, *args)``.  Calling ``klass.f(*args)``
 becomes ``f(*args)``.
 
diff -r 83fa2e9b0038 Doc/install/index.rst
--- a/Doc/install/index.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/install/index.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -148,7 +148,7 @@ into.  For example, if you've just downl
 
 On Windows, you'd probably download :file:`foo-1.0.zip`.  If you downloaded the
 archive file to :file:`C:\\Temp`, then it would unpack into
-:file:`C:\\Temp\\foo-1.0`; you can use either a archive manipulator with a
+:file:`C:\\Temp\\foo-1.0`; you can use either an archive manipulator with a
 graphical user interface (such as WinZip) or a command-line tool (such as
 :program:`unzip` or :program:`pkunzip`) to unpack the archive.  Then, open a
 command prompt window and run::
diff -r 83fa2e9b0038 Doc/library/asyncio-protocol.rst
--- a/Doc/library/asyncio-protocol.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/asyncio-protocol.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -148,7 +148,7 @@ WriteTransport
       high-water limit.  Neither *high* nor *low* can be negative.
 
       The defaults are implementation-specific.  If only the
-      high-water limit is given, the low-water limit defaults to a
+      high-water limit is given, the low-water limit defaults to an
       implementation-specific value less than or equal to the
       high-water limit.  Setting *high* to zero forces *low* to zero as
       well, and causes :meth:`pause_writing` to be called whenever the
diff -r 83fa2e9b0038 Doc/library/contextlib.rst
--- a/Doc/library/contextlib.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/contextlib.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -142,7 +142,7 @@ Functions and classes provided:
    is hardwired to stdout.
 
    For example, the output of :func:`help` normally is sent to *sys.stdout*.
-   You can capture that output in a string by redirecting the output to a
+   You can capture that output in a string by redirecting the output to an
    :class:`io.StringIO` object::
 
         f = io.StringIO()
diff -r 83fa2e9b0038 Doc/library/email.parser.rst
--- a/Doc/library/email.parser.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/email.parser.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -146,7 +146,7 @@ have the same API as the :class:`Parser`
       methods on file-like objects.
 
       The text contained in *fp* must be formatted as a block of :rfc:`2822`
-      style headers and header continuation lines, optionally preceded by a
+      style headers and header continuation lines, optionally preceded by an
       envelope header.  The header block is terminated either by the end of the
       data or by a blank line.  Following the header block is the body of the
       message (which may contain MIME-encoded subparts).
@@ -189,7 +189,7 @@ have the same API as the :class:`Parser`
       methods on file-like objects.
 
       The bytes contained in *fp* must be formatted as a block of :rfc:`2822`
-      style headers and header continuation lines, optionally preceded by a
+      style headers and header continuation lines, optionally preceded by an
       envelope header.  The header block is terminated either by the end of the
       data or by a blank line.  Following the header block is the body of the
       message (which may contain MIME-encoded subparts, including subparts
diff -r 83fa2e9b0038 Doc/library/glob.rst
--- a/Doc/library/glob.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/glob.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -38,7 +38,7 @@ For example, ``'[?]'`` matches the chara
    symlinks are included in the results (as in the shell).
 
    If *recursive* is true, the pattern "``**``" will match any files and zero or
-   more directories and subdirectories.  If the pattern is followed by a
+   more directories and subdirectories.  If the pattern is followed by an
    ``os.sep``, only directories and subdirectories match.
 
    .. note::
diff -r 83fa2e9b0038 Doc/library/gzip.rst
--- a/Doc/library/gzip.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/gzip.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -64,7 +64,7 @@ The module defines the following items:
    method.  At least one of *fileobj* and *filename* must be given a non-trivial
    value.
 
-   The new class instance is based on *fileobj*, which can be a regular file, a
+   The new class instance is based on *fileobj*, which can be a regular file, an
    :class:`io.BytesIO` object, or any other object which simulates a file.  It
    defaults to ``None``, in which case *filename* is opened to provide a file
    object.
diff -r 83fa2e9b0038 Doc/library/pickle.rst
--- a/Doc/library/pickle.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/pickle.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -192,7 +192,7 @@ process more convenient:
    number is specified, :data:`HIGHEST_PROTOCOL` is selected.
 
    The *file* argument must have a write() method that accepts a single bytes
-   argument.  It can thus be an on-disk file opened for binary writing, a
+   argument.  It can thus be an on-disk file opened for binary writing, an
    :class:`io.BytesIO` instance, or any other custom object that meets this
    interface.
 
@@ -288,7 +288,7 @@ The :mod:`pickle` module exports two cla
    number is specified, :data:`HIGHEST_PROTOCOL` is selected.
 
    The *file* argument must have a write() method that accepts a single bytes
-   argument.  It can thus be an on-disk file opened for binary writing, a
+   argument.  It can thus be an on-disk file opened for binary writing, an
    :class:`io.BytesIO` instance, or any other custom object that meets this
    interface.
 
diff -r 83fa2e9b0038 Doc/library/socket.rst
--- a/Doc/library/socket.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/socket.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -786,7 +786,7 @@ The :mod:`socket` module also offers var
 
 .. function:: sethostname(name)
 
-   Set the machine's hostname to *name*.  This will raise a
+   Set the machine's hostname to *name*.  This will raise an
    :exc:`OSError` if you don't have enough rights.
 
    Availability: Unix.
@@ -818,7 +818,7 @@ The :mod:`socket` module also offers var
 
 .. function:: if_indextoname(if_index)
 
-   Return a network interface name corresponding to a
+   Return a network interface name corresponding to an
    interface index number.
    :exc:`OSError` if no interface with the given index exists.
 
diff -r 83fa2e9b0038 Doc/library/tokenize.rst
--- a/Doc/library/tokenize.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/tokenize.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -41,7 +41,7 @@ The primary entry point is a :term:`gene
    returned as a :term:`named tuple` with the field names:
    ``type string start end line``.
 
-   The returned :term:`named tuple` has a additional property named
+   The returned :term:`named tuple` has an additional property named
    ``exact_type`` that contains the exact operator type for
    :data:`token.OP` tokens.  For all other token types ``exact_type``
    equals the named tuple ``type`` field.
diff -r 83fa2e9b0038 Doc/library/unittest.rst
--- a/Doc/library/unittest.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/unittest.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -471,7 +471,7 @@ Skipping tests and expected failures
 .. versionadded:: 3.1
 
 Unittest supports skipping individual test methods and even whole classes of
-tests.  In addition, it supports marking a test as a "expected failure," a test
+tests.  In addition, it supports marking a test as an "expected failure," a test
 that is broken and will fail, but shouldn't be counted as a failure on a
 :class:`TestResult`.
 
diff -r 83fa2e9b0038 Doc/library/urllib.request.rst
--- a/Doc/library/urllib.request.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/urllib.request.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -1383,7 +1383,7 @@ some point in the future.
     .. method:: retrieve(url, filename=None, reporthook=None, data=None)
 
        Retrieves the contents of *url* and places it in *filename*.  The return value
-       is a tuple consisting of a local filename and either a
+       is a tuple consisting of a local filename and either an
        :class:`email.message.Message` object containing the response headers (for remote
        URLs) or ``None`` (for local URLs).  The caller must then open and read the
        contents of *filename*.  If *filename* is not given and the URL refers to a
diff -r 83fa2e9b0038 Doc/library/xml.dom.minidom.rst
--- a/Doc/library/xml.dom.minidom.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/xml.dom.minidom.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -54,7 +54,7 @@ instead:
 
 .. function:: parseString(string, parser=None)
 
-   Return a :class:`Document` that represents the *string*. This method creates a
+   Return a :class:`Document` that represents the *string*. This method creates an
    :class:`io.StringIO` object for the string and passes that on to :func:`parse`.
 
 Both functions return a :class:`Document` object representing the content of the
diff -r 83fa2e9b0038 Doc/library/zlib.rst
--- a/Doc/library/zlib.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/library/zlib.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -30,7 +30,7 @@ The available exception and functions in
 
 .. function:: adler32(data[, value])
 
-   Computes a Adler-32 checksum of *data*.  (An Adler-32 checksum is almost as
+   Computes an Adler-32 checksum of *data*.  (An Adler-32 checksum is almost as
    reliable as a CRC32 but can be computed much more quickly.)  If *value* is
    present, it is used as the starting value of the checksum; otherwise, a fixed
    default value is used.  This allows computing a running checksum over the
diff -r 83fa2e9b0038 Doc/whatsnew/2.7.rst
--- a/Doc/whatsnew/2.7.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/whatsnew/2.7.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -1118,7 +1118,7 @@ changes, or look through the Subversion 
   (Fixed by Daniel Stutzbach; :issue:`8729`.)
 
 * Constructors for the parsing classes in the :mod:`ConfigParser` module now
-  take a *allow_no_value* parameter, defaulting to false; if true,
+  take an *allow_no_value* parameter, defaulting to false; if true,
   options without values will be allowed.  For example::
 
     >>> import ConfigParser, StringIO
diff -r 83fa2e9b0038 Doc/whatsnew/3.3.rst
--- a/Doc/whatsnew/3.3.rst	Mon Nov 02 00:39:56 2015 -0500
+++ b/Doc/whatsnew/3.3.rst	Mon Nov 02 09:30:41 2015 +0200
@@ -2155,7 +2155,7 @@ Major performance enhancements have been
   * encode an ASCII string to UTF-8 doesn't need to encode characters anymore,
     the UTF-8 representation is shared with the ASCII representation
   * the UTF-8 encoder has been optimized
-  * repeating a single ASCII letter and getting a substring of a ASCII strings
+  * repeating a single ASCII letter and getting a substring of ASCII strings
     is 4 times faster
 
 * UTF-8 is now 2x to 4x faster.  UTF-16 encoding is now up to 10x faster.
diff -r 83fa2e9b0038 Include/unicodeobject.h
--- a/Include/unicodeobject.h	Mon Nov 02 00:39:56 2015 -0500
+++ b/Include/unicodeobject.h	Mon Nov 02 09:30:41 2015 +0200
@@ -982,7 +982,7 @@ PyAPI_FUNC(int)
     Py_ssize_t end
     );
 
-/* Append a ASCII-encoded byte string.
+/* Append an ASCII-encoded byte string.
    Return 0 on success, raise an exception and return -1 on error. */
 PyAPI_FUNC(int)
 _PyUnicodeWriter_WriteASCIIString(_PyUnicodeWriter *writer,
@@ -2058,7 +2058,7 @@ PyAPI_FUNC(PyObject *) PyUnicode_RichCom
     int op                      /* Operation: Py_EQ, Py_NE, Py_GT, etc. */
     );
 
-/* Apply a argument tuple or dictionary to a format string and return
+/* Apply an argument tuple or dictionary to a format string and return
    the resulting Unicode string. */
 
 PyAPI_FUNC(PyObject *) PyUnicode_Format(
diff -r 83fa2e9b0038 Lib/asyncio/sslproto.py
--- a/Lib/asyncio/sslproto.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/asyncio/sslproto.py	Mon Nov 02 09:30:41 2015 +0200
@@ -349,7 +349,7 @@ class _SSLProtocolTransport(transports._
         high-water limit.  Neither value can be negative.
 
         The defaults are implementation-specific.  If only the
-        high-water limit is given, the low-water limit defaults to a
+        high-water limit is given, the low-water limit defaults to an
         implementation-specific value less than or equal to the
         high-water limit.  Setting high to zero forces low to zero as
         well, and causes pause_writing() to be called whenever the
diff -r 83fa2e9b0038 Lib/asyncio/transports.py
--- a/Lib/asyncio/transports.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/asyncio/transports.py	Mon Nov 02 09:30:41 2015 +0200
@@ -62,7 +62,7 @@ class WriteTransport(BaseTransport):
         high-water limit.  Neither value can be negative.
 
         The defaults are implementation-specific.  If only the
-        high-water limit is given, the low-water limit defaults to a
+        high-water limit is given, the low-water limit defaults to an
         implementation-specific value less than or equal to the
         high-water limit.  Setting high to zero forces low to zero as
         well, and causes pause_writing() to be called whenever the
diff -r 83fa2e9b0038 Lib/ctypes/test/test_random_things.py
--- a/Lib/ctypes/test/test_random_things.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/ctypes/test/test_random_things.py	Mon Nov 02 09:30:41 2015 +0200
@@ -30,7 +30,7 @@ class CallbackTracbackTestCase(unittest.
     # value is printed correctly.
     #
     # Changed in 0.9.3: No longer is '(in callback)' prepended to the
-    # error message - instead a additional frame for the C code is
+    # error message - instead an additional frame for the C code is
     # created, then a full traceback printed.  When SystemExit is
     # raised in a callback function, the interpreter exits.
 
diff -r 83fa2e9b0038 Lib/http/cookiejar.py
--- a/Lib/http/cookiejar.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/http/cookiejar.py	Mon Nov 02 09:30:41 2015 +0200
@@ -1437,7 +1437,7 @@ class CookieJar:
                         break
                     # convert RFC 2965 Max-Age to seconds since epoch
                     # XXX Strictly you're supposed to follow RFC 2616
-                    #   age-calculation rules.  Remember that zero Max-Age is a
+                    #   age-calculation rules.  Remember that zero Max-Age
                     #   is a request to discard (old and new) cookie, though.
                     k = "expires"
                     v = self._now + v
diff -r 83fa2e9b0038 Lib/lib2to3/fixes/fix_metaclass.py
--- a/Lib/lib2to3/fixes/fix_metaclass.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/lib2to3/fixes/fix_metaclass.py	Mon Nov 02 09:30:41 2015 +0200
@@ -114,7 +114,7 @@ def find_metas(cls_node):
                 left_node = expr_node.children[0]
                 if isinstance(left_node, Leaf) and \
                         left_node.value == '__metaclass__':
-                    # We found a assignment to __metaclass__.
+                    # We found an assignment to __metaclass__.
                     fixup_simple_stmt(node, i, simple_node)
                     remove_trailing_newline(simple_node)
                     yield (node, i, simple_node)
diff -r 83fa2e9b0038 Lib/msilib/schema.py
--- a/Lib/msilib/schema.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/msilib/schema.py	Mon Nov 02 09:30:41 2015 +0200
@@ -733,7 +733,7 @@ tables=[_Validation, ActionText, AdminEx
 ('CustomAction','Source','Y',None, None, None, None, 'CustomSource',None, 'The table reference of the source of the code.',),
 ('CustomAction','Target','Y',None, None, None, None, 'Formatted',None, 'Excecution parameter, depends on the type of custom action',),
 ('DrLocator','Signature_','N',None, None, None, None, 'Identifier',None, 'The Signature_ represents a unique file signature and is also the foreign key in the Signature table.',),
-('DrLocator','Path','Y',None, None, None, None, 'AnyPath',None, 'The path on the user system. This is a either a subpath below the value of the Parent or a full path. The path may contain properties enclosed within [ ] that will be expanded.',),
+('DrLocator','Path','Y',None, None, None, None, 'AnyPath',None, 'The path on the user system. This is either a subpath below the value of the Parent or a full path. The path may contain properties enclosed within [ ] that will be expanded.',),
 ('DrLocator','Depth','Y',0,32767,None, None, None, None, 'The depth below the path to which the Signature_ is recursively searched. If absent, the depth is assumed to be 0.',),
 ('DrLocator','Parent','Y',None, None, None, None, 'Identifier',None, 'The parent file signature. It is also a foreign key in the Signature table. If null and the Path column does not expand to a full path, then all the fixed drives of the user system are searched using the Path.',),
 ('DuplicateFile','File_','N',None, None, 'File',1,'Identifier',None, 'Foreign key referencing the source file to be duplicated.',),
diff -r 83fa2e9b0038 Lib/test/libregrtest/cmdline.py
--- a/Lib/test/libregrtest/cmdline.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/libregrtest/cmdline.py	Mon Nov 02 09:30:41 2015 +0200
@@ -25,7 +25,7 @@ python -E -Wd -m test [options] [test_na
 EPILOG = """\
 Additional option details:
 
--r randomizes test execution order. You can use --randseed=int to provide a
+-r randomizes test execution order. You can use --randseed=int to provide an
 int seed value for the randomizer; this is useful for reproducing troublesome
 test orders.
 
diff -r 83fa2e9b0038 Lib/test/test_asdl_parser.py
--- a/Lib/test/test_asdl_parser.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/test_asdl_parser.py	Mon Nov 02 09:30:41 2015 +0200
@@ -21,7 +21,7 @@ class TestAsdlParser(unittest.TestCase):
     def setUpClass(cls):
         # Loads the asdl module dynamically, since it's not in a real importable
         # package.
-        # Parses Python.asdl into a ast.Module and run the check on it.
+        # Parses Python.asdl into an ast.Module and run the check on it.
         # There's no need to do this for each test method, hence setUpClass.
         sys.path.insert(0, parser_dir)
         loader = importlib.machinery.SourceFileLoader(
diff -r 83fa2e9b0038 Lib/test/test_codecs.py
--- a/Lib/test/test_codecs.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/test_codecs.py	Mon Nov 02 09:30:41 2015 +0200
@@ -1244,7 +1244,7 @@ class RecodingTest(unittest.TestCase):
 
 # From RFC 3492
 punycode_testcases = [
-    # A Arabic (Egyptian):
+    # An Arabic (Egyptian):
     ("\u0644\u064A\u0647\u0645\u0627\u0628\u062A\u0643\u0644"
      "\u0645\u0648\u0634\u0639\u0631\u0628\u064A\u061F",
      b"egbpdaj6bu4bxfgehfvwxn"),
diff -r 83fa2e9b0038 Lib/test/test_dict.py
--- a/Lib/test/test_dict.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/test_dict.py	Mon Nov 02 09:30:41 2015 +0200
@@ -603,7 +603,7 @@ class DictTest(unittest.TestCase):
         # (D) subclass defines __missing__ method returning a value
         # (E) subclass defines __missing__ method raising RuntimeError
         # (F) subclass sets __missing__ instance variable (no effect)
-        # (G) subclass doesn't define __missing__ at a all
+        # (G) subclass doesn't define __missing__ at all
         class D(dict):
             def __missing__(self, key):
                 return 42
diff -r 83fa2e9b0038 Lib/test/test_io.py
--- a/Lib/test/test_io.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/test_io.py	Mon Nov 02 09:30:41 2015 +0200
@@ -15,7 +15,7 @@
 ################################################################################
 # When writing tests for io, it's important to test both the C and Python
 # implementations. This is usually done by writing a base test that refers to
-# the type it is testing as a attribute. Then it provides custom subclasses to
+# the type it is testing as an attribute. Then it provides custom subclasses to
 # test both implementations. This file has lots of examples.
 ################################################################################
 
diff -r 83fa2e9b0038 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/test_socket.py	Mon Nov 02 09:30:41 2015 +0200
@@ -4549,7 +4549,7 @@ class TestUnixDomain(unittest.TestCase):
         except OSError as e:
             if str(e) == "AF_UNIX path too long":
                 self.skipTest(
-                    "Pathname {0!a} is too long to serve as a AF_UNIX path"
+                    "Pathname {0!a} is too long to serve as an AF_UNIX path"
                     .format(path))
             else:
                 raise
diff -r 83fa2e9b0038 Lib/test/test_userdict.py
--- a/Lib/test/test_userdict.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/test/test_userdict.py	Mon Nov 02 09:30:41 2015 +0200
@@ -171,7 +171,7 @@ class UserDictTest(mapping_tests.TestHas
         # (D) subclass defines __missing__ method returning a value
         # (E) subclass defines __missing__ method raising RuntimeError
         # (F) subclass sets __missing__ instance variable (no effect)
-        # (G) subclass doesn't define __missing__ at a all
+        # (G) subclass doesn't define __missing__ at all
         class D(collections.UserDict):
             def __missing__(self, key):
                 return 42
diff -r 83fa2e9b0038 Lib/tkinter/__init__.py
--- a/Lib/tkinter/__init__.py	Mon Nov 02 00:39:56 2015 -0500
+++ b/Lib/tkinter/__init__.py	Mon Nov 02 09:30:41 2015 +0200
@@ -1123,7 +1123,7 @@ class Misc:
 
         return self._bind(('bind', className), sequence, func, add, 0)
     def unbind_class(self, className, sequence):
-        """Unbind for a all widgets with bindtag CLASSNAME for event SEQUENCE
+        """Unbind for all widgets with bindtag CLASSNAME for event SEQUENCE
         all functions."""
         self.tk.call('bind', className , sequence, '')
     def mainloop(self, n=0):
diff -r 83fa2e9b0038 Misc/HISTORY
--- a/Misc/HISTORY	Mon Nov 02 00:39:56 2015 -0500
+++ b/Misc/HISTORY	Mon Nov 02 09:30:41 2015 +0200
@@ -12412,7 +12412,7 @@ Extension Modules
 
 - Bug #1194181: bz2.BZ2File didn't handle mode 'U' correctly.
 
-- Patch #1212117: os.stat().st_flags is now accessible as a attribute
+- Patch #1212117: os.stat().st_flags is now accessible as an attribute
   if available on the platform.
 
 - Patch #1103951: Expose O_SHLOCK and O_EXLOCK in the posix module if
diff -r 83fa2e9b0038 Misc/NEWS
--- a/Misc/NEWS	Mon Nov 02 00:39:56 2015 -0500
+++ b/Misc/NEWS	Mon Nov 02 09:30:41 2015 +0200
@@ -2651,7 +2651,7 @@ Library
 
 - Issue #20170: Convert posixmodule to use Argument Clinic.
 
-- Issue #21539: Add a *exists_ok* argument to `Pathlib.mkdir()` to mimic
+- Issue #21539: Add an *exists_ok* argument to `Pathlib.mkdir()` to mimic
   `mkdir -p` and `os.makedirs()` functionality.  When true, ignore
   FileExistsErrors.  Patch by Berker Peksag.
 
@@ -3240,7 +3240,7 @@ IDLE
   Changes are written to HOME/.idlerc/config-extensions.cfg.
   Original patch by Tal Einat.
 
-- Issue #16233: A module browser (File : Class Browser, Alt+C) requires a
+- Issue #16233: A module browser (File : Class Browser, Alt+C) requires an
   editor window with a filename.  When Class Browser is requested otherwise,
   from a shell, output window, or 'Untitled' editor, Idle no longer displays
   an error box.  It now pops up an Open Module box (Alt+M). If a valid name
diff -r 83fa2e9b0038 Modules/_ssl.c
--- a/Modules/_ssl.c	Mon Nov 02 00:39:56 2015 -0500
+++ b/Modules/_ssl.c	Mon Nov 02 09:30:41 2015 +0200
@@ -2996,7 +2996,7 @@ static PyObject *
             cadata_ascii = PyUnicode_AsASCIIString(cadata);
             if (cadata_ascii == NULL) {
                 PyErr_SetString(PyExc_TypeError,
-                                "cadata should be a ASCII string or a "
+                                "cadata should be an ASCII string or a "
                                 "bytes-like object");
                 goto error;
             }
@@ -3273,7 +3273,7 @@ static int
     ssl = SSL_get_app_data(s);
     assert(PySSLSocket_Check(ssl));
 
-    /* The servername callback expects a argument that represents the current
+    /* The servername callback expects an argument that represents the current
      * SSL connection and that has a .context attribute that can be changed to
      * identify the requested hostname. Since the official API is the Python
      * level API we want to pass the callback a Python level object rather than
diff -r 83fa2e9b0038 Modules/itertoolsmodule.c
--- a/Modules/itertoolsmodule.c	Mon Nov 02 00:39:56 2015 -0500
+++ b/Modules/itertoolsmodule.c	Mon Nov 02 09:30:41 2015 +0200
@@ -1743,7 +1743,7 @@ PyDoc_STRVAR(starmap_doc,
 "starmap(function, sequence) --> starmap object\n\
 \n\
 Return an iterator whose values are returned from the function evaluated\n\
-with a argument tuple taken from the given sequence.");
+with an argument tuple taken from the given sequence.");
 
 static PyTypeObject starmap_type = {
     PyVarObject_HEAD_INIT(NULL, 0)
diff -r 83fa2e9b0038 Objects/longobject.c
--- a/Objects/longobject.c	Mon Nov 02 00:39:56 2015 -0500
+++ b/Objects/longobject.c	Mon Nov 02 09:30:41 2015 +0200
@@ -4472,7 +4472,7 @@ PyObject *
         }
 
         if (k == 0) {
-            /* no progress; do a Euclidean step */
+            /* no progress; do an Euclidean step */
             if (l_divmod(a, b, NULL, &r) < 0)
                 goto error;
             Py_DECREF(a);
diff -r 83fa2e9b0038 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Mon Nov 02 00:39:56 2015 -0500
+++ b/Objects/unicodeobject.c	Mon Nov 02 09:30:41 2015 +0200
@@ -1865,7 +1865,7 @@ PyUnicode_Resize(PyObject **p_unicode, P
     return unicode_resize(p_unicode, length);
 }
 
-/* Copy a ASCII or latin1 char* string into a Python Unicode string.
+/* Copy an ASCII or latin1 char* string into a Python Unicode string.
 
    WARNING: The function doesn't copy the terminating null character and
    doesn't check the maximum character (may write a latin1 character in an
@@ -7411,7 +7411,7 @@ error:
 }
 
 /*
- * Encode a Unicode string to a Windows code page into a byte string using a
+ * Encode a Unicode string to a Windows code page into a byte string using an
  * error handler.
  *
  * Returns consumed characters if succeed, or raise an OSError and returns



From yanzhaoxun at greendh.com  Mon Nov  2 00:22:00 2015
From: yanzhaoxun at greendh.com (=?UTF-8?B?6ZiO5YWG54+j?=)
Date: Mon, 2 Nov 2015 13:22:00 +0800 (CST)
Subject: [docs] =?utf-8?q?Tks=3ARe=3A__Bug_on_=22open=22_function?=
Message-ID: <418869351.3524210.1446441720795.JavaMail.xmail@wmthree-3>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151102/6b4dd84b/attachment.html>

From storchaka at gmail.com  Mon Nov  2 08:37:00 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Mon, 02 Nov 2015 13:37:00 -0000
Subject: [docs] Correct "a" article to "an" article (issue 25523)
Message-ID: <20151102133700.19102.14240@psf.upfronthosting.co.za>


http://bugs.python.org/review/25523/diff/15867/Doc/whatsnew/3.3.rst
File Doc/whatsnew/3.3.rst (right):

http://bugs.python.org/review/25523/diff/15867/Doc/whatsnew/3.3.rst#newcode2158
Doc/whatsnew/3.3.rst:2158: * repeating a single ASCII letter and getting
a substring of ASCII strings
On 2015/11/02 10:36:38, vadmium wrote:
> I think it would read even better in the singular:
> 
> repeating a single ASCII letter and getting a substring of an ASCII
string . . .

Done.

http://bugs.python.org/review/25523/diff/15867/Lib/test/test_codecs.py
File Lib/test/test_codecs.py (right):

http://bugs.python.org/review/25523/diff/15867/Lib/test/test_codecs.py#newcode1247
Lib/test/test_codecs.py:1247: # An Arabic (Egyptian):
On 2015/11/02 10:36:38, vadmium wrote:
> Looking at the other comments I think this is just meant to be the
letter A not
> the word ?a? :)

Done. :)

http://bugs.python.org/review/25523/diff/15867/Objects/longobject.c
File Objects/longobject.c (right):

http://bugs.python.org/review/25523/diff/15867/Objects/longobject.c#newcode4475
Objects/longobject.c:4475: /* no progress; do an Euclidean step */
On 2015/11/02 10:36:38, vadmium wrote:
> I would pronounce this ?a yooclidean?, not ?an ooclidean? or
something. This
> could be controversial, so maybe leave it as it was.

Done.

http://bugs.python.org/review/25523/

From report at bugs.python.org  Mon Nov  2 08:37:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Nov 2015 13:37:26 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446471446.2.0.68499035096.issue25523@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin for your review.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Mon Nov  2 09:33:18 2015
From: report at bugs.python.org (Mouse)
Date: Mon, 02 Nov 2015 14:33:18 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446474798.0.0.63556880211.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

1. I concede knowing nothing about the early Python library implementation, functionality, or even purpose.

2. I don't think it makes sense now to either refer to PEM. We'd be two decades too late for that (well, 27 years, to be precise :). See
 https://en.wikipedia.org/wiki/Privacy-enhanced_Electronic_Mail

3. I don't think we are in position to tell programmers how to split a string of characters into 76-long chunks. Not to mention that the example you gave is likely to suffer in performance (just count those function calls), compared to other methods, and won't reflect well on the authors.

Here's one possible doc version:

'''
Convert binary data to the base 64 encoding defined in :rfc:`4648`. The return value includes a trailing newline ``b"\n"`` if *newline* is true.

If the output is used as Base64 transfer encoding for MIME (:rfc: 2045), base 64 output should be broken into lines at most 76 characters long to be compliant. Base64 encoding standard does not limit the maximum encoded line length.
'''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Mon Nov  2 09:56:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Nov 2015 14:56:20 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446476180.51.0.409872776513.issue25495@psf.upfronthosting.co.za>


R. David Murray added the comment:

Add a parenthetical "(57 bytes of the input per line)" and I'll be happy with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Mon Nov  2 09:59:49 2015
From: report at bugs.python.org (Mouse)
Date: Mon, 02 Nov 2015 14:59:49 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446476389.83.0.0702750914761.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Let's not insinuate anything about the input. This is about what constraints on the OUTPUT MAY be there, not a tutorial from the 80-ties on how one might accomplish it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Mon Nov  2 10:00:46 2015
From: report at bugs.python.org (Mouse)
Date: Mon, 02 Nov 2015 15:00:46 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446476446.42.0.637486883291.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

And even those constraints depend on the use. E.g. X.509 does not have those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Mon Nov  2 10:15:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Nov 2015 15:15:52 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446477352.14.0.205484414314.issue25495@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please take a look at the Examples section of this:

   http://perldoc.perl.org/MIME/Base64.html

Looks kind of like Martin's suggestion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Mon Nov  2 12:23:24 2015
From: report at bugs.python.org (Mouse)
Date: Mon, 02 Nov 2015 17:23:24 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446485004.04.0.711599574284.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

1. I am OK with the following text, modeling referred Perldoc:

b2a_base64( $bytes, $eol );

Encode data by calling the encode_base64() function. The first argument is the byte string to encode. 

The second argument is optional, and provides the line-ending sequence to use. When it is given, the returned encoded string is broken into lines of no more than 76 characters each and it will end with $eol unless it is empty. Pass an empty string, or no second argument at all if you do not want the encoded string to be broken into lines.

2. I already had people telling me that "Python-3 doc prohibits input longer than 57 bytes, even though it doesn't currently enforce it". Please help putting end to spreading of this confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Mon Nov  2 20:04:28 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Nov 2015 01:04:28 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446512668.61.0.25002687185.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW that Perl function looks like it does the line splitting for you. It mentions ?chunks that are a multiple of 57 bytes?. The Python function does not do any line splitting. You have to use base64.encodebytes(), codecs.encode(encoding="base64") or perhaps something in the email package (or user code) for that.

I think we all agree that there is no hard limit of 57. I have avoided this function in the past due to the documentation. The question is whether the documentation should mention that number in a more accurate context, or not at all.

Personally I don?t see much harm in mentioning the 57-byte input chunking, as long as it is obvious it is not the only option. I don?t have a strong view; I am just trying to be conservative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Tue Nov  3 09:05:19 2015
From: report at bugs.python.org (Albert White)
Date: Tue, 03 Nov 2015 14:05:19 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1446559519.11.0.832236560995.issue9694@psf.upfronthosting.co.za>


Changes by Albert White <albert.white at gmail.com>:


----------
nosy: +Albert White

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Tue Nov  3 13:36:45 2015
From: report at bugs.python.org (Mouse)
Date: Tue, 03 Nov 2015 18:36:45 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446575805.36.0.641056567545.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

The harm in mentioning the 57-byte chunking is that so far it successfully confused people. 

b2a_base64() function is not coupled to MIME. It has no constraints on either its input, or its output. *IF* it is used by (in) a MIME application, then the caller may want to make its output RFC 2045-compliant, by whatever way he chooses. Giving (an unwelcome) advice to a writer of one specific application is in my opinion completely out of scope here. Justification that it used to matter 25 years ago and therefore should be kept here doesn't make sense to me.

I strongly insist that this "chunking" thing does not belong, and must be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Tue Nov  3 16:37:42 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 03 Nov 2015 21:37:42 +0000
Subject: [docs] [issue12300] Document pydoc.help
In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za>
Message-ID: <1446586662.09.0.740527034732.issue12300@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

What can we do for this issue ?

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12300>
_______________________________________

From report at bugs.python.org  Tue Nov  3 16:56:10 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Nov 2015 21:56:10 +0000
Subject: [docs] [issue12300] Document pydoc.help
In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za>
Message-ID: <1446587770.47.0.900570274325.issue12300@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Close it, which I think ?ric implicitly agreed to in paired issue #12299, where I said more in opposition to this one.  What I meant above is that help() is 'listed' in https://docs.python.org/3/library/pydoc.html#module-pydoc.
While it does not have usual format there, it is linked to a full entry here
https://docs.python.org/3/library/functions.html#help

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12300>
_______________________________________

From report at bugs.python.org  Tue Nov  3 16:58:36 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Nov 2015 21:58:36 +0000
Subject: [docs] [issue12300] Document pydoc.help
In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za>
Message-ID: <1446587916.24.0.10587060663.issue12300@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12300>
_______________________________________

From hector.torres at advics-na.com  Tue Nov  3 10:57:42 2015
From: hector.torres at advics-na.com (Torres, Hector)
Date: Tue, 3 Nov 2015 15:57:42 +0000
Subject: [docs] python 2.7
Message-ID: <7F9994412DEF184FAD221DF7DE1FCABC0E9B9EB6@LEBMAIL3.advics.local>

Something went wrong with python 2.7 and I cannot open it or uninstall to make it work.

I need to run Pyscripter to communicate with Pyvisa and control an Oscilloscope but since my python does not work I cannot do the script.

Would you please support how to have python 2.7 work or uninstall to fix the problem?


Hector Torres
Hardware Design Engineer |Control Systems Engineering
ADVICS North America, Inc.
45300 Polaris Court
Plymouth, MI 48170
e-mail: hector.torres at advics-na.com<mailto:hector.torres at advics-na.com>
Phone: 734-414-5543
Cell: 734-646-2454

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151103/1ac378a8/attachment.html>

From report at bugs.python.org  Thu Nov  5 06:02:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 05 Nov 2015 11:02:56 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446721376.13.0.522908936106.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps we can focus on the Python 2 version where there is always a newline appended. Here is a possible patch.

----------
Added file: http://bugs.python.org/file40953/issue25495.base64.2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From u.nassonov at asuproject.ru  Thu Nov  5 07:56:50 2015
From: u.nassonov at asuproject.ru (=?koi8-r?B?7sHT08/Oz9cg4NLJyiD3wczF0tjF18ne?=)
Date: Thu, 5 Nov 2015 12:56:50 +0000
Subject: [docs] windows chm file do not open properly
Message-ID: <9C3CDD584D5F1B45AD77714936AE19ACD56F30@EXCH2010NJC1.ois.ru>

[cid:image001.png at 01D117E1.10691E60]
OS | Windows 8.1 prof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151105/903e35c8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 43727 bytes
Desc: image001.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151105/903e35c8/attachment-0001.png>

From report at bugs.python.org  Thu Nov  5 11:50:59 2015
From: report at bugs.python.org (Mouse)
Date: Thu, 05 Nov 2015 16:50:59 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446742259.04.0.658363749346.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Unfortunately, NO. The problem (and this bug report) is for Python-3 documentation, so trying to address it in Python-2 rather than in Python-3 does not make sense.

We seem to both understand and agree that there is no length limitation on b2a_base64() input, either recommended or enforced - contrary to what the current Python-3 documentation implies.

We understand that *if* the *output* of this function is intended for use in MIME (rather than X.509 or whatever else Base64 is good for), then the caller should do other things besides calling b2a_base64(), and in all likelihood the caller is already aware of that - after all, if he figured that he needs Base64 in his stuff, he probably knows something about what MIME standards say and require?. 

I repeat my original complaint: Python-3 documentation is buggy because it implies a restriction on the input that is not there. This reference should be removed from there because it confuses people. 
I've talked to those confused personally, so this is first-hand.

I refer you to the original msg253572 of this bug report.

If you want to write a MIME-in-Python tutorial, it is up to you - but b2a_base64() does not seem to be the right place for it.  
(And I'd rather see an X.509 tutorial if you're dead set on writing something besides strict plain b2a_base64() doc. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Thu Nov  5 11:54:37 2015
From: report at bugs.python.org (Tom Meagher)
Date: Thu, 05 Nov 2015 16:54:37 +0000
Subject: [docs] [issue25559] signal.siginterrupt description has typo
Message-ID: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za>


New submission from Tom Meagher:

"if flag is False, system calls will be restarted when interrupted by signal signalnum, otherwise system calls will be interrupted."

This sentence doesn't make any sense as written.  I assume there should be a "not" in there somewhere, but I'm unclear if signal calls are not interrupted when the flag is false, or not interrupted when they are true.

----------
assignee: docs at python
components: Documentation
messages: 254121
nosy: Tom Meagher, docs at python
priority: normal
severity: normal
status: open
title: signal.siginterrupt description has typo
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25559>
_______________________________________

From report at bugs.python.org  Thu Nov  5 11:56:20 2015
From: report at bugs.python.org (Mouse)
Date: Thu, 05 Nov 2015 16:56:20 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446742580.67.0.804434045657.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

To add: I do not understand your attachment to that 57 "...(exactly 57 bytes of input data per line)", and request that this parenthesized sentence is removed from your Python-2.7 doc patch. 

Please give the reader the benefit of the doubt, and allow that *if* he wants to repeatedly call b2a_base64() instead of splitting its output - the ability to compute (76 * 3 / 4) is within his skill level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Thu Nov  5 12:49:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Nov 2015 17:49:27 +0000
Subject: [docs] [issue25559] signal.siginterrupt description has typo
In-Reply-To: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za>
Message-ID: <1446745767.36.0.391739697084.issue25559@psf.upfronthosting.co.za>


R. David Murray added the comment:

The first phase says "restarted when interrupted", the second phrase says "interrupted".  So the difference is whether the system call is restarted or left in interrupted state (ie: the signal will propagate, which is confirmed by the second paragraph).  I can't see a way to phrase it any more clearly, can you?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25559>
_______________________________________

From report at bugs.python.org  Thu Nov  5 15:30:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Nov 2015 20:30:22 +0000
Subject: [docs] [issue25559] signal.siginterrupt description has typo
In-Reply-To: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za>
Message-ID: <1446755422.46.0.216500289862.issue25559@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For more information on how Python handles signals, you can also read the PEP 475 (which changed how Python 3.5 handles signals ;-))

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25559>
_______________________________________

From report at bugs.python.org  Thu Nov  5 15:58:42 2015
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 05 Nov 2015 20:58:42 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446757122.3.0.374938903007.issue25495@psf.upfronthosting.co.za>


Georg Brandl added the comment:

issue25495.base64.2.7.patch looks good to me.  A similar patch can be adapted for 3.x.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Thu Nov  5 18:24:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 05 Nov 2015 23:24:20 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446765859.97.0.965101610387.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

Mouse, I know you originally opened this against 3.5. Apart from the module description at the bottom, my patch should be valid for 3.5 also. The relevant wording is identical to 2.7.

I have resisted removing the magic number 57 for a couple of reasons. Reading existing code that uses this number may be harder. David said he would be happier with it kept. I believed we could solve your original complaint and explain why the number was really there at the same time. It helps explain how the function was originally to be used, and why the newline is appended.

Anyway, I think it is best if I let this go, and someone else pick it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From m0ycm at veenstras.com  Thu Nov  5 16:58:51 2015
From: m0ycm at veenstras.com (Lester Veenstra)
Date: Thu, 5 Nov 2015 16:58:51 -0500
Subject: [docs] Python problems on Windows 1o
Message-ID: <02a601d11815$29818930$7c849b90$@com>

Could not IDLE to run under WINDOWS 10 install

 

ENV Path includes      ;d:\python27

 

When I try to invoke Tinker from inside python, I get

 

C:\Users\lbv>python

Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
on win32

Type "help", "copyright", "credits" or "license" for more information.

>>> import Tkinter

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "d:\python27\lib\lib-tk\Tkinter.py", line 38, in <module>

    import FixTk

  File "d:\python27\lib\lib-tk\FixTk.py", line 65, in <module>

    import _tkinter

ImportError: DLL load failed: %1 is not a valid Win32 application.

 

 

Lester B Veenstra  M?YCM K1YCM W8YCM

 <mailto:lester at veenstras.com> lester at veenstras.com

 

US Postal Address:

5 Shrine Club Drive

HC84 Box 89C

Keyser WV 26726

GPS: 39.336826 N  78.982287 W (Google)

GPS: 39.33682 N  78.9823741 W (GPSDO)

 

 

Telephones:

Home:                     +1-304-289-6057

US cell                    +1-304-790-9192 

UK cell                    +44-(0)7849-248-749 

Guam Cell:              +1-671-929-8141

Jamaica:                 +1-876-456-8898 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151105/25d5677c/attachment.html>

From report at bugs.python.org  Fri Nov  6 08:51:01 2015
From: report at bugs.python.org (Mouse)
Date: Fri, 06 Nov 2015 13:51:01 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446817861.07.0.713138097141.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

> my patch should be valid for 3.5 also.
> The relevant wording is identical to 2.7.

OK.

> I have resisted removing the magic number 57 for a couple
> of reasons. Reading existing code that uses this number may
> be harder.

You expect to see "existing code that uses this number" in Python-3.5+? Interesting... (Care to point me at a couple of samples of such "existing" Python-3 code?) And you expect that the main info source for understanding the reason behind that "57" (assuming this function is invoked that way, as opposed to splitting the output :) would be the doc for this function, rather than the main program, or RFC 2045, or...? Fine.

> It helps explain how the function was originally to be used,
> and why the newline is appended.

Pardon me, but why do you think anybody would care...? There are tons of functions, old and new, with more new ones popping up fast enough. I'd really envy a person who has time to enjoy history of one minuscule function of an old (albeit still useful :) library.

OK. You think a history of this function should be documented - fine. I don't need it (and don't think anybody else wants to read it either), but it's not my doc or my decision.

Just get the darn bug fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Fri Nov  6 16:34:26 2015
From: report at bugs.python.org (Alexandre Macabies)
Date: Fri, 06 Nov 2015 21:34:26 +0000
Subject: [docs] [issue25573] traceback documentation example is lying about
 FrameSummary repr()
Message-ID: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>


New submission from Alexandre Macabies:

https://docs.python.org/3.5/library/traceback.html#traceback-examples
See second code sample and its sample output. According to the docs, the call:

  print(repr(traceback.extract_tb(exc_traceback)))

is supposed to print something that looks like an array with only strings; that is what the doc sample output states:

  [('<doctest...>', 10, '<module>', 'lumberjack()'),

But actually, in 3.5+, this call outputs the repr() of a list of FrameSummary instances that do not go further in repr()esenting their state:

  [<FrameSummary file <ipython-input-61-3e63d7daea82>, line 10 in <module>>,

By looking at the docs I thought I was able to get a nice string representation of a FrameSummary. I actually have to format it myself. It should be reflected in the doc sample output.

----------
assignee: docs at python
components: Documentation
messages: 254224
nosy: Alexandre Macabies, docs at python
priority: normal
severity: normal
status: open
title: traceback documentation example is lying about FrameSummary repr()
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Fri Nov  6 16:43:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Nov 2015 21:43:54 +0000
Subject: [docs] [issue25573] FrameSummary repr() does not support previously
 working uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1446846234.16.0.352664731123.issue25573@psf.upfronthosting.co.za>


R. David Murray added the comment:

IMO, that is neither a lie nor a doc bug, it is a bug in the new traceback features that were added in 3.5.

----------
assignee: docs at python -> 
keywords: +3.5regression
nosy: +r.david.murray, rbcollins
stage:  -> needs patch
title: traceback documentation example is lying about FrameSummary repr() -> FrameSummary repr() does not support previously working uses of repr in traceback module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Fri Nov  6 16:45:41 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 06 Nov 2015 21:45:41 +0000
Subject: [docs] [issue25573] FrameSummary repr() does not support previously
 working uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1446846341.76.0.776011993007.issue25573@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Could you check with Python 3.4 ?

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Fri Nov  6 17:08:40 2015
From: report at bugs.python.org (leewz)
Date: Fri, 06 Nov 2015 22:08:40 +0000
Subject: [docs] [issue25428] Have `datetime` understand integer arguments
 for timezones
In-Reply-To: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>
Message-ID: <1446847719.84.0.445268839513.issue25428@psf.upfronthosting.co.za>


leewz added the comment:

Thanks. Will visit them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25428>
_______________________________________

From report at bugs.python.org  Fri Nov  6 17:10:52 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 06 Nov 2015 22:10:52 +0000
Subject: [docs] [issue25573] FrameSummary repr() does not support previously
 working uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1446847852.41.0.863580904222.issue25573@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Oops, sorry,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Fri Nov  6 17:35:05 2015
From: report at bugs.python.org (wim glenn)
Date: Fri, 06 Nov 2015 22:35:05 +0000
Subject: [docs] [issue25574] 2.7 incorrectly documents objects hash as equal
 to id
Message-ID: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za>


New submission from wim glenn:

The 2.7 glossary still incorrectly mentions instances of user-defined classes hash equal to their id.  
https://docs.python.org/2/glossary.html#term-hashable

Just a minor documentation bug that was unfortunately missed by http://bugs.python.org/issue21782

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 254237
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: 2.7 incorrectly documents objects hash as equal to id
versions: Python 2.7
Added file: http://bugs.python.org/file40966/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25574>
_______________________________________

From report at bugs.python.org  Fri Nov  6 20:00:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Nov 2015 01:00:09 +0000
Subject: [docs] [issue25064] Adjust tempfile documentation for bytes
 filename support
In-Reply-To: <1441943216.0.0.731717269075.issue25064@psf.upfronthosting.co.za>
Message-ID: <20151107010004.58393.49796@psf.io>


Roundup Robot added the comment:

New changeset de79e483565c by Martin Panter in branch '3.5':
Issue #25064: Adjust documentation according to new mkstemp signature
https://hg.python.org/cpython/rev/de79e483565c

New changeset c495c9dd7726 by Martin Panter in branch 'default':
Issue #25064: Merge tempfile doc from 3.5
https://hg.python.org/cpython/rev/c495c9dd7726

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25064>
_______________________________________

From report at bugs.python.org  Fri Nov  6 20:30:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Nov 2015 01:30:31 +0000
Subject: [docs] [issue25064] Adjust tempfile documentation for bytes
 filename support
In-Reply-To: <1441943216.0.0.731717269075.issue25064@psf.upfronthosting.co.za>
Message-ID: <1446859831.22.0.489310994392.issue25064@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25064>
_______________________________________

From report at bugs.python.org  Sat Nov  7 00:59:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Nov 2015 05:59:03 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1446875943.55.0.742204337461.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

David: are you saying you like the first patch better (ignoring the markup mistakes)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Sat Nov  7 02:01:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Nov 2015 07:01:45 +0000
Subject: [docs] [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1446879704.71.0.0257331116577.issue23360@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch 4 is just updated to avoid conflicts with the current code. Changes are the same.

----------
versions: +Python 3.6
Added file: http://bugs.python.org/file40968/non-urlencoded.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23360>
_______________________________________

From report at bugs.python.org  Sat Nov  7 02:32:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Nov 2015 07:32:31 +0000
Subject: [docs] [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1446881551.0.0.370915013932.issue23360@psf.upfronthosting.co.za>


Martin Panter added the comment:

Spotted a docstring that needed updating

----------
Added file: http://bugs.python.org/file40969/non-urlencoded.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23360>
_______________________________________

From report at bugs.python.org  Sat Nov  7 03:43:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Nov 2015 08:43:41 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
Message-ID: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>


New submission from Martin Panter:

I understand using a ?charset? parameter with ?Content-Type: application/x-www-form-urlencoded? is not standardized. Since Issue 11082, the documentation advises to use it, but I propose to remove this advice.

HTML 5 mentions setting a _charset_ parameter, and mentions decoding with a default of UTF-8 (not Latin-1!), but does not mention any Content-Type parameters.

There seems to be confusion about what encoding it actually represents. According to <https://bugzilla.mozilla.org/show_bug.cgi?id=7533>, Mozilla briefly set this ?charset? parameter a long time ago, but it would have corresponded to the urlencode(encoding=...) argument. The Python documentation currently suggests calling data.encode("utf-8"), which is misleading, because the urlencode() output is already guaranteed to be ASCII text. Any non-ASCII characters and bytes will already be character-encoded and percent-encoded by urlencode(). So I also propose to change the examples to data.encode("ascii").

----------
assignee: docs at python
components: Documentation
files: urlencoded-charset.patch
keywords: patch
messages: 254263
nosy: docs at python, martin.panter, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: Remove ?Content-Type: application/x-www-form-urlencoded; charset? advice
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40970/urlencoded-charset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Sat Nov  7 11:02:19 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 07 Nov 2015 16:02:19 +0000
Subject: [docs] [issue25580] async and await missing from token list
Message-ID: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>


New submission from SilentGhost:

With introduction of async and await tokens in 3.5 the token documentation needs updating.

----------
assignee: docs at python
components: Documentation
files: token.diff
keywords: patch
messages: 254281
nosy: SilentGhost, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: async and await missing from token list
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40974/token.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Sat Nov  7 11:06:22 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 07 Nov 2015 16:06:22 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1446912382.87.0.15872083051.issue25580@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

With python 3.5, async is a token with the ASYNC type.


>>> tokens = tokenize.generate_tokens(io.StringIO('async def foo').readline)
>>> pprint.pprint(list(tokens))
[TokenInfo(type=55 (ASYNC), string='async', start=(1, 0), end=(1, 5), line='async def foo'),
 TokenInfo(type=1 (NAME), string='def', start=(1, 6), end=(1, 9), line='async def foo'),
 TokenInfo(type=1 (NAME), string='foo', start=(1, 10), end=(1, 13), line='async def foo'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Sat Nov  7 16:37:08 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Sat, 07 Nov 2015 21:37:08 +0000
Subject: [docs] [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1446932228.8.0.493960237521.issue25179@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

Might be useful to add a note to PEP 257 that f-strings are not valid as docstrings .

Or should f-strings be valid docstrings and raise an error if any variables present in the f-string do not exist in the outer scope?

----------
nosy: +John.Mark.Vandenberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Sat Nov  7 16:58:21 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 07 Nov 2015 21:58:21 +0000
Subject: [docs] [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1446933501.13.0.157275932237.issue25179@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I think f-strings should be valid as docstrings. I don't know the exact details, but I think it would be harder to prevent rather than allow them. It would be exactly the same as doing func.__doc__ = func.__doc__.format(foo=foo, bar=bar)

It probably wouldn't be useful in most cases, but I don't see why we should restrict the use of f-strings to non-docstrings (not counting users trying to do that and stumbling across this error).

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Sat Nov  7 17:00:50 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 07 Nov 2015 22:00:50 +0000
Subject: [docs] [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1446933650.54.0.0954817497948.issue25179@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Since f-strings are not constant strings, they cannot be used as docstrings without some modifications to the compiler.

I'm not sure it's worth evaluating a docstring f-string at compile time to make them become docstrings: I can't think of a use case where this would be worthwhile. But maybe I'm not thinking hard enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Sat Nov  7 17:04:26 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 07 Nov 2015 22:04:26 +0000
Subject: [docs] [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1446933866.12.0.471415008286.issue25179@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I was under the impression that they would work without any additional work (as they'd have access to the outer scope). Of course, trying to access a local variable would be an error as it's not yet defined.

My point is more that we shouldn't have to account for such a small case - if they can be used, then let them be used, and if they can't, then don't (unless the modification is straightforward, which it might not be).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Sat Nov  7 17:12:03 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 07 Nov 2015 22:12:03 +0000
Subject: [docs] [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1446934323.06.0.868829417101.issue25179@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It does not currently work, because the docstring logic looks for a string, not an expression. And an f-string is an expression.

It would require changing the compiler to evaluate the f-string expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Sat Nov  7 17:13:04 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 07 Nov 2015 22:13:04 +0000
Subject: [docs] [issue25179] PEP 498 f-strings need to be documented
In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za>
Message-ID: <1446934384.07.0.41228406653.issue25179@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Well, then my bad. Pretend I didn't say anything :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25179>
_______________________________________

From report at bugs.python.org  Sat Nov  7 18:21:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Nov 2015 23:21:51 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1446938511.04.0.895468936246.issue25017@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, though I hadn't looked at it before this :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Sat Nov  7 20:16:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Nov 2015 01:16:55 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>
Message-ID: <1446945414.88.0.355866737647.issue25576@psf.upfronthosting.co.za>


R. David Murray added the comment:

Although I didn't read through the whole thing, the mozilla bug discussion indicates this is the correct way to specify the charset, it's just that there was lots of buggy software that didn't handle setting it to latin-1.  Is the same true for setting it to utf-8?

Agreed about the encode call.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Sun Nov  8 05:56:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Nov 2015 10:56:36 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>
Message-ID: <1446980196.52.0.665789638883.issue25576@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the server bugs referenced by the Mozilla bug are mainly about servers that do not recognize the content type at all, due the the presence of any charset parameter. They probably do something like ?if headers['Content-Type'] == 'application/x-www-form-urlencoded' ? without checking for parameters first. So it wouldn?t matter if it was charset=latin-1 or charset=utf-8.

A couple comments in the Mozilla bug say that including ?charset? is specified by a HTTP standard, but I suspect this may be a mistake. Perhaps this is the best evidence for my argument, from <http://www.w3.org/TR/html/forms.html#url-encoded-form-data>:

'''
Parameters on the ?application/x-www-form-urlencoded? MIME type are ignored. In particular, this MIME type does not support the ?charset? parameter.
'''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Sun Nov  8 06:29:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Nov 2015 11:29:29 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1446982169.65.0.824500854959.issue25580@psf.upfronthosting.co.za>


Martin Panter added the comment:

I wonder if the new tokens need a ?versionadded? notice. They were added in revision eeeb666a5365 for 3.5.

----------
nosy: +martin.panter, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From rdmurray at bitdance.com  Sun Nov  8 12:24:56 2015
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Sun, 08 Nov 2015 17:24:56 -0000
Subject: [docs] =?utf-8?q?Remove_=E2=80=9CContent-Type=3A_application/x-ww?=
 =?utf-8?q?w-form-urlencoded=3B_charset=E2=80=9D_advice_=28issue_25576=29?=
Message-ID: <20151108172456.9304.65207@psf.upfronthosting.co.za>


http://bugs.python.org/review/25576/diff/15901/Doc/library/urllib.request.rst
File Doc/library/urllib.request.rst (right):

http://bugs.python.org/review/25576/diff/15901/Doc/library/urllib.request.rst#newcode1245
Doc/library/urllib.request.rst:1245: >>> with
urllib.request.urlopen("http://requestb.in/xrbl82xr", data) as f:
We lose something from the example no longer showing a use of
add_header.  Is there any other header we could add that would make
sense in context?  I don't think it is a big deal, though.

http://bugs.python.org/review/25576/

From report at bugs.python.org  Sun Nov  8 12:25:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Nov 2015 17:25:27 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>
Message-ID: <1447003527.8.0.973248061327.issue25576@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, I'll accept that as authoritative :)

One very minor comment in the review, otherwise looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Sun Nov  8 16:47:35 2015
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Nov 2015 21:47:35 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
Message-ID: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>


New submission from Jakub Stasiak:

It is my understanding that socket.sendall effectively calls the underlying socket.send's implementation in a retry loop, possibly multiple times.

It is also my understanding that each one of those low level send calls can timeout on its own if a socket timeout is set.

Considering the above I believe it's undesired to ever call socket.sendall with a socket that has a timeout set because if:

1. At least one send call succeeds
2. A send call after that times out

then a socket timeout error will be raised and the information about the sent data will be lost.

Granted, the documentation says that "On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent". I believe, however, that such API is very easy to misuse (I've seen it used with sockets with timeout set, because of small payload sizes and other circumstances it would appear to work fine most of the time and only fail every N hours or days).

Possible improvements I see:

1. Explicitly mention interaction between socket's timeout and sendall's behavior in the documentation
2. Make sendall raise an error when the socket it's called with has a timeout set (I can see the backwards compatibility being a concern here but I can't think of any reason to remain compatible with behavior I believe to be broken anyway)
3. Both of the above

I'm happy to procure an appropriate patch for any of the above. Please correct me if my understanding of this is off.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 254357
nosy: docs at python, jstasiak
priority: normal
severity: normal
status: open
title: socket.sendall broken when a socket has a timeout
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Sun Nov  8 17:06:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Nov 2015 22:06:37 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447020397.01.0.0690924646307.issue25586@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI the behaviour of socket.socket.sendall() regarding timeout has been modified in Python 3.5:
https://docs.python.org/dev/library/socket.html#socket.socket.sendall

"Changed in version 3.5: The socket timeout is no more reset each time data is sent successfuly. The socket timeout is now the maximum total duration to send all data."

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Sun Nov  8 17:33:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Nov 2015 22:33:20 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447022000.48.0.159838780829.issue25586@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t like the sound of improvement 2. I think it would break existing use cases, e.g. HTTPConnection(timeout=...), urlopen(timeout=...). If you want a HTTP request to abort if it takes a long time, how is that behaviour broken?

Regarding improvement 1, I think Victor?s 3.5 documentation explains how the timeout works fairly well. Perhaps you meant for this bug to be about pre-3.5 versions?

Also, see Issue 7322 for discussion of how to handle exceptions when reading from sockets and other streams. E.g. what should readline() do when it has read half a line and then gets an exception, and should you be allowed to read again after handling an exception? In my mind the readline() and sendall() cases are somewhat complementary.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From vadmium+py at gmail.com  Sun Nov  8 18:08:29 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 08 Nov 2015 23:08:29 -0000
Subject: [docs]
 =?utf-8?q?Remove_=E2=80=9CContent-Type=3A_application/x-ww?=
 =?utf-8?q?w-form-urlencoded=3B_charset=E2=80=9D_advice_=28issue_25576=29?=
Message-ID: <20151108230829.17071.31002@psf.upfronthosting.co.za>

Reviewers: r.david.murray,


http://bugs.python.org/review/25576/diff/15901/Doc/library/urllib.request.rst
File Doc/library/urllib.request.rst (right):

http://bugs.python.org/review/25576/diff/15901/Doc/library/urllib.request.rst#newcode1245
Doc/library/urllib.request.rst:1245: >>> with
urllib.request.urlopen("http://requestb.in/xrbl82xr", data) as f:
On 2015/11/08 18:24:56, r.david.murray wrote:
> We lose something from the example no longer showing a use of
add_header.  Is
> there any other header we could add that would make sense in context? 
I don't
> think it is a big deal, though.

Nothing immediately comes to mind for this particular example. It might
be better to illustrate one concept per example, rather than adding in
unrelated headers at the same time. There is already an example at line
1209 setting Referer with add_header(). Some more options:

* Perhaps there should be a link to
<https://docs.python.org/dev/howto/urllib2.html#headers>, which has
example code for setting User-Agent via the Request constructor
parameter.

* In my patch at Issue 23360 I proposed setting the Content-Type in the
examples where data is not in urlencoded format, although again using
the constructor rather than add_header().

* Perhaps we can resolve Issue 25570 with an example setting User-Agent
via add_header().



Please review this at http://bugs.python.org/review/25576/

Affected files:
  Doc/library/urllib.parse.rst
  Doc/library/urllib.request.rst
  Lib/urllib/request.py


# HG changeset patch
# Parent  4df1eaecb506507e5d613f8601b48057e7f328a8
Remove advice about setting charset with application/x-www-form-urlencoded

No charset parameter is standardized for this Content-Type value. Also
clarify that urlencode() outputs ASCII.

diff -r 4df1eaecb506 -r 6ff71efb3b5b Doc/library/urllib.parse.rst
--- a/Doc/library/urllib.parse.rst	Sat Nov 07 03:15:32 2015 +0000
+++ b/Doc/library/urllib.parse.rst	Sat Nov 07 08:36:34 2015 +0000
@@ -535,10 +535,11 @@
                         errors=None, quote_via=quote_plus)
 
    Convert a mapping object or a sequence of two-element tuples, which may
-   contain :class:`str` or :class:`bytes` objects, to a "percent-encoded"
-   string.  If the resultant string is to be used as a *data* for POST
-   operation with :func:`~urllib.request.urlopen` function, then it should be
-   properly encoded to bytes, otherwise it would result in a :exc:`TypeError`.
+   contain :class:`str` or :class:`bytes` objects, to a percent-encoded ASCII
+   text string.  If the resultant string is to be used as a *data* for POST
+   operation with the :func:`~urllib.request.urlopen` function, then
+   it should be encoded to bytes, otherwise it would result in a
+   :exc:`TypeError`.
 
    The resulting string is a series of ``key=value`` pairs separated by ``'&'``
    characters, where both *key* and *value* are quoted using the *quote_via*
diff -r 4df1eaecb506 -r 6ff71efb3b5b Doc/library/urllib.request.rst
--- a/Doc/library/urllib.request.rst	Sat Nov 07 03:15:32 2015 +0000
+++ b/Doc/library/urllib.request.rst	Sat Nov 07 08:36:34 2015 +0000
@@ -36,13 +36,8 @@
    *data* should be a buffer in the standard
    :mimetype:`application/x-www-form-urlencoded` format.  The
    :func:`urllib.parse.urlencode` function takes a mapping or sequence of
-   2-tuples and returns a string in this format. It should be encoded to bytes
-   before being used as the *data* parameter. The charset parameter in
-   ``Content-Type`` header may be used to specify the encoding. If charset
-   parameter is not sent with the Content-Type header, the server following the
-   HTTP 1.1 recommendation may assume that the data is encoded in ISO-8859-1
-   encoding. It is advisable to use charset parameter with encoding used in
-   ``Content-Type`` header with the :class:`Request`.
+   2-tuples and returns an ASCII text string in this format. It should
+   be encoded to bytes before being used as the *data* parameter.
 
    urllib.request module uses HTTP/1.1 and includes ``Connection:close`` header
    in its HTTP requests.
@@ -180,16 +175,9 @@
    the only ones that use *data*; the HTTP request will be a POST instead of a
    GET when the *data* parameter is provided.  *data* should be a buffer in the
    standard :mimetype:`application/x-www-form-urlencoded` format.
-
    The :func:`urllib.parse.urlencode` function takes a mapping or sequence of
-   2-tuples and returns a string in this format. It should be encoded to bytes
-   before being used as the *data* parameter. The charset parameter in
-   ``Content-Type`` header may be used to specify the encoding. If charset
-   parameter is not sent with the Content-Type header, the server following the
-   HTTP 1.1 recommendation may assume that the data is encoded in ISO-8859-1
-   encoding. It is advisable to use charset parameter with encoding used in
-   ``Content-Type`` header with the :class:`Request`.
-
+   2-tuples and returns an ASCII string in this format. It should be
+   encoded to bytes before being used as the *data* parameter.
 
    *headers* should be a dictionary, and will be treated as if
    :meth:`add_header` was called with each key and value as arguments.
@@ -202,7 +190,7 @@
    ``"Python-urllib/2.6"`` (on Python 2.6).
 
    An example of using ``Content-Type`` header with *data* argument would be
-   sending a dictionary like ``{"Content-Type":" application/x-www-form-urlencoded;charset=utf-8"}``.
+   sending a dictionary like ``{"Content-Type": "application/x-www-form-urlencoded"}``.
 
    The final two arguments are only of interest for correct handling
    of third-party HTTP cookies:
@@ -1230,7 +1218,7 @@
    opener.open('http://www.example.com/')
 
 Also, remember that a few standard headers (:mailheader:`Content-Length`,
-:mailheader:`Content-Type` without charset parameter and :mailheader:`Host`)
+:mailheader:`Content-Type` and :mailheader:`Host`)
 are added when the :class:`Request` is passed to :func:`urlopen` (or
 :meth:`OpenerDirector.open`).
 
@@ -1253,11 +1241,8 @@
    >>> import urllib.request
    >>> import urllib.parse
    >>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
-   >>> data = data.encode('utf-8')
-   >>> request = urllib.request.Request("http://requestb.in/xrbl82xr")
-   >>> # adding charset parameter to the Content-Type header.
-   >>> request.add_header("Content-Type","application/x-www-form-urlencoded;charset=utf-8")
-   >>> with urllib.request.urlopen(request, data) as f:
+   >>> data = data.encode('ascii')
+   >>> with urllib.request.urlopen("http://requestb.in/xrbl82xr", data) as f:
    ...     print(f.read().decode('utf-8'))
    ...
 
diff -r 4df1eaecb506 -r 6ff71efb3b5b Lib/urllib/request.py
--- a/Lib/urllib/request.py	Sat Nov 07 03:15:32 2015 +0000
+++ b/Lib/urllib/request.py	Sat Nov 07 08:36:34 2015 +0000
@@ -149,13 +149,8 @@
 
     *data* should be a buffer in the standard application/x-www-form-urlencoded
     format. The urllib.parse.urlencode() function takes a mapping or sequence
-    of 2-tuples and returns a string in this format. It should be encoded to
-    bytes before being used as the data parameter. The charset parameter in
-    Content-Type header may be used to specify the encoding. If charset
-    parameter is not sent with the Content-Type header, the server following
-    the HTTP 1.1 recommendation may assume that the data is encoded in
-    ISO-8859-1 encoding. It is advisable to use charset parameter with encoding
-    used in Content-Type header with the Request.
+    of 2-tuples and returns an ASCII text string in this format. It should be
+    encoded to bytes before being used as the data parameter.
 
     urllib.request module uses HTTP/1.1 and includes a "Connection:close"
     header in its HTTP requests.



From report at bugs.python.org  Sun Nov  8 18:25:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Nov 2015 23:25:05 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>
Message-ID: <1447025105.83.0.404865998371.issue25576@psf.upfronthosting.co.za>


Martin Panter added the comment:

The second version of the patch changes some more examples in the how-to to data.encode("ascii"). I?ll leave this open for a bit in case Senthil is around and wants to comment (seeing as he added the text I am removing).

----------
Added file: http://bugs.python.org/file40983/urlencoded-charset.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Sun Nov  8 20:04:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Nov 2015 01:04:16 +0000
Subject: [docs] [issue25570] urllib.request > Request.add_header("abcd",
 "efgh") fails with character ":" in first parameter string
In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za>
Message-ID: <1447031056.27.0.145124424012.issue25570@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hmm, I wonder if that OpenerDirector example is a bit obscure. Normally you would use the default urlopen() to set User-Agent, without resorting to a custom OpenerDirector.

In my patch:

* Included ?User-Agent header _value_? in the ?headers? parameter description
* Linked to <https://docs.python.org/dev/howto/urllib2.html> from examples section
* Added add_header("User-Agent", ...) example with made-up custom value

Let me know what you think (if anything is unnecessary, other suggestions?)

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +patch
nosy: +docs at python
stage: needs patch -> patch review
type: behavior -> enhancement
versions: +Python 2.7, Python 3.4, Python 3.6
Added file: http://bugs.python.org/file40984/add_header.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25570>
_______________________________________

From report at bugs.python.org  Sun Nov  8 20:19:16 2015
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 09 Nov 2015 01:19:16 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447031955.98.0.42419160088.issue25586@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

Martin: While I'd consider timeout in HTTPConnection(timeout=...) or urlopen(timeout=...) to be the timeout for the entire operation, just just for the data sending part and HTTPConnection/urlopen can achieve the timeout behavior using just send I concede there may be valid use cases for "either sendall succeeds or we don't care about what we've sent anyway" and in this light my second suggestion is problematic.

Victor: The behavior change in 3.5 does't affect my concern from what I see.  The concern is sendall timing out after some data has already been sent which can create some subtle issues. I've seen code like this:

def x(data, sock):
    while True:
        # some code here    
        try:
            sock.sendall(data)
            return
        except timeout:
            pass


Now I'll agree the code is at fault for ever attempting to retry sendall but I also think the API is easy to misuse like this. And it many cases it'll just work most of the time because sendall won't timeout.

Maybe explicitly mentioning sendall's behavior concerning sockets with timeouts could improve this? I'm honestly not sure anymore, technically "On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent." should be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Sun Nov  8 20:45:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Nov 2015 01:45:26 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447033525.97.0.817889389157.issue25586@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe it would be reasonable to expand on that ?On error? sentence. I imagine the main errors that would cause this situation are a timeout as you say, and also a blocking exception. Also, you could point out that if you have lost record of how much has already been sent, it may not make sense to send any more data with the same socket.

----------
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Mon Nov  9 04:02:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Nov 2015 09:02:43 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
 module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1447059763.17.0.685210108314.issue21818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Georg, is it possible to tune Sphinx rules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21818>
_______________________________________

From report at bugs.python.org  Mon Nov  9 04:17:11 2015
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 09 Nov 2015 09:17:11 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447060631.88.0.0468313256052.issue25586@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

This is exactly what I'm thinking. Do you think it's sensible to move that sentence + some additional information (following your suggestion) into a "Warning" block?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Mon Nov  9 12:59:50 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 09 Nov 2015 17:59:50 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
 module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1447091990.45.0.211834322685.issue21818@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The rules are as they are mostly for backwards compatibility. But it is rarely a problem since there is only one object with a given name.

:class:`Cookie` within the docs for cookielib would not be able to link to Cookie.Cookie since it is not found in its scope. :class:`Cookie.Cookie` works, as does :class:`~Cookie.Cookie`.

When you use the "find-in-any-namespace" syntax, i.e. :class:`.Cookie` the type *will* be taken into account.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21818>
_______________________________________

From report at bugs.python.org  Mon Nov  9 16:16:44 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Nov 2015 21:16:44 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447103804.48.0.952308286102.issue25586@psf.upfronthosting.co.za>


Martin Panter added the comment:

Personally I would avoid big red warning boxes in 90% of the cases people suggest them, including this one. But maybe we can see what others think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Mon Nov  9 16:24:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Nov 2015 21:24:08 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447104248.35.0.6420081494.issue25586@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't really understand why do even you consider the behaviour has a bug or a trap. On timeout, the most common behaviour is to give up on the whole client. I don't know code trying to resend the same data in case of timeout.

Describing the behaviour on the documentation helps, but no warning is need.

When you *read* data, it's different. It can be interesting to get the partial read.

--

For example, the asyncio.StreamReader.readexactly() coroutine raises an asyncio.IncompleteReadError exception which contains the partial data:

https://docs.python.org/dev/library/asyncio-stream.html#asyncio.StreamReader.readexactly

The HTTP client has a similar exception.

I proposed to add similar method to socket.socket which also raises a similar exception to return partial data: issue #1103213.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Tue Nov 10 01:06:12 2015
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 10 Nov 2015 06:06:12 +0000
Subject: [docs] [issue25592] distutils docs: data_files always uses
 sys.prefix
Message-ID: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

The documentation for distutils claims that sys.exec_prefix is used in certain cases to install data_files, but this is simply not true (maybe it was true in the past or this sentence was copy/pasted from somewhere else?)

----------
assignee: docs at python
components: Documentation
files: data_files_doc.patch
keywords: patch
messages: 254432
nosy: docs at python, jdemeyer
priority: normal
severity: normal
status: open
title: distutils docs: data_files always uses sys.prefix
versions: Python 2.7
Added file: http://bugs.python.org/file40993/data_files_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Tue Nov 10 03:27:47 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 10 Nov 2015 08:27:47 +0000
Subject: [docs] [issue25594] enum docs outdated re attribute access
Message-ID: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>


New submission from SilentGhost:

In enum docs[0], there is a suggestion that the attribute access on members should raise an AttributeError:

>>> Color.red.blue
Traceback (most recent call last):
...
AttributeError: 'Color' object has no attribute 'blue'

which is demonstrably wrong in either 3.5 or 3.6. I presume that's a doc issue and I'd be glad to propose the patch as soon as someone more familiar with the module could confirm that.

[0] https://docs.python.org/3.6/library/enum.html#finer-points

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 254436
nosy: SilentGhost, barry, docs at python, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: enum docs outdated re attribute access
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From animalize81 at hotmail.com  Sun Nov  8 08:28:08 2015
From: animalize81 at hotmail.com (animalize)
Date: Sun, 8 Nov 2015 21:28:08 +0800
Subject: [docs] small typo in re module article
Message-ID: <BLU437-SMTP93946A44AC2805E39C3A00B6160@phx.gbl>

In this article:   https://docs.python.org/3/library/re.html

Search "neither" inside browser, it should followed by "nor".

Need not to reply me:)

From igor.zhun at gmail.com  Mon Nov  9 15:32:50 2015
From: igor.zhun at gmail.com (Igor Zhun)
Date: Mon, 9 Nov 2015 22:32:50 +0200
Subject: [docs] misspelling on website
Message-ID: <CAEgyZ8rz2pzqtmbXGsT41+QfuMQQt_nUCS7y0So89kyPBj0EYA@mail.gmail.com>

Hello everybody

On page "What?s New In Python 3.6" (
https://docs.python.org/3.6/whatsnew/3.6.html)

There is text:
datetime.*stftime* and date.*stftime*

Maybe it should be:
datetime.st*r*ftime and date.st*r*ftime (r are missing twice)

Is it OK?

Best regards,
Igor Zhun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151109/bc18011e/attachment-0001.html>

From keith.briggs at bt.com  Mon Nov  9 07:16:01 2015
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Mon, 9 Nov 2015 12:16:01 +0000
Subject: [docs] https://docs.python.org/3.5/whatsnew/3.5.html
Message-ID: <1447071407399.69053@bt.com>

> Objects from random<https://docs.python.org/3.5/library/random.html#module-random> module now use two times less memory on 64-bit builds


How can you use "two times less memory"?  Wouldn't that make the usage negative?   Perhaps "half as much memory" was meant?


Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151109/12ec5db5/attachment.html>

From report at bugs.python.org  Tue Nov 10 04:25:53 2015
From: report at bugs.python.org (Jakub Stasiak)
Date: Tue, 10 Nov 2015 09:25:53 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447147553.19.0.401689806697.issue25586@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

That's fair and thanks for the links.

Please find a quick patch attached, feel free to use that or any modification of it. While I believe the documentation is technically correct right now it won't hurt to clarify this I think.

----------
keywords: +patch
Added file: http://bugs.python.org/file40994/socket-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Tue Nov 10 10:47:03 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Nov 2015 15:47:03 +0000
Subject: [docs] [issue25594] enum docs outdated re attribute access
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447170423.15.0.575816145473.issue25594@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Nope, that would be a bug.

----------
assignee: docs at python -> ethan.furman
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Tue Nov 10 12:53:25 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 10 Nov 2015 17:53:25 +0000
Subject: [docs] [issue25594] enum docs outdated re attribute access
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447178005.54.0.653573234116.issue25594@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the test, it seems to have been 2545bfe0d273 that caused it (issue23486): test passes prior to it and fails on it (and I assume uniformly after).

----------
keywords: +patch
Added file: http://bugs.python.org/file41003/test_issue25594.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Tue Nov 10 15:09:27 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 10 Nov 2015 20:09:27 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447186167.28.0.0947145616023.issue25594@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components:  -Documentation
stage: test needed -> needs patch
title: enum docs outdated re attribute access -> enum instance attribute access possible

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Tue Nov 10 21:26:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Nov 2015 02:26:43 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447208803.72.0.850820893841.issue25586@psf.upfronthosting.co.za>


Martin Panter added the comment:

That was kind of what I had in mind. The only change I would make is to restore the comma to ?On error (including socket timeout), an exception . . .?. I?ll try to commit this in a few days if nobody has anything else to say.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From docneogi at gmail.com  Wed Nov 11 01:39:36 2015
From: docneogi at gmail.com (docneogi)
Date: Wed, 11 Nov 2015 12:09:36 +0530
Subject: [docs] ePub Book Corrupt
Message-ID: <F230D5FA-216A-4A54-9EFB-926833823F59@gmail.com>

Hi,

this is to bring to your notice that the EPUB book available on https://docs.python.org/3/download.html <https://docs.python.org/3/download.html> for download is corrupt. I use OSX El Capitan. 

Kindly see to the problem. and if possible when the problem is rectified if I could be kindly notified so that i may download the EPUB book for my personal reference.

Warm Regards,
Dr. S Neogi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151111/49d32473/attachment.html>

From report at bugs.python.org  Wed Nov 11 21:52:55 2015
From: report at bugs.python.org (Matthias welp)
Date: Thu, 12 Nov 2015 02:52:55 +0000
Subject: [docs] [issue25603] spelling mistake - 26.1 typing
Message-ID: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za>


New submission from Matthias welp:

Almost at the end of the page, under Usage of Typing.NamedTuple(...), this code snippet occurs: `Employee = typing.NamedTuple('Employee', [('name', str), 'id', int)])`. Unfortunately, this has an error in its parenthesis. 

This can easily be fixed by adding an opening bracket before the `'id'`-part, as seen here: `Employee = typing.NamedTuple('Employee', [('name', str), ('id', int)])`.

----------
assignee: docs at python
components: Documentation
messages: 254511
nosy: Matthias welp, docs at python
priority: normal
severity: normal
status: open
title: spelling mistake - 26.1 typing
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25603>
_______________________________________

From zachary.ware+pydocs at gmail.com  Wed Nov 11 23:42:18 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 11 Nov 2015 22:42:18 -0600
Subject: [docs] misspelling on website
In-Reply-To: <CAEgyZ8rz2pzqtmbXGsT41+QfuMQQt_nUCS7y0So89kyPBj0EYA@mail.gmail.com>
References: <CAEgyZ8rz2pzqtmbXGsT41+QfuMQQt_nUCS7y0So89kyPBj0EYA@mail.gmail.com>
Message-ID: <CAKJDb-OHOiafdEy5kC+shm6eotePhagQXZHFXAEn16qHOyH8Pg@mail.gmail.com>

On Mon, Nov 9, 2015 at 2:32 PM, Igor Zhun <igor.zhun at gmail.com> wrote:
> Hello everybody
>
> On page "What?s New In Python 3.6"
> (https://docs.python.org/3.6/whatsnew/3.6.html)
>
> There is text:
> datetime.stftime and date.stftime
>
> Maybe it should be:
> datetime.strftime and date.strftime (r are missing twice)
>
> Is it OK?

Thanks for the report!  This has now been fixed.

-- 
Zach

From zachary.ware+pydocs at gmail.com  Wed Nov 11 23:54:31 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 11 Nov 2015 22:54:31 -0600
Subject: [docs] https://docs.python.org/3.5/whatsnew/3.5.html
In-Reply-To: <1447071407399.69053@bt.com>
References: <1447071407399.69053@bt.com>
Message-ID: <CAKJDb-N7op7dxu_p0rXbyeMuFjvNfWkV7D+DrX+H9hcUkMa5ww@mail.gmail.com>

On Mon, Nov 9, 2015 at 6:16 AM,  <keith.briggs at bt.com> wrote:
>> Objects from random module now use two times less memory on 64-bit builds
>
>
> How can you use "two times less memory"?  Wouldn't that make the usage
> negative?   Perhaps "half as much memory" was meant?

Thanks for the report!  This has now been fixed.

-- 
Zach

From report at bugs.python.org  Thu Nov 12 00:00:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Nov 2015 05:00:18 +0000
Subject: [docs] [issue25603] spelling mistake - 26.1 typing
In-Reply-To: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za>
Message-ID: <20151112050013.92474.97772@psf.io>


Roundup Robot added the comment:

New changeset 81cc0cea2323 by Zachary Ware in branch '3.5':
Issue #25603: Add missing parenthesis.
https://hg.python.org/cpython/rev/81cc0cea2323

New changeset 1af59662f6d5 by Zachary Ware in branch 'default':
Closes #25603: Merge with 3.5
https://hg.python.org/cpython/rev/1af59662f6d5

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25603>
_______________________________________

From report at bugs.python.org  Thu Nov 12 00:00:52 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 12 Nov 2015 05:00:52 +0000
Subject: [docs] [issue25603] spelling mistake - 26.1 typing
In-Reply-To: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za>
Message-ID: <1447304452.83.0.0213149600813.issue25603@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report!

----------
nosy: +zach.ware
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25603>
_______________________________________

From zachary.ware+pydocs at gmail.com  Thu Nov 12 00:08:51 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 11 Nov 2015 23:08:51 -0600
Subject: [docs] ePub Book Corrupt
In-Reply-To: <F230D5FA-216A-4A54-9EFB-926833823F59@gmail.com>
References: <F230D5FA-216A-4A54-9EFB-926833823F59@gmail.com>
Message-ID: <CAKJDb-MpatiG=49z=xLG2hiRtQSDDftUDinvt0cuMA=yZ-T=hw@mail.gmail.com>

On Wed, Nov 11, 2015 at 12:39 AM, docneogi <docneogi at gmail.com> wrote:
> Hi,
>
> this is to bring to your notice that the EPUB book available on
> https://docs.python.org/3/download.html for download is corrupt. I use OSX
> El Capitan.
>
> Kindly see to the problem. and if possible when the problem is rectified if
> I could be kindly notified so that i may download the EPUB book for my
> personal reference.

iBooks on El Capitan does indeed complain about the EPUB being corrupt
("This book can't be opened./The book is corrupt"), seemingly at
random.  It does work for a while, then decides it's corrupt and
closes it.  Reopening it, it works for a while again.  I'm not sure
whose bug this is; iBooks, Sphinx, or otherwise.  iBooks doesn't give
enough information to even think about tracking it down.

-- 
Zach

From zachary.ware+pydocs at gmail.com  Thu Nov 12 00:35:03 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 11 Nov 2015 23:35:03 -0600
Subject: [docs] small typo in re module article
In-Reply-To: <BLU437-SMTP93946A44AC2805E39C3A00B6160@phx.gbl>
References: <BLU437-SMTP93946A44AC2805E39C3A00B6160@phx.gbl>
Message-ID: <CAKJDb-NeHxWCMcTBbiZJkPa7CEqffPdM3H0V0n5tOE0FpBdKkA@mail.gmail.com>

On Sun, Nov 8, 2015 at 7:28 AM, animalize <animalize81 at hotmail.com> wrote:
> In this article:   https://docs.python.org/3/library/re.html
>
> Search "neither" inside browser, it should followed by "nor".

Fixed by completely rewriting the section to avoid neither/(n)or.

Thanks for the report!

-- 
Zach

From matthieudelaro at gmail.com  Thu Nov 12 00:58:29 2015
From: matthieudelaro at gmail.com (=?UTF-8?Q?Matthieu_de_La_Roche_Saint=2DAndr=C3=A9?=)
Date: Thu, 12 Nov 2015 14:58:29 +0900
Subject: [docs] Typo error in Python 3.5 documentation
Message-ID: <CAPdbYzvLxs2BS+W6ubutgZm_qPp-sJa2yAiOVgefp9Srsn-tWg@mail.gmail.com>

Hello,

Quick email to notice about a typo error on the following documentation
page : https://docs.python.org/3.5/tutorial/classes.html#method-objects

On the last line of the example, a dot is missing between x and f :

9.3.4. Method Objects
<https://docs.python.org/3.5/tutorial/classes.html#method-objects>

Usually, a method is called right after it is bound:

x.f()

In the MyClass example, this will return the string 'hello world'. However,
it is not necessary to call a method right away: x.f is a method object,
and can be stored away and called at a later time. For example:

xf = x.fwhile True:
    print(xf())


Thanks for the efforts on the documentations,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/1e0e18b9/attachment-0001.html>

From zachary.ware+pydocs at gmail.com  Thu Nov 12 01:22:54 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 12 Nov 2015 00:22:54 -0600
Subject: [docs] Typo error in Python 3.5 documentation
In-Reply-To: <CAPdbYzvLxs2BS+W6ubutgZm_qPp-sJa2yAiOVgefp9Srsn-tWg@mail.gmail.com>
References: <CAPdbYzvLxs2BS+W6ubutgZm_qPp-sJa2yAiOVgefp9Srsn-tWg@mail.gmail.com>
Message-ID: <CAKJDb-Oz0462TaCn5O-m0kVi-s4XCSey1j_mtjS_tFpMDuxPAA@mail.gmail.com>

Hi Matthieu,

On Wed, Nov 11, 2015 at 11:58 PM, Matthieu de La Roche Saint-Andr?
<matthieudelaro at gmail.com> wrote:
> Hello,
>
> Quick email to notice about a typo error on the following documentation page
> : https://docs.python.org/3.5/tutorial/classes.html#method-objects
>
> On the last line of the example, a dot is missing between x and f

Actually, it's not; that's the point of the example :).  Note that the
first line of the last example is "xf = x.f", which assigns the method
object to the name "xf", which is then used (called) in the last line.
Try it out using the MyClass class from further up the page.

The page could perhaps use an update to make that more obvious (and
the example less obnoxious to run), such as:

   method = x.f
   for each in range(5):
       print(method())

...but what's there now is not wrong.

Thanks for the report, though!

Regards,
-- 
Zach

From matthieudelaro at gmail.com  Thu Nov 12 01:25:41 2015
From: matthieudelaro at gmail.com (=?UTF-8?Q?Matthieu_de_La_Roche_Saint=2DAndr=C3=A9?=)
Date: Thu, 12 Nov 2015 15:25:41 +0900
Subject: [docs] Typo error in Python 3.5 documentation
In-Reply-To: <CAKJDb-Oz0462TaCn5O-m0kVi-s4XCSey1j_mtjS_tFpMDuxPAA@mail.gmail.com>
References: <CAPdbYzvLxs2BS+W6ubutgZm_qPp-sJa2yAiOVgefp9Srsn-tWg@mail.gmail.com>
 <CAKJDb-Oz0462TaCn5O-m0kVi-s4XCSey1j_mtjS_tFpMDuxPAA@mail.gmail.com>
Message-ID: <CAPdbYzu1kU1yLWfaVrwJDH2RDGDL+0tdZS7EV+Au_vEgxb0Hjw@mail.gmail.com>

Oh right, sorry for useless notification.
Thanks a lot for answering though, I was reading fast to adapt my knowledge
from other languages and indeed completely missed the point.

On 12 November 2015 at 15:22, Zachary Ware <zachary.ware+pydocs at gmail.com>
wrote:

> Hi Matthieu,
>
> On Wed, Nov 11, 2015 at 11:58 PM, Matthieu de La Roche Saint-Andr?
> <matthieudelaro at gmail.com> wrote:
> > Hello,
> >
> > Quick email to notice about a typo error on the following documentation
> page
> > : https://docs.python.org/3.5/tutorial/classes.html#method-objects
> >
> > On the last line of the example, a dot is missing between x and f
>
> Actually, it's not; that's the point of the example :).  Note that the
> first line of the last example is "xf = x.f", which assigns the method
> object to the name "xf", which is then used (called) in the last line.
> Try it out using the MyClass class from further up the page.
>
> The page could perhaps use an update to make that more obvious (and
> the example less obnoxious to run), such as:
>
>    method = x.f
>    for each in range(5):
>        print(method())
>
> ...but what's there now is not wrong.
>
> Thanks for the report, though!
>
> Regards,
> --
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/a4cf950d/attachment.html>

From report at bugs.python.org  Thu Nov 12 03:09:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Nov 2015 08:09:36 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447315776.2.0.489696219045.issue25586@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not a big fan of "may" in documentation. I would prefer to rephrase it as an advice. Example:

"Considering the loss of information, it's better to not retry sending data to the socket anymore."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Thu Nov 12 03:10:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Nov 2015 08:10:17 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447315817.39.0.367352933817.issue25586@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: socket-docs.patch file is strange, it looks like you removed the first line starting with "diff", and so we don't get the [Review] button.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Thu Nov 12 04:29:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Nov 2015 09:29:02 +0000
Subject: [docs] [issue25605] fcntl doc: document exceptions raised on error
 for ioctl() and flock()
Message-ID: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch documents the exception raised when ioctl() or flock() functions fail.

Note: flock() can also raises a ValueError if the second parameter (op) is unknown.

If the patch is approved, I will write a similar patch for Python 3 (just replace IOError with OSError in Python 3 doc).

Python 2 online doc:
https://docs.python.org/2/library/fcntl.html

Python 3 online doc:
https://docs.python.org/dev/library/fcntl.html

----------
assignee: docs at python
components: Documentation
files: fcntl_doc.patch
keywords: patch
messages: 254524
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: fcntl doc: document exceptions raised on error for ioctl() and flock()
versions: Python 2.7
Added file: http://bugs.python.org/file41020/fcntl_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25605>
_______________________________________

From Hrvoje.Abraham at avl.com  Thu Nov 12 07:43:17 2015
From: Hrvoje.Abraham at avl.com (Abraham, Hrvoje AVL/HR)
Date: Thu, 12 Nov 2015 12:43:17 +0000
Subject: [docs] Python 2 dis module docs
Message-ID: <482ca78a80084b90adf3a3a0525fdb5a@ATGRZSW1692.avl01.avlcorp.lan>

dis module
https://docs.python.org/2/library/dis.html

Documentation does not include BUILD_SET bytecode instruction, although it seems it is present in all Python 2 versions I experimented with. Maybe my reasoning is wrong (maybe BUILD_SET is not considered bytecode inst.), but also maybe there are some other instructions missing. It is present in Python 3 docs.

minimal case:

import dis
def fun():
    return {1,2,3,4,5}
print dis.dis(fun)

output:

49           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               2 (2)
              6 LOAD_CONST               3 (3)
              9 LOAD_CONST               4 (4)
             12 LOAD_CONST               5 (5)
             15 BUILD_SET                5
             18 RETURN_VALUE
None

Best regards
Hrvoje Abraham




HRVOJE ABRAHAM
Software Development Engineer
Advanced Simulation Technologies / CDU

hrvoje.abraham at avl.com<mailto:hrvoje.abraham at avl.com>
T: +385 1 7775 000, F: +385 1 7775 123
M: +385 99 2380 737, Office: +385 1 7775 068

AVL-AST D.O.O.
HR-10020 Zagreb, Strojarska 22
www .avl .com


[cid:image001.png at 01CF48D8.17AEEF30]<https://www.facebook.com/AVL.List>  [cid:image002.png at 01CF48D8.17AEEF30] <https://twitter.com/AVL_List>   [cid:image003.png at 01CF48D8.17AEEF30] <http://www.linkedin.com/company/avl>   [cid:image004.png at 01CF48D8.17AEEF30] <https://www.xing.com/companies/avllistgmbh>   [cid:image005.png at 01CF48D8.17AEEF30] <http://www.youtube.com/user/AVLList>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/226f73df/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1010 bytes
Desc: image001.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/226f73df/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1094 bytes
Desc: image002.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/226f73df/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 951 bytes
Desc: image003.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/226f73df/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 907 bytes
Desc: image004.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/226f73df/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1195 bytes
Desc: image005.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151112/226f73df/attachment-0009.png>

From zachary.ware+pydocs at gmail.com  Thu Nov 12 11:08:17 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 12 Nov 2015 10:08:17 -0600
Subject: [docs] Python 2 dis module docs
In-Reply-To: <482ca78a80084b90adf3a3a0525fdb5a@ATGRZSW1692.avl01.avlcorp.lan>
References: <482ca78a80084b90adf3a3a0525fdb5a@ATGRZSW1692.avl01.avlcorp.lan>
Message-ID: <CAKJDb-M1jz1VheDRp46VuP+7ik3vQdrEBHUnqEw+yuyRvkWuMg@mail.gmail.com>

On Thu, Nov 12, 2015 at 6:43 AM, Abraham, Hrvoje AVL/HR
<Hrvoje.Abraham at avl.com> wrote:
> dis module
>
> https://docs.python.org/2/library/dis.html
>
> Documentation does not include BUILD_SET bytecode instruction, although it
> seems it is present in all Python 2 versions I experimented with. Maybe my
> reasoning is wrong (maybe BUILD_SET is not considered bytecode inst.), but
> also maybe there are some other instructions missing. It is present in
> Python 3 docs.

Thanks for the report!  This has now been fixed.

-- 
Zach

From report at bugs.python.org  Thu Nov 12 13:04:06 2015
From: report at bugs.python.org (SilentGhost)
Date: Thu, 12 Nov 2015 18:04:06 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447351446.48.0.471344618251.issue25580@psf.upfronthosting.co.za>


SilentGhost added the comment:

I've added versionchanged, since this is what's done in os, for similar lists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Thu Nov 12 15:09:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Nov 2015 20:09:35 +0000
Subject: [docs] [issue8426] multiprocessing.Queue fails to get() very large
 objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1447358975.04.0.626866848578.issue8426@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree with Charles-Fran?ois and think this issue should be closed. There is no a bug, and the behavior is documented.

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Nov 12 15:12:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Nov 2015 20:12:18 +0000
Subject: [docs] [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1447359138.26.0.169648037634.issue16394@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Raymond, do you want to add a clarification to the documentation, or prefer just to close this issue?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16394>
_______________________________________

From report at bugs.python.org  Thu Nov 12 16:34:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Nov 2015 21:34:49 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447364089.31.0.548037460931.issue25580@psf.upfronthosting.co.za>


Martin Panter added the comment:

Do you have a new version of the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Thu Nov 12 17:53:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Nov 2015 22:53:32 +0000
Subject: [docs] [issue25586] socket.sendall broken when a socket has a
 timeout
In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za>
Message-ID: <1447368812.43.0.704932406278.issue25586@psf.upfronthosting.co.za>


Martin Panter added the comment:

For what it?s worth, there could be obsure cases where sending more data might be okay. I prefer the original version (but can settle for either). Here?s a third alternative:

Considering this loss of information, it is generally best not to send any more data to the socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________

From report at bugs.python.org  Thu Nov 12 18:19:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Nov 2015 23:19:18 +0000
Subject: [docs] [issue25605] fcntl doc: document exceptions raised on error
 for ioctl() and flock()
In-Reply-To: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za>
Message-ID: <1447370357.97.0.421919860677.issue25605@psf.upfronthosting.co.za>


Martin Panter added the comment:

This looks good for Python 2 and the equivalent for Python 3.

FWIW the ValueError case is platform-dependent. On Linux, I see EINVAL (the IOError version of ValueError):

>>> flock(0, LOCK_UN)
>>> flock(0, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 22] Invalid argument

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25605>
_______________________________________

From report at bugs.python.org  Thu Nov 12 20:03:04 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 13 Nov 2015 01:03:04 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447376584.86.0.322326008835.issue25580@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

ASYNC/AWAIT tokens are temporary and will be removed in 3.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Thu Nov 12 21:44:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Nov 2015 02:44:24 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1447382664.02.0.657738027198.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a cleaned-up version of Nan?s first patch.

----------
Added file: http://bugs.python.org/file41027/htmllib_deprecation_warning_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Thu Nov 12 22:11:07 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Nov 2015 03:11:07 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1447384267.61.0.103585885863.issue25017@psf.upfronthosting.co.za>


Berker Peksag added the comment:

htmllib_deprecation_warning_3.patch looks good to me.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Thu Nov 12 23:28:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Nov 2015 04:28:40 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
 features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1447388920.45.0.884834019929.issue19023@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sye van der Veen: can you sign a contributor agreement <https://www.python.org/psf/contrib/contrib-form/>? I think it might be needed for this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Fri Nov 13 02:10:18 2015
From: report at bugs.python.org (SilentGhost)
Date: Fri, 13 Nov 2015 07:10:18 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447398618.79.0.247980333815.issue25580@psf.upfronthosting.co.za>


SilentGhost added the comment:

Hm, not sure why the file didn't get uploaded, I clearly remember attaching it.

Yury, what is the implication for this issue? Are you suggesting that the note should state that these two are temporary? Or is this information available somewhere else, in What's new, for example?

----------
Added file: http://bugs.python.org/file41028/issue25580.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Fri Nov 13 03:14:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Nov 2015 08:14:47 +0000
Subject: [docs] [issue25605] fcntl doc: document exceptions raised on error
 for ioctl() and flock()
In-Reply-To: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za>
Message-ID: <20151113081443.109191.95806@psf.io>


Roundup Robot added the comment:

New changeset d3d974e92e6f by Victor Stinner in branch '2.7':
Issue #25605: Document exceptions raised by fcntl.ioctl() and fcntl.flock()
https://hg.python.org/cpython/rev/d3d974e92e6f

New changeset f82cd1ed659e by Victor Stinner in branch '3.4':
Issue #25605: Document exceptions raised by fcntl.ioctl() and fcntl.flock()
https://hg.python.org/cpython/rev/f82cd1ed659e

New changeset cf69fe41f873 by Victor Stinner in branch '3.5':
Merge 3.4 (issue #25605)
https://hg.python.org/cpython/rev/cf69fe41f873

New changeset 0eddeb57c3d6 by Victor Stinner in branch 'default':
Merge 3.5 (issue #25605)
https://hg.python.org/cpython/rev/0eddeb57c3d6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25605>
_______________________________________

From report at bugs.python.org  Fri Nov 13 03:14:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Nov 2015 08:14:53 +0000
Subject: [docs] [issue25605] fcntl doc: document exceptions raised on error
 for ioctl() and flock()
In-Reply-To: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za>
Message-ID: <1447402493.61.0.544346344461.issue25605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the review.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25605>
_______________________________________

From report at bugs.python.org  Fri Nov 13 05:26:21 2015
From: report at bugs.python.org (Dave Jones)
Date: Fri, 13 Nov 2015 10:26:21 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
Message-ID: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>


New submission from Dave Jones:

As suggested in issue 21748, this is a minor documentation change to make explicitly clear that glob.glob returns unsorted results (on the basis that the existing specification references shell behaviour which is always sorted).

----------
assignee: docs at python
components: Documentation
files: glob-spec-unsorted.patch
keywords: patch
messages: 254597
nosy: Dave Jones, docs at python
priority: normal
severity: normal
status: open
title: Document unsorted behaviour of glob.glob
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41029/glob-spec-unsorted.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Fri Nov 13 09:34:41 2015
From: report at bugs.python.org (Sye van der Veen)
Date: Fri, 13 Nov 2015 14:34:41 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
 features
In-Reply-To: <1447388920.45.0.884834019929.issue19023@psf.upfronthosting.co.za>
Message-ID: <CA+No7BSkNk4Wy3nARV2VxayrhgbnuYKFt_NBh1axfkNmmmRmQg@mail.gmail.com>


Sye van der Veen added the comment:

Signed and confirmed. :-)

On Thu, Nov 12, 2015 at 11:28 PM Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> Sye van der Veen: can you sign a contributor agreement <
> https://www.python.org/psf/contrib/contrib-form/>? I think it might be
> needed for this patch.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue19023>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Fri Nov 13 13:15:35 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 13 Nov 2015 18:15:35 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447438535.8.0.621256098081.issue25580@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Are you suggesting that the note should state that these two are temporary? 

Yes, that would be great.


> Or is this information available somewhere else, in What's new, for example?

Not directly, I think.  It was detailed to some extent in PEP 492.  In what's new of 3.5 & 3.6 it's stated that async/await will be keywords in 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Fri Nov 13 13:18:24 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 13 Nov 2015 18:18:24 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447438704.65.0.0137202045669.issue25594@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks for tracking that down.

After more research I'm inclined to leave the code as it is and revamp the docs to clarify that while it may work, the results may not be what you want:

-- 8< -------------------
class Color(Enum):
    red = 1
    blue = 2
    name = 3

print(Color.name)         # Color.name
print(Color.name.blue)    # Color.blue
print(Color.blue.name)    # 'blue'  (not Color.name!)
-- 8< -------------------

Patch attached.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41030/issue25594.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From ghost.adh at gmail.com  Fri Nov 13 13:25:34 2015
From: ghost.adh at gmail.com (ghost.adh at gmail.com)
Date: Fri, 13 Nov 2015 18:25:34 -0000
Subject: [docs] enum docs outdated re attribute access (issue 25594)
Message-ID: <20151113182534.22831.21587@psf.upfronthosting.co.za>

Reviewers: ,

Message:
One typo.


https://bugs.python.org/review/25594/diff/15947/Doc/library/enum.rst
File Doc/library/enum.rst (right):

https://bugs.python.org/review/25594/diff/15947/Doc/library/enum.rst#newcode733
Doc/library/enum.rst:733: Enum members are instances of an Enum class,
and even though they are
Not related to the issue, but perhaps one of the Enum could be linked
with :class:`Enum`?

https://bugs.python.org/review/25594/diff/15947/Doc/library/enum.rst#newcode747
Doc/library/enum.rst:747: The :attr:`__members__` attribtute is only
available on the class.
Should read "attribute"



Please review this at https://bugs.python.org/review/25594/

Affected files:
  Doc/library/enum.rst


diff -r 828c9b920532 Doc/library/enum.rst
--- a/Doc/library/enum.rst	Fri Nov 13 15:18:26 2015 +0200
+++ b/Doc/library/enum.rst	Fri Nov 13 10:17:02 2015 -0800
@@ -724,31 +724,34 @@ The most interesting thing about Enum me
 :class:`EnumMeta` creates them all while it is creating the :class:`Enum`
 class itself, and then puts a custom :meth:`__new__` in place to ensure
 that no new ones are ever instantiated by returning only the existing
 member instances.
 
 
 Finer Points
 ^^^^^^^^^^^^
 
 Enum members are instances of an Enum class, and even though they are
-accessible as `EnumClass.member`, they are not accessible directly from
+accessible as `EnumClass.member`, they may not be accessible directly from
 the member::
 
-    >>> Color.red
-    <Color.red: 1>
-    >>> Color.red.blue
-    Traceback (most recent call last):
+    >>> class FieldTypes(Enum):
+    ...     name = 0
+    ...     value = 1
+    ...     size = 2
     ...
-    AttributeError: 'Color' object has no attribute 'blue'
+    >>> FieldTypes.value.size
+    <FieldTypes.size: 2>
+    >>> FieldTypes.size.value
+    2
 
-Likewise, the :attr:`__members__` is only available on the class.
+The :attr:`__members__` attribtute is only available on the class.
 
 If you give your :class:`Enum` subclass extra methods, like the `Planet`_
 class above, those methods will show up in a :func:`dir` of the member,
 but not of the class::
 
     >>> dir(Planet)
     ['EARTH', 'JUPITER', 'MARS', 'MERCURY', 'NEPTUNE', 'SATURN', 'URANUS', 'VENUS', '__class__', '__doc__', '__members__', '__module__']
     >>> dir(Planet.EARTH)
     ['__class__', '__doc__', '__module__', 'name', 'surface_gravity', 'value']
 



From report at bugs.python.org  Fri Nov 13 13:36:49 2015
From: report at bugs.python.org (SilentGhost)
Date: Fri, 13 Nov 2015 18:36:49 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447439809.86.0.848069136993.issue25580@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the updated wording. I'm not familiar with other such cases in the stdlib, if any one knows of another similar case, I'd be glad to correct the language to match previous usage.

----------
Added file: http://bugs.python.org/file41031/issue25580_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Fri Nov 13 17:58:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Nov 2015 22:58:22 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447455502.37.0.341977923187.issue25580@psf.upfronthosting.co.za>


Martin Panter added the comment:

Will they really be removed? What are the compatibility implications? Maybe it would be better to alias them to NAME, or keep them as unused values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Fri Nov 13 18:04:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Nov 2015 23:04:25 +0000
Subject: [docs] [issue25580] async and await missing from token list
In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za>
Message-ID: <1447455865.08.0.465302929354.issue25580@psf.upfronthosting.co.za>


Martin Panter added the comment:

My only background here is via the tokenize module, which seems to currently behave as described in <https://www.python.org/dev/peps/pep-0492/#transition-plan>: async and await are either NAME tokens (like ordinary identifiers and other reserved keywords) outside a coroutine definition, but they become special ASYNC and AWAIT tokens inside a coroutine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25580>
_______________________________________

From report at bugs.python.org  Fri Nov 13 18:19:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Nov 2015 23:19:30 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <1447456770.8.0.5985492525.issue25615@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks good to me. Also worth applying to earlier versions I think.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Fri Nov 13 19:45:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Nov 2015 00:45:13 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <20151114004511.14353.37505@psf.io>


Roundup Robot added the comment:

New changeset 7bc8f56ef1f3 by Martin Panter in branch '2.7':
Issue #25017: Document that htmllib is superseded by module HTMLParser
https://hg.python.org/cpython/rev/7bc8f56ef1f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Fri Nov 13 19:48:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 Nov 2015 00:48:43 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1447462123.29.0.832820681545.issue25017@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From ethan at stoneleaf.us  Sun Nov 15 04:15:19 2015
From: ethan at stoneleaf.us (ethan at stoneleaf.us)
Date: Sun, 15 Nov 2015 09:15:19 -0000
Subject: [docs] enum docs outdated re attribute access (issue 25594)
Message-ID: <20151115091519.14836.5076@psf.upfronthosting.co.za>


http://bugs.python.org/review/25594/diff/15947/Doc/library/enum.rst
File Doc/library/enum.rst (right):

http://bugs.python.org/review/25594/diff/15947/Doc/library/enum.rst#newcode733
Doc/library/enum.rst:733: Enum members are instances of an Enum class,
and even though they are
Good idea.

http://bugs.python.org/review/25594/diff/15947/Doc/library/enum.rst#newcode747
Doc/library/enum.rst:747: The :attr:`__members__` attribtute is only
available on the class.
Fixed.

http://bugs.python.org/review/25594/

From report at bugs.python.org  Sun Nov 15 04:15:44 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Nov 2015 09:15:44 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447578944.15.0.660659121376.issue25594@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


Added file: http://bugs.python.org/file41048/issue25594.stoneleaf.03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Sun Nov 15 05:40:13 2015
From: report at bugs.python.org (Dave Jones)
Date: Sun, 15 Nov 2015 10:40:13 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <1447584013.67.0.954507814465.issue25615@psf.upfronthosting.co.za>


Dave Jones added the comment:

Sounds good; the patch seems to apply cleanly to checkouts of 2.7, 3.4, and 3.5 so I'm assuming I don't need to do anything else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Sun Nov 15 06:19:39 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 15 Nov 2015 11:19:39 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447586379.5.0.307531143255.issue25594@psf.upfronthosting.co.za>


SilentGhost added the comment:

No further comments re the latest patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Sun Nov 15 14:06:56 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Nov 2015 19:06:56 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <1447614416.56.0.364747995229.issue25615@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for the doc update.

For future reference, the doc patches are much easier to review if you don't rewrap the text (we can easily do that part before applying the patch).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Sun Nov 15 14:26:15 2015
From: report at bugs.python.org (Dave Jones)
Date: Sun, 15 Nov 2015 19:26:15 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <1447615575.79.0.0841160087894.issue25615@psf.upfronthosting.co.za>


Dave Jones added the comment:

Ah, sorry about that - force of habit. I did wonder if it was preferable to have a nicely wrapped patch, or to have a clean diff but obviously figured wrong! I'll know for future :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Sun Nov 15 15:48:48 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Nov 2015 20:48:48 +0000
Subject: [docs] [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1447620528.47.0.797447743586.issue16394@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Unlike the other "equivalents" in the docs, this one is further away from the actual implementation.  So, I think I should add a clarification that the example code is a "rough logical equivalent" but that actual implementation may have shared queues (Jython, PyPy, and IronPython are free to have their own implementation choices).

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16394>
_______________________________________

From report at bugs.python.org  Mon Nov 16 01:12:17 2015
From: report at bugs.python.org (Antony Lee)
Date: Mon, 16 Nov 2015 06:12:17 +0000
Subject: [docs] [issue25632] Document BUILD_*_UNPACK opcodes
Message-ID: <1447654337.27.0.0979674663638.issue25632@psf.upfronthosting.co.za>


New submission from Antony Lee:

The additional unpack generalizations provided by Python3.5 rely on a new set of opcodes, BUILD_{TUPLE,LIST,DICT,SET}_UNPACK, that are not documented in the docs for the dis module.

----------
assignee: docs at python
components: Documentation
messages: 254715
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Document BUILD_*_UNPACK opcodes
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25632>
_______________________________________

From report at bugs.python.org  Mon Nov 16 03:42:51 2015
From: report at bugs.python.org (jon orebro)
Date: Mon, 16 Nov 2015 08:42:51 +0000
Subject: [docs] [issue25633] The documentation for urllib.request should
 mention http.client.HTTPException
Message-ID: <1447663371.73.0.839165836135.issue25633@psf.upfronthosting.co.za>


New submission from jon orebro:

The documentation for urllib.request should mention that a robust client using urllib.request must be prepared for exceptions of type http.client.HTTPException in addition to urllib.error.URLError.

Example: the server breaks HTTP and returns an empty status line and we get a http.client.BadStatusLine.

----------
assignee: docs at python
components: Documentation
messages: 254720
nosy: docs at python, jon orebro
priority: normal
severity: normal
status: open
title: The documentation for urllib.request should mention http.client.HTTPException
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25633>
_______________________________________

From report at bugs.python.org  Mon Nov 16 09:29:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Nov 2015 14:29:08 +0000
Subject: [docs] [issue13821] misleading return from isidentifier
In-Reply-To: <1326934459.59.0.614334427327.issue13821@psf.upfronthosting.co.za>
Message-ID: <1447684148.85.0.445383358258.issue13821@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, haypo, serhiy.storchaka
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13821>
_______________________________________

From report at bugs.python.org  Mon Nov 16 10:30:02 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Nov 2015 15:30:02 +0000
Subject: [docs] [issue13821] misleading return from isidentifier
In-Reply-To: <1326934459.59.0.614334427327.issue13821@psf.upfronthosting.co.za>
Message-ID: <1447687802.94.0.641142906147.issue13821@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13821>
_______________________________________

From report at bugs.python.org  Mon Nov 16 17:17:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 Nov 2015 22:17:41 +0000
Subject: [docs] [issue25633] The documentation for urllib.request should
 mention http.client.HTTPException
In-Reply-To: <1447663371.73.0.839165836135.issue25633@psf.upfronthosting.co.za>
Message-ID: <1447712261.09.0.981042626181.issue25633@psf.upfronthosting.co.za>


Martin Panter added the comment:

Closely related: Issue 22797 proposes documenting some circumstances where ValueError is raised directly. Perhaps you can review and enhance the patch already there.

Also related:

Issue 13736 proposes to wrap http.client exceptions (which I disagree with), and add extra wrapping for socket.error (which I may agree with for consistency), and document existing ?exception leaks?.

Issue 6471 discusses awkwardnesses of getting at the underlying exception that URLError wraps.

----------
nosy: +martin.panter
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25633>
_______________________________________

From report at bugs.python.org  Mon Nov 16 19:28:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Nov 2015 00:28:48 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <1447720128.58.0.140993161247.issue25615@psf.upfronthosting.co.za>


Martin Panter added the comment:

I committed the patch as it was. But normally I do try to keep the number of lines in the diff close to the minimum, even when committing. RST files are like source code and it doesn?t matter if the wrapping is not 100% perfect, because they get turned into HTML or whatever anyway. Plus keeping the diff to a minimum helps when looking through the repository history with annotate or whatever.

On the other hand, for doc strings, I think it is best to rewrap them, because that is the wrapping you end up with in pydoc and help().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Mon Nov 16 19:29:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Nov 2015 00:29:01 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <1447720141.86.0.610872121284.issue25615@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Mon Nov 16 19:20:54 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Nov 2015 00:20:54 +0000
Subject: [docs] [issue25615] Document unsorted behaviour of glob.glob
In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za>
Message-ID: <20151117002051.21857.34@psf.io>


Roundup Robot added the comment:

New changeset fa4f0096b719 by Martin Panter in branch '2.7':
Issue #25615: Document unsorted behaviour of glob; patch by Dave Jones
https://hg.python.org/cpython/rev/fa4f0096b719

New changeset 7ca6a13db0e5 by Martin Panter in branch '3.4':
Issue #25615: Document unsorted behaviour of glob; patch by Dave Jones
https://hg.python.org/cpython/rev/7ca6a13db0e5

New changeset f928dcb448a9 by Martin Panter in branch '3.5':
Issue #25615: Merge glob doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/f928dcb448a9

New changeset a6bc96c2b8be by Martin Panter in branch 'default':
Issue #25615: Merge glob doc from 3.5
https://hg.python.org/cpython/rev/a6bc96c2b8be

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25615>
_______________________________________

From report at bugs.python.org  Tue Nov 17 06:52:43 2015
From: report at bugs.python.org (John Runyon)
Date: Tue, 17 Nov 2015 11:52:43 +0000
Subject: [docs] [issue24172] Errors in resource.getpagesize module
 documentation
In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za>
Message-ID: <1447761163.3.0.212982879447.issue24172@psf.upfronthosting.co.za>


John Runyon added the comment:

This is a duplicate of 20468, which has a patch submitted (over a year ago).

----------
nosy: +jrunyon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24172>
_______________________________________

From report at bugs.python.org  Tue Nov 17 07:02:56 2015
From: report at bugs.python.org (John Runyon)
Date: Tue, 17 Nov 2015 12:02:56 +0000
Subject: [docs] [issue24256] threading.Timer is not a class
In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za>
Message-ID: <1447761776.62.0.800394418149.issue24256@psf.upfronthosting.co.za>


John Runyon added the comment:

New proposed patch.

I understand not wanting to document an "internal only name", except that in this case it rather needs to be documented. I would strongly prefer Angad's patch to mine because you do, at times, need to know the actual name of the class being used -- and the documentation should not force people to dig through the source code to find that.

----------
Added file: http://bugs.python.org/file41062/timer.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24256>
_______________________________________

From report at bugs.python.org  Tue Nov 17 17:20:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Nov 2015 22:20:07 +0000
Subject: [docs] [issue24172] Errors in resource.getpagesize module
 documentation
In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za>
Message-ID: <1447798807.28.0.225967997757.issue24172@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation already says to consult the getrusage(2) man page.

Regarding the getpagesize() API, Python?s implementation actually falls back to Posix?s sysconf(). Perhaps it should prefer sysconf() over getpagesize(), but that would be a separate issue.

Anyway I will commit the important half of the Issue 20468?s patch, so I think we can close this.

----------
nosy: +martin.panter
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> resource module documentation is incorrect
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24172>
_______________________________________

From report at bugs.python.org  Tue Nov 17 18:20:01 2015
From: report at bugs.python.org (Mouse)
Date: Tue, 17 Nov 2015 23:20:01 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1447802401.67.0.98311322486.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Status...?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Tue Nov 17 19:00:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Nov 2015 00:00:32 +0000
Subject: [docs] [issue14911] generator.throw() documentation inaccurate
In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>
Message-ID: <1447804832.03.0.781667481662.issue14911@psf.upfronthosting.co.za>


Martin Panter added the comment:

I can?t really comment on the 2.7 version, because I?m not too familiar with Python 2 exceptions.

For Python 3, is there any reason to bless the None, tuple or non-exception cases as the exception ?value? argument? IMO these just make things too complicated without any benefit. Changes I would make to the patch:

* Only mention that ?value? can be omitted, or it can be an instance of the class specified by ?type?. Drop mentioning the None option, and the single or tuple constructor argument options. It looks like the tuple option actually gets expanded to multiple constructor arguments?!
* Mention that if ?value? is passed, its traceback could be lost
* Drop the example, unless someone can come up with a concise and realistic example
* Unify with definition for coroutines <https://docs.python.org/dev/reference/datamodel.html#coroutine.throw>
* Change the doc string(s) to match the argument names, but don?t bother copying the full definition text

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14911>
_______________________________________

From report at bugs.python.org  Tue Nov 17 19:52:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Nov 2015 00:52:06 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1447807926.72.0.191120215975.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looking at the current zlib module source code, I confirmed that wbits is passed directly to the deflateInit2(windowBits) and inflateInit2(windowBits) parameters. So the following modes could also be added to the documentation for decompression:

* Zero: automatically determine size from zlib header
* 32 + logarithm: automatically accept either a zlib or gzip header

Also, the compressobj() doc string is out of date. It mentions 8?15 but none of the other options.

Paul: Perhaps it would be better to say ?wbits? corresponds to the format of the stream, rather than mentioning just the window size as currently proposed. Then hopefully the reader would look to see what value is needed for the raw Deflate format.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Tue Nov 17 21:59:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Nov 2015 02:59:13 +0000
Subject: [docs] [issue23200] Clarify max_length and flush() for zlib
 decompression
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <20151118025909.4679.32162@psf.io>


Roundup Robot added the comment:

New changeset 106c49edbb12 by Martin Panter in branch '2.7':
Issue #23200: Document that max_length=0 is not supported
https://hg.python.org/cpython/rev/106c49edbb12

New changeset 660bdfaada64 by Martin Panter in branch '3.4':
Issue #23200: Document that max_length=0 is not supported
https://hg.python.org/cpython/rev/660bdfaada64

New changeset d64bb25cf797 by Martin Panter in branch '3.5':
Issue #23200: Merge zlib doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/d64bb25cf797

New changeset cdd403dd82cb by Martin Panter in branch 'default':
Issue #23200: Merge zlib doc from 3.5
https://hg.python.org/cpython/rev/cdd403dd82cb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23200>
_______________________________________

From report at bugs.python.org  Tue Nov 17 23:42:25 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Nov 2015 04:42:25 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1447821745.03.0.044603478396.issue25594@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Changed the wording slightly to indicate that looking up members on other members is a bad idea.

----------
Added file: http://bugs.python.org/file41064/issue25594.stoneleaf.04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Wed Nov 18 02:44:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Nov 2015 07:44:02 +0000
Subject: [docs] =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor?=
 =?utf-8?b?4oCZcyBmbHVzaCgpIG1ldGhvZA==?=
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <1447832641.32.0.29445730655.issue23200@psf.upfronthosting.co.za>


Martin Panter added the comment:

See Issue 224981 (bug) and Issue 403373 (patch) about the Z_SYNC_FLUSH change (the numbers in the commit message are different and do not work).

I committed my doc change to 2.7 and 3.4+, which leaves the main problem of what to do about flush(). I propose deprecate-flush.patch for 3.6, which deprecates this method.

I ran the test suite with -Werror, so I hopefully got all the instances of flush() in the library.

----------
components: +Library (Lib) -Documentation
title: Clarify max_length and flush() for zlib decompression -> Deprecate the zlib decompressor?s flush() method
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file41067/deprecate-flush.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23200>
_______________________________________

From report at bugs.python.org  Wed Nov 18 03:07:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Nov 2015 08:07:07 +0000
Subject: [docs] =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor?=
 =?utf-8?b?4oCZcyBmbHVzaCgpIG1ldGhvZA==?=
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <1447834027.59.0.372822408092.issue23200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Besides unconsumed_tail there is an internal buffer. Even if flush() is no longer needed in the zlib decompresser (I don't know), I doubt about bz2 and lzma.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23200>
_______________________________________

From report at bugs.python.org  Wed Nov 18 06:05:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Nov 2015 11:05:21 +0000
Subject: [docs] =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor?=
 =?utf-8?b?4oCZcyBmbHVzaCgpIG1ldGhvZA==?=
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <1447844721.63.0.0218206463663.issue23200@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the bz2 and lzma modules, neither decompressor classes have a flush() method, only the compressors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23200>
_______________________________________

From report at bugs.python.org  Thu Nov 19 04:00:33 2015
From: report at bugs.python.org (jon orebro)
Date: Thu, 19 Nov 2015 09:00:33 +0000
Subject: [docs] [issue25666] Python unexpectedly ignores a signal after fork
Message-ID: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za>


New submission from jon orebro:

Description:
I found a slight problem with signal handling. It seems that if you have a signal handler setup for a signal, right after a fork the child ignores that signal for a short time. This is regardless of what the signal handler is setup to do. This can cause hangs if the parent immediately kills and then waits for the child. Since the timeframe is small, in practice this only happens sometimes (se example). There might be a reason for this behavour, but in that case I think it should me mentioned in the docs.

What I expected:
I expected the child to, at any point in time, either do the default action for the signal (terminate in this case), or to run the signal handler.

What happens:
It ignores the signal for a short while.

Tested versions:
Python 2.7.6
Python 3.4.0

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: example.py
messages: 254890
nosy: docs at python, jon orebro
priority: normal
severity: normal
status: open
title: Python unexpectedly ignores a signal after fork
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41074/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25666>
_______________________________________

From report at bugs.python.org  Thu Nov 19 09:42:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Nov 2015 14:42:42 +0000
Subject: [docs] [issue25666] Python unexpectedly ignores a signal after fork
In-Reply-To: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za>
Message-ID: <1447944162.09.0.0909725767639.issue25666@psf.upfronthosting.co.za>


R. David Murray added the comment:

Are you sure this is a python issue and not an OS issue?  That is, does an equivalent C program work correctly?  Since the operation is a fork, I don't think there's anything that python does that would cause the signal to be ignored.

The comment block in the example code here: https://www.win.tue.nl/~aeb/linux/lk/lk-5.html makes me think that the signal getting ignored is a possibility at the OS level, though it isn't explicitly clear.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25666>
_______________________________________

From report at bugs.python.org  Thu Nov 19 17:24:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Nov 2015 22:24:30 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
 of Pool example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1447971870.31.0.705687164607.issue18620@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18620>
_______________________________________

From report at bugs.python.org  Thu Nov 19 20:58:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Nov 2015 01:58:19 +0000
Subject: [docs] [issue25666] Python unexpectedly ignores a signal after fork
In-Reply-To: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za>
Message-ID: <1447984699.59.0.414435601246.issue25666@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a modified version of the script that is not a slow fork bomb. In the original, if time.sleep(600) fails to be interrupted, the children end up continuing the loop and forking more children.

I tried Python 3.5, 2.7 and 3.4. I am seeing the signal completely ignored (at the Python level), not just ignored ?for a short while?. Here is a sample output:

$ python3 example.py
Python handler called
Parent waiting for child
Got exit status 0x0000
===
Parent waiting for child
Child: 0
Child: 1
Child: 2
Child: 3
Child: 4
Child: 5
Got exit status 0x0100

David may be right that it is an OS thing, though it does not seem likely IMO. It needs more investigation or expert knowledge.

But I would like to point out that even if the bug of the signal being completely ignored is fixed, the code still has a race condition. The signal could arrive in the window between when Python checks for signals and when it calls sleep(). Then the signal will be ignored until sleep() has returned. If you need this code to be robust, I suggest looking at set_signal_fd() and select().

----------
nosy: +martin.panter
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41089/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25666>
_______________________________________

From report at bugs.python.org  Fri Nov 20 04:13:31 2015
From: report at bugs.python.org (Novice Live)
Date: Fri, 20 Nov 2015 09:13:31 +0000
Subject: [docs] [issue25679] Fix typo in Doc/reference/executionmodel.rst
Message-ID: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za>


New submission from Novice Live:

> 4. Execution model
> 4.1. Structure of a programm

You see.

----------
assignee: docs at python
components: Documentation
files: executionmodel-typo.patch
keywords: patch
messages: 254962
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: Fix typo in Doc/reference/executionmodel.rst
Added file: http://bugs.python.org/file41092/executionmodel-typo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25679>
_______________________________________

From vadmium+py at gmail.com  Tue Nov 17 18:24:33 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Tue, 17 Nov 2015 23:24:33 -0000
Subject: [docs] generator.throw() documentation inaccurate (issue 14911)
Message-ID: <20151117232433.14836.59176@psf.upfronthosting.co.za>


http://bugs.python.org/review/14911/diff/10905/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

http://bugs.python.org/review/14911/diff/10905/Doc/reference/expressions.rst#newcode446
Doc/reference/expressions.rst:446: If provided, the ``tb`` argument is
used for the raised exception, otherwise
On 2014/02/03 18:37:37, Yury.Selivanov wrote:
> ``traceback`` instead of ``tb``?

The usual markup for these is actually *traceback*

http://bugs.python.org/review/14911/diff/10905/Doc/reference/expressions.rst#newcode447
Doc/reference/expressions.rst:447: the excepition instance's
:attr:`__traceback__` attribute is used.
In my experience, if you use the *value* parameter, you have to
explicitly give the traceback, otherwise the original traceback gets
cleared.

http://bugs.python.org/review/14911/diff/10905/Doc/reference/expressions.rst#newcode447
Doc/reference/expressions.rst:447: the excepition instance's
:attr:`__traceback__` attribute is used.
exception instance [Spelling]

http://bugs.python.org/review/14911/

From vadmium+py at gmail.com  Tue Nov 17 19:47:12 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 18 Nov 2015 00:47:12 -0000
Subject: [docs] raw deflate format and zlib module (issue 5784)
Message-ID: <20151118004712.32193.30392@psf.upfronthosting.co.za>


https://bugs.python.org/review/5784/diff/14652/Doc/library/zlib.rst
File Doc/library/zlib.rst (right):

https://bugs.python.org/review/5784/diff/14652/Doc/library/zlib.rst#newcode84
Doc/library/zlib.rst:84: * -8 to -15: Uses the absolute value of *wbits*
as the window size, while
absolute value .?.?. as the logarithm

https://bugs.python.org/review/5784/diff/14652/Doc/library/zlib.rst#newcode88
Doc/library/zlib.rst:88: the window size, while including a basic
:program:`gzip` header
as the logarithm

https://bugs.python.org/review/5784/diff/14652/Doc/library/zlib.rst#newcode143
Doc/library/zlib.rst:143: :func:`compressobj`.  When decompressing a
stream, *wbits* must not be
the history buffer size must not be smaller

[According to the zlib inflateInit2() documentation, for the negative
case it is the magnitude that cannot be smaller, which makes more sense
than the alternative.]

https://bugs.python.org/review/5784/

From vadmium+py at gmail.com  Wed Nov 18 07:09:28 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 18 Nov 2015 12:09:28 -0000
Subject: [docs] Clarify max_length and flush() for zlib decompression (issue
 23200)
Message-ID: <20151118120928.22125.29875@psf.upfronthosting.co.za>

Reviewers: ,


https://bugs.python.org/review/23200/diff/15974/Lib/zipfile.py
File Lib/zipfile.py (right):

https://bugs.python.org/review/23200/diff/15974/Lib/zipfile.py#newcode922
Lib/zipfile.py:922: not data and
Actually I think this condition also needs to fail if any compressed
data was passed in:

compressed_data = data  # Before decompression

if ... not compressed_data and not data and ...



Please review this at https://bugs.python.org/review/23200/

Affected files:
  Doc/library/zlib.rst
  Doc/whatsnew/3.6.rst
  Lib/encodings/zlib_codec.py
  Lib/test/test_codecs.py
  Lib/test/test_zlib.py
  Lib/zipfile.py
  Misc/NEWS
  Modules/zlibmodule.c



From report at bugs.python.org  Fri Nov 20 10:00:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Nov 2015 15:00:36 +0000
Subject: [docs] [issue25679] Fix typo in Doc/reference/executionmodel.rst
In-Reply-To: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za>
Message-ID: <20151120150028.79037.59836@psf.io>


Roundup Robot added the comment:

New changeset 3e723559d9f1 by R David Murray in branch '3.4':
#25679: spelling fix
https://hg.python.org/cpython/rev/3e723559d9f1

New changeset 44ca5e073feb by R David Murray in branch '3.5':
Merge: #25679: spelling fix
https://hg.python.org/cpython/rev/44ca5e073feb

New changeset 14a3cfc477c6 by R David Murray in branch 'default':
Merge: #25679: spelling fix
https://hg.python.org/cpython/rev/14a3cfc477c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25679>
_______________________________________

From report at bugs.python.org  Fri Nov 20 10:01:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Nov 2015 15:01:58 +0000
Subject: [docs] [issue25679] Fix typo in Doc/reference/executionmodel.rst
In-Reply-To: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za>
Message-ID: <1448031718.53.0.807028889927.issue25679@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed, thanks.  I wonder if it was one of our german speakers who typed that :)

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25679>
_______________________________________

From report at bugs.python.org  Fri Nov 20 16:19:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Nov 2015 21:19:57 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <20151120211954.21873.31939@psf.io>


Roundup Robot added the comment:

New changeset 276cf69b911e by Ethan Furman in branch '3.5':
Close issue25594: advise against accessing Enum members from other members
https://hg.python.org/cpython/rev/276cf69b911e

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From report at bugs.python.org  Fri Nov 20 16:35:44 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 20 Nov 2015 21:35:44 +0000
Subject: [docs] [issue25594] enum instance attribute access possible
In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za>
Message-ID: <1448055344.66.0.823945968895.issue25594@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Other changeset f4b495ceab17 in default branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25594>
_______________________________________

From cwilliams at spotxchange.com  Fri Nov 20 18:24:11 2015
From: cwilliams at spotxchange.com (Colton Williams)
Date: Fri, 20 Nov 2015 16:24:11 -0700
Subject: [docs] struct package documentation bug
Message-ID: <4D6A2CB2-6DC3-4B2F-9AB1-998414C7B0E2@spotxchange.com>

The documentation for the `struct` package https://docs.python.org/2/library/struct.html <https://docs.python.org/2/library/struct.html> indicates that using ?l? (that?s an ?l? as in leopard) as the format character for the pack function will return 4 bytes. Using that format character appears to actually return 8 bytes of data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151120/bf9eb673/attachment.html>

From encukou at gmail.com  Fri Nov 20 18:53:31 2015
From: encukou at gmail.com (Petr Viktorin)
Date: Sat, 21 Nov 2015 00:53:31 +0100
Subject: [docs] struct package documentation bug
In-Reply-To: <4D6A2CB2-6DC3-4B2F-9AB1-998414C7B0E2@spotxchange.com>
References: <4D6A2CB2-6DC3-4B2F-9AB1-998414C7B0E2@spotxchange.com>
Message-ID: <CA+=+wqADRZzpRZU3sVTKnXj94RU=N4qYRbOB=BH0Q6ye5YuzHA@mail.gmail.com>

On Sat, Nov 21, 2015 at 12:24 AM, Colton Williams
<cwilliams at spotxchange.com> wrote:
> The documentation for the `struct` package
> https://docs.python.org/2/library/struct.html indicates that using ?l?
> (that?s an ?l? as in leopard) as the format character for the pack function
> will return 4 bytes. Using that format character appears to actually return
> 8 bytes of data.

Hello,
Are you by any chance using native data sizes? As explained in the
"Byte Order, Size, and Alignment" section, you need to put one of the
characters =, <, >, or ! at the start of the format string to select
the "standard" sizes.

From report at bugs.python.org  Sat Nov 21 07:35:52 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 21 Nov 2015 12:35:52 +0000
Subject: [docs] [issue25689] ftplib docs language fix
Message-ID: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za>


New submission from SilentGhost:

Just a minor fix, removing the following: "Here is a sample on how using it:"

----------
assignee: docs at python
components: Documentation
files: ftplib_docs.diff
keywords: patch
messages: 255056
nosy: SilentGhost, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: ftplib docs language fix
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41112/ftplib_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25689>
_______________________________________

From report at bugs.python.org  Sat Nov 21 10:03:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Nov 2015 15:03:28 +0000
Subject: [docs] [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1448118208.56.0.770410093534.issue13275@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The wording in the tutorial was changed in issue23891. Now ElementTree is mentioned on first place. In the "Structured Markup Processing Tools" section ElementTree is listed before other XML processing modules.

I think this issue can be closed now.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Sat Nov 21 10:09:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Nov 2015 15:09:26 +0000
Subject: [docs] [issue10942] xml.etree.ElementTree.tostring returns type
 bytes, expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1448118566.01.0.0548842701118.issue10942@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For now the documentation explains the resulting type of tostring().

https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring
"""
Generates a string representation of an XML element, including all subelements. element is an Element instance. encoding [1] is the output encoding (default is US-ASCII). Use encoding="unicode" to generate a Unicode string (otherwise, a bytestring is generated). method is either "xml", "html" or "text" (default is "xml").
"""

Looks as this issue can be closed.

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Sat Nov 21 17:46:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Nov 2015 22:46:06 +0000
Subject: [docs] [issue25689] ftplib docs language fix
In-Reply-To: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za>
Message-ID: <1448145966.68.0.0184297036104.issue25689@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch, I will commit it.

I also noticed the same problem in nntplib. And I think the sentence works even better starting as ?The FTP class supports .?.?.?.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25689>
_______________________________________

From report at bugs.python.org  Sat Nov 21 17:56:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Nov 2015 22:56:51 +0000
Subject: [docs] [issue25689] ftplib docs language fix
In-Reply-To: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za>
Message-ID: <20151121225648.15095.47816@psf.io>


Roundup Robot added the comment:

New changeset 74111e62a76c by Martin Panter in branch '3.4':
Issue #25689: Fix language in ftplib and nntplib docs
https://hg.python.org/cpython/rev/74111e62a76c

New changeset 2fa12e53e8f3 by Martin Panter in branch '3.5':
Issue #25689: Merge ftplib and nntplib docs from 3.4 into 3.5
https://hg.python.org/cpython/rev/2fa12e53e8f3

New changeset b99a30383bd5 by Martin Panter in branch 'default':
Issue #25689: Merge ftplib and nntplib docs from 3.5
https://hg.python.org/cpython/rev/b99a30383bd5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25689>
_______________________________________

From report at bugs.python.org  Sat Nov 21 18:06:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Nov 2015 23:06:27 +0000
Subject: [docs] [issue25689] ftplib docs language fix
In-Reply-To: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za>
Message-ID: <1448147187.92.0.00965516201471.issue25689@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25689>
_______________________________________

From report at bugs.python.org  Sun Nov 22 05:33:17 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 22 Nov 2015 10:33:17 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1448188397.41.0.26692575932.issue4744@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Ping, what's the status of this issue ? maybe we can close it and open an new one with a new description.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Sun Nov 22 10:44:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Nov 2015 15:44:48 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
Message-ID: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

the list in Misc/ACKS is intended to be in rough alphabetical order by last names. But some lines breaks this order. Proposed patch restores ordering. It also removes duplicates for Richard Oudkerk.

Correct sorting is not easy due to different letter order in different alphabets and different collation rules in different languages. I tried to take it into account, but can make a mistake.

----------
assignee: docs at python
components: Documentation
files: acks_order-3.6.patch
keywords: patch
messages: 255106
nosy: docs at python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix rough alphabetical order in Misc/ACKS
Added file: http://bugs.python.org/file41125/acks_order-3.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Sun Nov 22 16:53:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Nov 2015 21:53:22 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1448229202.17.0.607837184501.issue4744@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think it would be okay to keep this issue open to address the other mentions of ?strings?.

Nitika?s patch is missing the special --- and @@ indicator lines at the top, which is probably why it was rejected. Usually you make a patch by using a ?diff? command (standalone, with Mercurial, etc).

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From vadmium+py at gmail.com  Sun Nov 22 17:48:24 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 22 Nov 2015 22:48:24 -0000
Subject: [docs] Fix rough alphabetical order in Misc/ACKS (issue 25697)
Message-ID: <20151122224824.27150.85039@psf.upfronthosting.co.za>


https://bugs.python.org/review/25697/diff/16019/Misc/ACKS
File Misc/ACKS (left):

https://bugs.python.org/review/25697/diff/16019/Misc/ACKS#oldcode899
Misc/ACKS:899: Tomasz Ma?kowiak
According to
<https://en.wikipedia.org/wiki/Polish_alphabet#Alphabetical_order>,
accented ? comes after plain c, so maybe this is better where it is.

https://bugs.python.org/review/25697/

From report at bugs.python.org  Sun Nov 22 17:50:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Nov 2015 22:50:16 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <1448232616.04.0.719865354382.issue25697@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left one review comment about Ma?kowiak. The other changes look okay.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From storchaka at gmail.com  Sun Nov 22 18:17:07 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Sun, 22 Nov 2015 23:17:07 -0000
Subject: [docs] Fix rough alphabetical order in Misc/ACKS (issue 25697)
Message-ID: <20151122231707.16766.76894@psf.upfronthosting.co.za>

Reviewers: vadmium,

Message:
Thank you for your review Martin.


https://bugs.python.org/review/25697/diff/16019/Misc/ACKS
File Misc/ACKS (left):

https://bugs.python.org/review/25697/diff/16019/Misc/ACKS#oldcode899
Misc/ACKS:899: Tomasz Ma?kowiak
On 2015/11/22 23:48:24, vadmium wrote:
> According to
<https://en.wikipedia.org/wiki/Polish_alphabet#Alphabetical_order>,
> accented ? comes after plain c, so maybe this is better where it is.

Done.



Please review this at https://bugs.python.org/review/25697/

Affected files:
  Misc/ACKS


diff -r fea86d0049d2 Misc/ACKS
--- a/Misc/ACKS	Sun Nov 22 15:18:54 2015 +0100
+++ b/Misc/ACKS	Sun Nov 22 17:41:17 2015 +0200
@@ -50,8 +50,8 @@ Fabrice Aneche
 Juancarlo A?ez
 Chris Angelico
 J?r?my Anger
+Jon Anglin
 Ankur Ankan
-Jon Anglin
 Heidi Annexstad
 Ramchandra Apte
 ?ric Araujo
@@ -173,8 +173,8 @@ Monty Brandenberg
 Georg Brandl
 Christopher Brannon
 Terrence Brannon
+Sven Brauch
 Germ?n M. Bravo
-Sven Brauch
 Erik Bray
 Brian Brazil
 Demian Brecht
@@ -211,6 +211,7 @@ Tarn Weisner Burton
 Lee Busby
 Katherine Busch
 Ralph Butler
+Laurent De Buyst
 Zach Byrne
 Nicolas Cadou
 Jp Calderone
@@ -290,8 +291,8 @@ David M. Cooke
 Jason R. Coombs
 Garrett Cooper
 Greg Copeland
+Ian Cordasco
 Aldo Cortesi
-Ian Cordasco
 David Costanzo
 Scott Cotton
 Greg Couch
@@ -350,6 +351,7 @@ Humberto Diogenes
 Yves Dionne
 Daniel Dittmar
 Josip Djolonga
+Walter D?rwald
 Jaromir Dolecek
 Ismail Donmez
 Robert Donohue
@@ -373,11 +375,10 @@ Virgil Dupras
 Bruno Dupuis
 Andy Dustman
 Gary Duzan
+Eugene Dvurechenski
 Karmen Dykstra
-Eugene Dvurechenski
 Josip Dzolonga
 Maxim Dzumanenko
-Walter D?rwald
 Hans Eckardt
 Rodolpho Eckhardt
 Ulrich Eckhardt
@@ -677,8 +678,8 @@ Flemming Kj?r Jensen
 Philip H. Jensen
 Philip Jenvey
 MunSic Jeong
+Chris Jerdonek
 Joe Jevnik
-Chris Jerdonek
 Jim Jewett
 Pedro Diaz Jimenez
 Orjan Johansen
@@ -766,9 +767,9 @@ Vajrasky Kok
 Guido Kollerie
 Jacek Ko?odziej
 Jacek Konieczny
-???? ?????????
 Arkady Koplyarov
 Peter A. Koren
+???? ?????????
 Vlad Korolev
 Joseph Koshy
 Daniel Kozan
@@ -868,7 +869,9 @@ Everett Lipman
 Mirko Liss
 Nick Lockwood
 Stephanie Lockwood
+Martin von L?wis
 Hugo Lopes Tavares
+Guillermo L?pez-Anglada
 Anne Lord
 Tom Loredo
 Justin Love
@@ -888,15 +891,13 @@ Mark Lutz
 Taras Lyapun
 Jim Lynch
 Mikael Lyngvig
-Martin von L?wis
-Guillermo L?pez-Anglada
 Jeff MacDonald
 John Machin
 Andrew I MacIntyre
 Tim MacKenzie
+Tomasz Ma?kowiak
 Nick Maclaren
 Don MacMillen
-Tomasz Ma?kowiak
 Wolfgang Maier
 Steve Majewski
 Marek Majkowski
@@ -914,9 +915,9 @@ Sven Marnach
 Alex Martelli
 Anthony Martin
 Owen Martin
+Sidney San Mart?n
 Westley Mart?nez
 S?bastien Martini
-Sidney San Mart?n
 Roger Masse
 Nick Mathewson
 Simon Mathieu
@@ -953,16 +954,16 @@ Lucas Prado Melo
 Ezio Melotti
 Doug Mennella
 Brian Merrell
+Alexis M?taireau
 Luke Mewburn
 Carl Meyer
 Mike Meyer
 Piotr Meyer
-Alexis M?taireau
 Steven Miale
-Trent Mick
 Jason Michalski
 Franck Michea
 Vincent Michel
+Trent Mick
 Tom Middleton
 Thomas Miedema
 Stan Mihai
@@ -1063,7 +1064,7 @@ Oleg Oshmyan
 Denis S. Otkidach
 Peter Otten
 Michael Otteneder
-R. M. Oudkerk
+Richard Oudkerk
 Russel Owen
 Joonas Paalasmaa
 Martin Packman
@@ -1072,6 +1073,7 @@ Ondrej Palkovsky
 Mike Pall
 Todd R. Palmer
 Juan David Ib??ez Palomar
+Nicola Palumbo
 Jan Palus
 Yongzhi Pan
 Martin Panter
@@ -1123,8 +1125,8 @@ Anand B. Pillai
 Fran?ois Pinard
 Tom Pinckney
 Zach Pincus
+Michael Piotrowski
 Zero Piraeus
-Michael Piotrowski
 Antoine Pitrou
 Jean-Fran?ois Pi?ronne
 Oleg Plakhotnyuk
@@ -1152,9 +1154,9 @@ Jyrki Pulliainen
 Steve Purcell
 Eduardo P?rez
 Fernando P?rez
+Kevin Jing Qiu
 Pierre Quentel
 Brian Quinlan
-Kevin Jing Qiu
 Anders Qvist
 Thomas Rachel
 Ram Rachum
@@ -1190,9 +1192,9 @@ Antoine Reversat
 Fl?vio Ribeiro
 Francesco Ricciardi
 Tim Rice
+Martin Richard
 Jan Pieter Riegel
 Armin Rigo
-Martin Richard
 Arc Riley
 Nicholas Riley
 Jean-Claude Rimbault
@@ -1224,6 +1226,7 @@ Mark Roseman
 Josh Rosenberg
 Jim Roskind
 Brian Rosner
+Ignacio Rossi
 Guido van Rossum
 Just van Rossum
 Hugo van Rossum
@@ -1269,7 +1272,6 @@ Hugh Sasse
 Bob Savage
 Dave Sawyer
 Ben Sayer
-sbt
 Luca Sbardella
 Marco Scataglini
 Andrew Schaaf
@@ -1310,8 +1312,8 @@ Denis Severson
 Ian Seyer
 Dmitry Shachnev
 Daniel Shahaf
+Mark Shannon
 Ha Shao
-Mark Shannon
 Richard Shapiro
 Varun Sharma
 Vlad Shcherbina
@@ -1511,9 +1513,10 @@ Johannes Vogel
 Michael Vogt
 Radu Voicilas
 Alex Volkov
+Guido Vranken
 Martijn Vries
 Sjoerd de Vries
-Guido Vranken
+Jonas Wagner
 Daniel Wagner-Hall
 Niki W. Waibel
 Wojtek Walczak
@@ -1527,7 +1530,6 @@ Ke Wang
 Greg Ward
 Tom Wardill
 Zachary Ware
-Jonas Wagner
 Barry Warsaw
 Steve Waterbury
 Bob Watson
@@ -1596,8 +1598,8 @@ Doug Wyatt
 Xiang Zhang
 Robert Xiao
 Florent Xicluna
+Arnon Yaari
 Hirokazu Yamamoto
-Arnon Yaari
 Ka-Ping Yee
 Jason Yeo
 EungJun Yi
@@ -1624,7 +1626,4 @@ Tarek Ziad?
 Gennadiy Zlobin
 Doug Zongker
 Peter ?strand
-Ignacio Rossi
-Laurent De Buyst
-Nicola Palumbo
 evilzero



From report at bugs.python.org  Sun Nov 22 19:44:40 2015
From: report at bugs.python.org (Laur Joost)
Date: Mon, 23 Nov 2015 00:44:40 +0000
Subject: [docs] [issue25700] namedtuple documentation
Message-ID: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za>


New submission from Laur Joost:

collections.namedtuple documentation has an example about changing the resulting class docstrings:

  Docstrings can be customized by making direct assignments to the
  ``__doc__`` fields:
  
     >>> Book = namedtuple('Book', ['id', 'title', 'authors'])
     >>> Book.__doc__ += ': Hardcover book in active collection'

This seems to work for the resulting class, but not the field names:

    MsgPacket = namedtuple('MsgPacket', ['sender', 'target', 'sig', 'ser_msg'])
    MsgPacket.__doc__ = '. Message packet format. This is the data added to client queues.'
    MsgPacket.sender.__doc__ = 'Sender public key.'

gives

    Traceback (most recent call last):
      File "C:/UTCloud/UT/DS/S11/server.py", line 42, in <module>
        MsgPacket.sender.__doc__ = 'Sender public key.'
    AttributeError: readonly attribute

----------
assignee: docs at python
components: Documentation
messages: 255121
nosy: Laur Joost, docs at python
priority: normal
severity: normal
status: open
title: namedtuple documentation
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25700>
_______________________________________

From report at bugs.python.org  Sun Nov 22 19:51:40 2015
From: report at bugs.python.org (Laur Joost)
Date: Mon, 23 Nov 2015 00:51:40 +0000
Subject: [docs] [issue25700] namedtuple documentation
In-Reply-To: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za>
Message-ID: <1448239900.52.0.5935426244.issue25700@psf.upfronthosting.co.za>


Laur Joost added the comment:

Did my testing on 3.4.3 (other computer). My apologies.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25700>
_______________________________________

From report at bugs.python.org  Sun Nov 22 21:53:59 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 23 Nov 2015 02:53:59 +0000
Subject: [docs] [issue25700] namedtuple documentation
In-Reply-To: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za>
Message-ID: <1448247239.76.0.0721031346204.issue25700@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I wonder if it's worth a ..versionchanged note in the namedtuple docs pointing out that __doc__ assignment on fields only works in 3.5+ due to property docstrings becoming writable.

----------
nosy: +zach.ware
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25700>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:57:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 06:57:21 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
Message-ID: <1448261841.63.0.685963364339.issue25701@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

tp_setattro and tp_setattr fields of PyTypeObject are used for deleting attributes. In this case the third argument is NULL. This should be documented. Not awareness of this can cause a segmentation fail (for example see issue25698).

----------
assignee: docs at python
components: Documentation
messages: 255130
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document that tp_setattro and tp_setattr are used for deleting attributes
type: crash
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:57:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 06:57:28 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261841.63.0.685963364339.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448261848.63.0.829110386881.issue25701@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:58:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 06:58:04 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
Message-ID: <1448261884.4.0.327784778608.issue25701@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg255130

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:58:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 06:58:24 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
Message-ID: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

tp_setattro and tp_setattr fields of PyTypeObject are used for deleting attributes. In this case the third argument is NULL. This should be documented. Not awareness of this can cause a segmentation fail (for example see issue25691).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Mon Nov 23 01:58:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 06:58:51 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448261931.53.0.0798017573677.issue25701@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Mon Nov 23 08:29:19 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 13:29:19 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
Message-ID: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>


New submission from hiroaki itoh:

* default of ignorechars for a85decode
    b' tnrv' should be b' \t\n\r\v'
* explanation of newline for a85encode
    "newline('n')" should be "newline('\n')"

----------
assignee: docs at python
components: Documentation
messages: 255155
nosy: docs at python, xwhhsprings
priority: normal
severity: normal
status: open
title: problems in library/base64.rst
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 08:32:50 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 13:32:50 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448285570.57.0.0811252765387.issue25706@psf.upfronthosting.co.za>


Changes by hiroaki itoh <xwhhsprings at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 08:33:15 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 13:33:15 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448285595.34.0.612101051495.issue25706@psf.upfronthosting.co.za>


Changes by hiroaki itoh <xwhhsprings at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From airween at gmail.com  Sun Nov 22 12:32:54 2015
From: airween at gmail.com (=?UTF-8?Q?Ervin_Heged=C3=BCs?=)
Date: Sun, 22 Nov 2015 18:32:54 +0100
Subject: [docs] Multiple bugs in email package and documentation - Python 3.4
Message-ID: <CAJ2uXbdV6RgWiuJSNep-u_jbROqviU808Q73Wt1_N=rupMxbVQ@mail.gmail.com>

Hi,

looks like I've found a complex, and connected bug in 'email' package.

Bug 1:
=====

I've read the documentation and examples:

https://docs.python.org/3.4/library/email-examples.html

I've looked up this example (copy and paste, replace the addresses):

https://docs.python.org/3.4/library/email-examples.html#examples-using-the-provisional-api

and this example gives a bug:

(after several lines, the end of the stack is this)

  File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
__str__
    return quote_string(''.join(str(x) for x in self))
  File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
<genexpr>
    return quote_string(''.join(str(x) for x in self))
RuntimeError: maximum recursion depth exceeded while getting the str of an
object

Okay, I've commented out the file write method, in line 50. and 51 - then
script terminated normally.


Bug 2:
=====

I've received the e-mail, but the MIME tree of message is completely wrong.
I think the original author would like to make a html mail
(multipart/alternative), with embedded image. The regular tree of a html
mail is this:

  I     1 <no description>      [multipa/alternativ, 7bit, 0,5K]
  I     2 ??><nodescription>   [text/plain, quoted, utf-8, 0,1K]
  I     3 ??><nodescription>    [text/html, quoted, utf-8, 0,2K]
  I     4 attached_image.png            [image/png, base64, 43K]

but the script in the example gives this tree:

  I     1 <no description>      [multipa/alternativ, 7bit, 101K]
  I     2 ??><no description>    [text/plain, 8bit, utf-8, 0,1K]
  I     3 ??><no description>      [multipa/related, 7bit, 101K]
  I     4   ??><no description> [text/html, quoted, utf-8, 0,3K]
  I     5   ??><no description>       [image/jpeg, base64, 100K]

So, the problem is, in a general MUA (Thunderbird, any webmail client...)
the image is not visible, but mail contains it.


Bug 3:
=====

The attached image is "pseduo" base64 encoded. The encode function is
defined in email/contenmanager.py:

   129  # XXX: This is a cleaned-up version of base64mime.body_encode.  It
would
   130  # be nice to drop both this and quoprimime.body_encode in favor of
   131  # enhanced binascii routines that accepted a max_line_length
parameter.
   132  def _encode_base64(data, max_line_length):
   133      encoded_lines = []
   134      unencoded_bytes_per_line = max_line_length * 3 // 4
   135      for i in range(0, len(data), unencoded_bytes_per_line):
   136          thisline = data[i:i+unencoded_bytes_per_line]
   137
encoded_lines.append(binascii.b2a_base64(thisline).decode('ascii'))
   138      return ''.join(encoded_lines)

But this code generates this form of base64:

--===============8598821442385181731==
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <20151122160934.12051.88999 at myhost.com>
MIME-Version: 1.0
Content-Disposition: inline

/9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA==
BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA==


I don't know, why had been created a new encoder here, because there is the
email/encoders.py module, which contains a correct base64 encoder. With
that, I've got this form (with same image):

--===============6414765018955620772==
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <20151122161400.14276.87008 at myhost.com>
MIME-Version: 1.0
Content-Disposition: inline

/9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA
AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA


I've checked this routine with another MIME tree, where image should be
visible, but the user agent could't show that.

Whit the correct tree and correct encoding, the e-mail visible as
correctly, with inline image.


I don't know, how can I report this connected bugs? I have a good and
working example - but it uses not exactly modules, than in example, however
it builds a correct e-mail message.
(I don't know, what does it mean the "Provisional API" - and what is the
eventual?)


Thanks,


a.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151122/05ced49d/attachment.html>

From stephane at wirtel.be  Sat Nov 21 07:43:57 2015
From: stephane at wirtel.be (stephane at wirtel.be)
Date: Sat, 21 Nov 2015 12:43:57 -0000
Subject: [docs] ftplib docs language fix (issue 25689)
Message-ID: <20151121124357.3529.92002@psf.upfronthosting.co.za>

no comment for this patch, this is clear.

http://bugs.python.org/review/25689/

From report at bugs.python.org  Mon Nov 23 08:36:31 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 13:36:31 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448285791.24.0.932384737348.issue25706@psf.upfronthosting.co.za>


hiroaki itoh added the comment:

maybe this is Sphinx bug.
rst has no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 08:49:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 13:49:36 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448286576.21.0.772039441292.issue25706@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 08:51:44 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 13:51:44 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448286576.19.0.151141842639.issue25706@psf.upfronthosting.co.za>
Message-ID: <20151123135141.GA25726@sg1>


St?phane Wirtel added the comment:

Who can explain the problem ? I am ignorant about this issue.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From lac at openend.se  Mon Nov 23 08:59:34 2015
From: lac at openend.se (Laura Creighton)
Date: Mon, 23 Nov 2015 14:59:34 +0100
Subject: [docs] Multiple bugs in email package and documentation - Python
 3.4 (fwd)
Message-ID: <201511231359.tANDxZX4026489@fido.openend.se>

Thought this would be of interest to those not reading the docs
mailing list.  If all of you already read that list, then I
apologise for wasting your time.

Laura

------- Forwarded Message

From:    Ervin Heged?s <airween at gmail.com>
Subject: [docs] Multiple bugs in email package and documentation - Python 3.4


Hi,

looks like I've found a complex, and connected bug in 'email' package.

Bug 1:
=====

I've read the documentation and examples:

[1]https://docs.python.org/3.4/library/email-examples.html

I've looked up this example (copy and paste, replace the addresses):

[2]https://docs.python.org/3.4/library/email-examples.html#
examples-using-the-provisional-api

and this example gives a bug:

(after several lines, the end of the stack is this)

? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
__str__
??? return quote_string(''.join(str(x) for x in self))
? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
<genexpr>
??? return quote_string(''.join(str(x) for x in self))
RuntimeError: maximum recursion depth exceeded while getting the str of an
object

Okay, I've commented out the file write method, in line 50. and 51 - then
script terminated normally.


Bug 2:
=====

I've received the e-mail, but the MIME tree of message is completely wrong. I
think the original author would like to make a html mail (multipart/
alternative), with embedded image. The regular tree of a html mail is this:

? I???? 1 <no description>????? [multipa/alternativ, 7bit, 0,5K]
? I???? 2 ??><nodescription>?? [text/plain, quoted, utf-8, 0,1K]
? I???? 3 ??><nodescription>??? [text/html, quoted, utf-8, 0,2K]
? I???? 4 attached_image.png??????????? [image/png, base64, 43K]

but the script in the example gives this tree:

? I???? 1 <no description>????? [multipa/alternativ, 7bit, 101K]
? I???? 2 ??><no description>??? [text/plain, 8bit, utf-8, 0,1K]
? I???? 3 ??><no description>????? [multipa/related, 7bit, 101K]
? I???? 4?? ??><no description> [text/html, quoted, utf-8, 0,3K]
? I???? 5?? ??><no description>?????? [image/jpeg, base64, 100K]

So, the problem is, in a general MUA (Thunderbird, any webmail client...) the
image is not visible, but mail contains it.


Bug 3:
=====

The attached image is "pseduo" base64 encoded. The encode function is defined
in email/contenmanager.py:

?? 129? # XXX: This is a cleaned-up version of base64mime.body_encode.? It
would
?? 130? # be nice to drop both this and quoprimime.body_encode in favor of
?? 131? # enhanced binascii routines that accepted a max_line_length
parameter.
?? 132? def _encode_base64(data, max_line_length):
?? 133????? encoded_lines = []
?? 134????? unencoded_bytes_per_line = max_line_length * 3 // 4
?? 135????? for i in range(0, len(data), unencoded_bytes_per_line):
?? 136????????? thisline = data[i:i+unencoded_bytes_per_line]
?? 137????????? encoded_lines.append(binascii.b2a_base64(thisline).decode
('ascii'))
?? 138????? return ''.join(encoded_lines)

But this code generates this form of base64:

--===============8598821442385181731==
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <[3]20151122160934.12051.88999 at myhost.com>
MIME-Version: 1.0
Content-Disposition: inline

/9j/
4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA==
BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA
==


I don't know, why had been created a new encoder here, because there is the
email/encoders.py module, which contains a correct base64 encoder. With that,
I've got this form (with same image):

--===============6414765018955620772==
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <[4]20151122161400.14276.87008 at myhost.com>
MIME-Version: 1.0
Content-Disposition: inline

/9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA
AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA


I've checked this routine with another MIME tree, where image should be
visible, but the user agent could't show that.

Whit the correct tree and correct encoding, the e-mail visible as correctly,
with inline image.


I don't know, how can I report this connected bugs? I have a good and working
example - but it uses not exactly modules, than in example, however it builds
a correct e-mail message.
(I don't know, what does it mean the "Provisional API" - and what is the
eventual?)


Thanks,


a.

References:

[1] https://docs.python.org/3.4/library/email-examples.html
[2] https://docs.python.org/3.4/library/email-examples.html#examples-using-the-p
rovisional-api
[3] mailto:20151122160934.12051.88999 at myhost.com
[4] mailto:20151122161400.14276.87008 at myhost.com
_______________________________________________
docs mailing list
docs at python.org
https://mail.python.org/mailman/listinfo/docs
lac at fido:~/Mail/webmaster$ show
show
(Message inbox:4120)
Date:    Sun, 22 Nov 2015 18:32:54 +0100
To:      docs at python.org
From:    Ervin Heged?s <airween at gmail.com>
Subject: [docs] Multiple bugs in email package and documentation - Python 3.4


Hi,

looks like I've found a complex, and connected bug in 'email' package.

Bug 1:
=====

I've read the documentation and examples:

[1]https://docs.python.org/3.4/library/email-examples.html

I've looked up this example (copy and paste, replace the addresses):

[2]https://docs.python.org/3.4/library/email-examples.html#
examples-using-the-provisional-api

and this example gives a bug:

(after several lines, the end of the stack is this)

? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
__str__
??? return quote_string(''.join(str(x) for x in self))
? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
<genexpr>
??? return quote_string(''.join(str(x) for x in self))
RuntimeError: maximum recursion depth exceeded while getting the str of an
object

Okay, I've commented out the file write method, in line 50. and 51 - then
script terminated normally.


Bug 2:
=====

I've received the e-mail, but the MIME tree of message is completely wrong. I
think the original author would like to make a html mail (multipart/
alternative), with embedded image. The regular tree of a html mail is this:

? I???? 1 <no description>????? [multipa/alternativ, 7bit, 0,5K]
? I???? 2 ??><nodescription>?? [text/plain, quoted, utf-8, 0,1K]
? I???? 3 ??><nodescription>??? [text/html, quoted, utf-8, 0,2K]
? I???? 4 attached_image.png??????????? [image/png, base64, 43K]

but the script in the example gives this tree:

? I???? 1 <no description>????? [multipa/alternativ, 7bit, 101K]
? I???? 2 ??><no description>??? [text/plain, 8bit, utf-8, 0,1K]
? I???? 3 ??><no description>????? [multipa/related, 7bit, 101K]
? I???? 4?? ??><no description> [text/html, quoted, utf-8, 0,3K]
? I???? 5?? ??><no description>?????? [image/jpeg, base64, 100K]

So, the problem is, in a general MUA (Thunderbird, any webmail client...) the
image is not visible, but mail contains it.


Bug 3:
=====

The attached image is "pseduo" base64 encoded. The encode function is defined
in email/contenmanager.py:

?? 129? # XXX: This is a cleaned-up version of base64mime.body_encode.? It
would
?? 130? # be nice to drop both this and quoprimime.body_encode in favor of
?? 131? # enhanced binascii routines that accepted a max_line_length
parameter.
?? 132? def _encode_base64(data, max_line_length):
?? 133????? encoded_lines = []
?? 134????? unencoded_bytes_per_line = max_line_length * 3 // 4
?? 135????? for i in range(0, len(data), unencoded_bytes_per_line):
?? 136????????? thisline = data[i:i+unencoded_bytes_per_line]
?? 137????????? encoded_lines.append(binascii.b2a_base64(thisline).decode
('ascii'))
?? 138????? return ''.join(encoded_lines)

But this code generates this form of base64:

--===============8598821442385181731==
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <[3]20151122160934.12051.88999 at myhost.com>
MIME-Version: 1.0
Content-Disposition: inline

/9j/
4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA==
BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA
==


I don't know, why had been created a new encoder here, because there is the
email/encoders.py module, which contains a correct base64 encoder. With that,
I've got this form (with same image):

--===============6414765018955620772==
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <[4]20151122161400.14276.87008 at myhost.com>
MIME-Version: 1.0
Content-Disposition: inline

/9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA
AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA


I've checked this routine with another MIME tree, where image should be
visible, but the user agent could't show that.

Whit the correct tree and correct encoding, the e-mail visible as correctly,
with inline image.


I don't know, how can I report this connected bugs? I have a good and working
example - but it uses not exactly modules, than in example, however it builds
a correct e-mail message.
(I don't know, what does it mean the "Provisional API" - and what is the
eventual?)


Thanks,


a.

References:

[1] https://docs.python.org/3.4/library/email-examples.html
[2] https://docs.python.org/3.4/library/email-examples.html#examples-using-the-p
rovisional-api
[3] mailto:20151122160934.12051.88999 at myhost.com
[4] mailto:20151122161400.14276.87008 at myhost.com
_______________________________________________
docs mailing list
docs at python.org
https://mail.python.org/mailman/listinfo/docs


------- End of Forwarded Message

From lac at openend.se  Mon Nov 23 09:04:22 2015
From: lac at openend.se (Laura Creighton)
Date: Mon, 23 Nov 2015 15:04:22 +0100
Subject: [docs] Multiple bugs in email package and documentation -
 Python 3.4 (fwd)
In-Reply-To: <201511231359.tANDxZX4026489@fido.openend.se>
References: <201511231359.tANDxZX4026489@fido.openend.se>
Message-ID: <201511231404.tANE4Mht027052@fido.openend.se>

And I seem to have forwarded the message to you twice. In one forward.
That was my bad.  Sorry.

Laura

From report at bugs.python.org  Mon Nov 23 09:07:19 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 14:07:19 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1448229202.17.0.607837184501.issue4744@psf.upfronthosting.co.za>
Message-ID: <20151123140716.GB15060@sg1>


St?phane Wirtel added the comment:

Hi Martin,

About the patch of Nikita, I am going to rewrite it asap.

Will you have time to check it ?

Thanks
-- 
St?phane Wirtel - http://wirtel.be - @matrixise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 09:11:55 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 14:11:55 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448287915.46.0.153027430279.issue25706@psf.upfronthosting.co.za>


hiroaki itoh added the comment:

Should be escape by '\\t\\b...' in rst?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 09:15:15 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Mon, 23 Nov 2015 14:15:15 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448288115.35.0.573402145675.issue25706@psf.upfronthosting.co.za>


hiroaki itoh added the comment:

escape*d*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 09:46:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Nov 2015 14:46:15 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <20151123144612.3550.38341@psf.io>


Roundup Robot added the comment:

New changeset a33d76465a18 by Serhiy Storchaka in branch '3.4':
Issue #25706: Fixed markup in the documentation.
https://hg.python.org/cpython/rev/a33d76465a18

New changeset f4918e98d085 by Serhiy Storchaka in branch '3.5':
Issue #25706: Fixed markup in the documentation.
https://hg.python.org/cpython/rev/f4918e98d085

New changeset ebec1a98ab81 by Serhiy Storchaka in branch 'default':
Issue #25706: Fixed markup in the documentation.
https://hg.python.org/cpython/rev/ebec1a98ab81

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 09:54:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 14:54:09 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za>
Message-ID: <1448290449.34.0.0105312799202.issue25706@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your report hiroaki itoh. Fixed yet one error in Doc/library/stdtypes.rst.

St?phane, the backslash hes special meaning in rst files if not escaped.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 10:24:50 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 15:24:50 +0000
Subject: [docs] [issue25706] problems in library/base64.rst
In-Reply-To: <1448290449.34.0.0105312799202.issue25706@psf.upfronthosting.co.za>
Message-ID: <20151123152447.GC15060@sg1>


St?phane Wirtel added the comment:

Thanks for your explanation, Serhiy.

Now, I know how to fix this kind of issues.

On 11/23, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Thank you for your report hiroaki itoh. Fixed yet one error in Doc/library/stdtypes.rst.
> 
> St?phane, the backslash hes special meaning in rst files if not escaped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25706>
_______________________________________

From report at bugs.python.org  Mon Nov 23 10:51:42 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 23 Nov 2015 15:51:42 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1448293902.48.0.524163905655.issue4744@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Does it make sense to spend time updating the asychat docs when https://docs.python.org/3/library/asynchat.html states "Note. This module exists for backwards compatibility only. For new code we recommend using asyncio."?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:34:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2015 16:34:56 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1448296496.11.0.352337152221.issue4744@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes.  The docs should be accurate, even if the module is deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:38:16 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 16:38:16 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1448296496.11.0.352337152221.issue4744@psf.upfronthosting.co.za>
Message-ID: <20151123163814.GE15060@sg1>


St?phane Wirtel added the comment:

Ok, in this case, I will provide the patch 

On 11/23, R. David Murray wrote:
> 
> R. David Murray added the comment:
> 
> Yes.  The docs should be accurate, even if the module is deprecated.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4744>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/stephane%40wirtel.be
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:44:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2015 16:44:54 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <1448297094.45.0.206873826506.issue25697@psf.upfronthosting.co.za>


R. David Murray added the comment:

It says "rough" for a reason.  The ascii-only changes are probably fine, but the non-ascii ones may not be (MvL in particular caught my eye, but there was another) may be correct as they stand since those two were consistent (at the end of the alphabet).  I don't know, though; I don't know the alphabetization rules for the non-ascii names.

In short, it is better to leave the non-ascii names alone unless you are sure of the sorting rules of the native language of the individual involved :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Mon Nov 23 11:52:01 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 16:52:01 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <20151123163814.GE15060@sg1>
Message-ID: <20151123165159.GG15060@sg1>


St?phane Wirtel added the comment:

Martin, About the patch of Nikita, this one has already been applied. I have
checked the source.

David, maybe we should close this issue. And open a new one if we find
an other issue in the documentation.

What do you suggest? Should I continue on this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 12:04:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Nov 2015 17:04:43 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <1448298283.72.0.468989826772.issue25697@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As Georg Brandl said in msg197962, "L?wis" should be sorted as "Loewis" according to German rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Mon Nov 23 12:18:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2015 17:18:25 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1448299105.51.0.853124848524.issue4744@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you've read through the asynchat docs and don't think any of the other mentions of string are incorrect or ambiguous, then we should close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 12:19:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2015 17:19:27 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <1448299167.81.0.317027479091.issue25697@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would be being sure, then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Mon Nov 23 12:45:06 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 23 Nov 2015 17:45:06 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1448299105.51.0.853124848524.issue4744@psf.upfronthosting.co.za>
Message-ID: <20151123174503.GB23241@sg1>


St?phane Wirtel added the comment:

For my part, you can close this issue. I have read the asynchat.rst and
asynchat.py files and think the rest of the documentation is clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 15:38:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Nov 2015 20:38:37 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1448311117.63.0.796544408751.issue4744@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, let's close it then.  If someone finds something wrong they can open a new issue.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4744>
_______________________________________

From report at bugs.python.org  Mon Nov 23 16:36:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Nov 2015 21:36:42 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <1448314602.19.0.293595810886.issue25697@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW when I said it was okay apart from Ma?kowiak, I guessed the accented letters were in German, Spanish, French and Polish alphabets. According to Wikipedia, sometimes the German ??? (umlaut) is put after Z, but sorting with ?oe? is also done, and I think it is better that way :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Mon Nov 23 18:06:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Nov 2015 23:06:22 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448319982.56.0.178140530489.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch. The same problem happens with getset descriptors:

>>> del sys.stdout._CHUNK_SIZE
SystemError: null argument to internal routine

So I also changed the documentation for ?setter? descriptor functions and the tp_descr_set() method.

I only looked at the Python 3 implementation, and I understand Python 2 objects work differently in some cases, so I?m not sure if my changes are apropriate for Python 2.

----------
keywords: +patch
nosy: +martin.panter
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41143/setattr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Tue Nov 24 01:19:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Nov 2015 06:19:23 +0000
Subject: [docs] [issue25700] namedtuple documentation
In-Reply-To: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za>
Message-ID: <20151124061919.648.54889@psf.io>


Roundup Robot added the comment:

New changeset f611e2244c69 by Raymond Hettinger in branch '3.5':
Issue #25700: Clarify that namedtuple property docstrings became writeable in 3.5
https://hg.python.org/cpython/rev/f611e2244c69

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25700>
_______________________________________

From report at bugs.python.org  Tue Nov 24 13:55:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Nov 2015 18:55:28 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448391328.69.0.699158735144.issue25701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin. In general the patch LGTM, but I'm not expert in English writing.

There are other functions and slots with twofold purpose: PyObject_SetItem, PySequence_SetItem, PySequence_SetSlice, PyMapping_SetItemString, PySequenceMethods.sq_ass_item, PyMappingMethods.mp_ass_subscript. May be address them in this issue?

I'm not sure about documenting the deletion for PyObject_SetAttr and like. All these functions have Del-counterpart. Deleting by Set-function with NULL may be a side effect and be deprecated in future. May be worth to discuss this on Python-Dev.

For PySys_SetObject the deletion if value is NULL already is documented, but there is no PySys_DelObject.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Tue Nov 24 16:04:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Nov 2015 21:04:06 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448399046.71.0.824985145053.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree it might be safer not to document that PyObject_SetAttr etc can delete (move that change to the tp_setattro etc method slot). I?ll also review the other functions you mentioned when I get a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:07:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Nov 2015 23:07:24 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>
Message-ID: <20151124230720.29819.62271@psf.io>


Roundup Robot added the comment:

New changeset 16fec577fd8b by Martin Panter in branch '3.4':
Issue #25576: Remove application/x-www-form-urlencoded charset advice
https://hg.python.org/cpython/rev/16fec577fd8b

New changeset 95ae5262d27c by Martin Panter in branch '3.5':
Issue #25576: Merge www-form-urlencoded doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/95ae5262d27c

New changeset d52521d13a64 by Martin Panter in branch 'default':
Issue #25576: Merge www-form-urlencoded doc from 3.5
https://hg.python.org/cpython/rev/d52521d13a64

New changeset 671429cc1d96 by Martin Panter in branch 'default':
Issue #25576: Apply fix to new urlopen() doc string
https://hg.python.org/cpython/rev/671429cc1d96

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:37:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 Nov 2015 23:37:00 +0000
Subject: [docs] [issue20923] ConfigParser should nested [] in section names.
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1448408220.9.0.150519052999.issue20923@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Discussion continues because my close message was, I now realize, incomplete and therefore unsatisfying.  Ditto for the doc.  So I complete my close message here and reopen issue to augment the doc.

The discussion has so far has glossed over the key question: "What is a legal section name?"  Pulling the answer from the doc was a challenge. It uses 'legal section name', once, as if one should already know. Reading further, I found the answer: there is no (fixed) answer!

The legal section name for a particular parser is determined by its .SECTCRE class attribute.
'''configparser.SECTCRE
    A compiled regular expression used to parse section headers. The default matches [section] to the name "section".'''  (This neglects to say whether the closing ']' is the first or last ']' on the line after the opening '['.) A non-verbose version of the default is
re.compile(r"\[(?P<header>[^]]+)\]").

I propose adding near the top of the doc:
"By default, a legal section name can be any string that does not contain '\n' or ']'.  To change this, see configparser.SECTCRE."

So my response to Milo? should have been to set SECTCRE to something like p below.

>>> p = re.compile(r"\[(?P<header>.*)\]")
>>> m = p.search("[Test[2]_foo]")
>>> m.group('header')
'Test[2]_foo'

Additional note: Postel's principle was formulated for internet protocols, which .ini files are not.  In any case, it is not a Python design principle.  Neither is "always check user input", which amounts to 'look before you leap'.  So I will not debate these. However, "Errors should never pass silently." is #10 on the Zen of Python ('import this') and that I do attend to.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution: rejected -> 
stage: test needed -> needs patch
status: closed -> open
versions: +Python 2.7, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Tue Nov 24 18:38:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Nov 2015 23:38:26 +0000
Subject: [docs] =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A?=
 =?utf-8?q?_application/x-www-form-urlencoded=3B_charset=E2=80=9D_advice?=
In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za>
Message-ID: <1448408306.51.0.417440759302.issue25576@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25576>
_______________________________________

From report at bugs.python.org  Tue Nov 24 21:24:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 Nov 2015 02:24:57 +0000
Subject: [docs] [issue10796] Improve doc for readline.set_completer_delims()
In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>
Message-ID: <1448418297.46.0.274935488516.issue10796@psf.upfronthosting.co.za>


Martin Panter added the comment:

I propose to address this with the general documentation bug, Issue 6953

----------
dependencies: +readline documenation needs work
nosy: +martin.panter
title: readline completion flaw -> Improve doc for readline.set_completer_delims()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10796>
_______________________________________

From report at bugs.python.org  Wed Nov 25 02:59:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Nov 2015 07:59:57 +0000
Subject: [docs] [issue20923] ConfigParser should nested [] in section names.
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1448438397.88.0.780007780961.issue20923@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It would be good if ConfigParser supported angled brackets in section names by being greedy when parsing.

I agree with Terry, it's the opposite: we must explicitly reject them to be compatible with other applications. Please move the discussion to issue #25723.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20923>
_______________________________________

From ezalilov94 at gmail.com  Mon Nov 23 15:43:10 2015
From: ezalilov94 at gmail.com (Clark Kent)
Date: Mon, 23 Nov 2015 23:43:10 +0300
Subject: [docs] (no subject)
Message-ID: <CAHOp6-kJpsou0etuMzFU7gPVEbMQxsOYWoKgdNdbWHRyb27=Uw@mail.gmail.com>

not work downloads links
error 404 not found
https://docs.python.org/3/download.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151123/0d9aa021/attachment.html>

From mtofsted at hotmail.com  Mon Nov 23 11:03:04 2015
From: mtofsted at hotmail.com (Marc Tofsted)
Date: Mon, 23 Nov 2015 09:03:04 -0700
Subject: [docs] Docs.python.org/3/download.html no-go
Message-ID: <BLU436-SMTP16AA7D86E430D6C4A78E02D9070@phx.gbl>

Gentlemen,

None of the links on this page are working today. 

Thanks for your help.  

Marc Tofsted 

From rdmurray at bitdance.com  Mon Nov 23 10:52:14 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 23 Nov 2015 10:52:14 -0500
Subject: [docs] [Roto Rooters] Multiple bugs in email package and
 documentation - Python 3.4 (fwd)
In-Reply-To: <201511231359.tANDxZX4026489@fido.openend.se>
References: <201511231359.tANDxZX4026489@fido.openend.se>
Message-ID: <20151123155215.6BF17B140A1@webabinitio.net>

The first bug has already been reported.  I just need to get around to
addressing it :(.

The report should be posted to bugs.python.org, otherwise it is unlikely
to get addressed.  It looks to be several bugs with one reproducer,
but it's fine to start with just a bug report with the reproducer and
a description of the issues encountered.

Ervin: FYI the api being provisional means it is not yet subject to our
full backward compatibility policies.  The current plan is for it to become
so in 3.6 (to no longer be provisional).  Obviously whatever these
issues are they should be dealt with before then :)

--David

On Mon, 23 Nov 2015 14:59:34 +0100, Laura Creighton <lac at openend.se> wrote:
> Thought this would be of interest to those not reading the docs
> mailing list.  If all of you already read that list, then I
> apologise for wasting your time.
> 
> Laura
> 
> ------- Forwarded Message
> 
> From:    Ervin Heged??s <airween at gmail.com>
> Subject: [docs] Multiple bugs in email package and documentation - Python 3.4
> 
> 
> Hi,
> 
> looks like I've found a complex, and connected bug in 'email' package.
> 
> Bug 1:
> =====
> 
> I've read the documentation and examples:
> 
> [1]https://docs.python.org/3.4/library/email-examples.html
> 
> I've looked up this example (copy and paste, replace the addresses):
> 
> [2]https://docs.python.org/3.4/library/email-examples.html#
> examples-using-the-provisional-api
> 
> and this example gives a bug:
> 
> (after several lines, the end of the stack is this)
> 
> ?? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
> __str__
> ?????? return quote_string(''.join(str(x) for x in self))
> ?? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
> <genexpr>
> ?????? return quote_string(''.join(str(x) for x in self))
> RuntimeError: maximum recursion depth exceeded while getting the str of an
> object
> 
> Okay, I've commented out the file write method, in line 50. and 51 - then
> script terminated normally.
> 
> 
> Bug 2:
> =====
> 
> I've received the e-mail, but the MIME tree of message is completely wrong. I
> think the original author would like to make a html mail (multipart/
> alternative), with embedded image. The regular tree of a html mail is this:
> 
> ?? I???????? 1 <no description>?????????? [multipa/alternativ, 7bit, 0,5K]
> ?? I???????? 2 ??????><nodescription>???? [text/plain, quoted, utf-8, 0,1K]
> ?? I???????? 3 ??????><nodescription>?????? [text/html, quoted, utf-8, 0,2K]
> ?? I???????? 4 attached_image.png?????????????????????? [image/png, base64, 43K]
> 
> but the script in the example gives this tree:
> 
> ?? I???????? 1 <no description>?????????? [multipa/alternativ, 7bit, 101K]
> ?? I???????? 2 ??????><no description>?????? [text/plain, 8bit, utf-8, 0,1K]
> ?? I???????? 3 ??????><no description>?????????? [multipa/related, 7bit, 101K]
> ?? I???????? 4???? ??????><no description> [text/html, quoted, utf-8, 0,3K]
> ?? I???????? 5???? ??????><no description>???????????? [image/jpeg, base64, 100K]
> 
> So, the problem is, in a general MUA (Thunderbird, any webmail client...) the
> image is not visible, but mail contains it.
> 
> 
> Bug 3:
> =====
> 
> The attached image is "pseduo" base64 encoded. The encode function is defined
> in email/contenmanager.py:
> 
> ???? 129?? # XXX: This is a cleaned-up version of base64mime.body_encode.?? It
> would
> ???? 130?? # be nice to drop both this and quoprimime.body_encode in favor of
> ???? 131?? # enhanced binascii routines that accepted a max_line_length
> parameter.
> ???? 132?? def _encode_base64(data, max_line_length):
> ???? 133?????????? encoded_lines = []
> ???? 134?????????? unencoded_bytes_per_line = max_line_length * 3 // 4
> ???? 135?????????? for i in range(0, len(data), unencoded_bytes_per_line):
> ???? 136?????????????????? thisline = data[i:i+unencoded_bytes_per_line]
> ???? 137?????????????????? encoded_lines.append(binascii.b2a_base64(thisline).decode
> ('ascii'))
> ???? 138?????????? return ''.join(encoded_lines)
> 
> But this code generates this form of base64:
> 
> --===============8598821442385181731==
> Content-Type: image/jpeg
> Content-Transfer-Encoding: base64
> Content-ID: <[3]20151122160934.12051.88999 at myhost.com>
> MIME-Version: 1.0
> Content-Disposition: inline
> 
> /9j/
> 4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA==
> BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA
> ==
> 
> 
> I don't know, why had been created a new encoder here, because there is the
> email/encoders.py module, which contains a correct base64 encoder. With that,
> I've got this form (with same image):
> 
> --===============6414765018955620772==
> Content-Type: image/jpeg
> Content-Transfer-Encoding: base64
> Content-ID: <[4]20151122161400.14276.87008 at myhost.com>
> MIME-Version: 1.0
> Content-Disposition: inline
> 
> /9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA
> AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA
> 
> 
> I've checked this routine with another MIME tree, where image should be
> visible, but the user agent could't show that.
> 
> Whit the correct tree and correct encoding, the e-mail visible as correctly,
> with inline image.
> 
> 
> I don't know, how can I report this connected bugs? I have a good and working
> example - but it uses not exactly modules, than in example, however it builds
> a correct e-mail message.
> (I don't know, what does it mean the "Provisional API" - and what is the
> eventual?)
> 
> 
> Thanks,
> 
> 
> a.
> 
> References:
> 
> [1] https://docs.python.org/3.4/library/email-examples.html
> [2] https://docs.python.org/3.4/library/email-examples.html#examples-using-the-p
> rovisional-api
> [3] mailto:20151122160934.12051.88999 at myhost.com
> [4] mailto:20151122161400.14276.87008 at myhost.com
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
> lac at fido:~/Mail/webmaster$ show
> show
> (Message inbox:4120)
> Date:    Sun, 22 Nov 2015 18:32:54 +0100
> To:      docs at python.org
> From:    Ervin Heged??s <airween at gmail.com>
> Subject: [docs] Multiple bugs in email package and documentation - Python 3.4
> 
> 
> Hi,
> 
> looks like I've found a complex, and connected bug in 'email' package.
> 
> Bug 1:
> =====
> 
> I've read the documentation and examples:
> 
> [1]https://docs.python.org/3.4/library/email-examples.html
> 
> I've looked up this example (copy and paste, replace the addresses):
> 
> [2]https://docs.python.org/3.4/library/email-examples.html#
> examples-using-the-provisional-api
> 
> and this example gives a bug:
> 
> (after several lines, the end of the stack is this)
> 
> ?? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
> __str__
> ?????? return quote_string(''.join(str(x) for x in self))
> ?? File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in
> <genexpr>
> ?????? return quote_string(''.join(str(x) for x in self))
> RuntimeError: maximum recursion depth exceeded while getting the str of an
> object
> 
> Okay, I've commented out the file write method, in line 50. and 51 - then
> script terminated normally.
> 
> 
> Bug 2:
> =====
> 
> I've received the e-mail, but the MIME tree of message is completely wrong. I
> think the original author would like to make a html mail (multipart/
> alternative), with embedded image. The regular tree of a html mail is this:
> 
> ?? I???????? 1 <no description>?????????? [multipa/alternativ, 7bit, 0,5K]
> ?? I???????? 2 ??????><nodescription>???? [text/plain, quoted, utf-8, 0,1K]
> ?? I???????? 3 ??????><nodescription>?????? [text/html, quoted, utf-8, 0,2K]
> ?? I???????? 4 attached_image.png?????????????????????? [image/png, base64, 43K]
> 
> but the script in the example gives this tree:
> 
> ?? I???????? 1 <no description>?????????? [multipa/alternativ, 7bit, 101K]
> ?? I???????? 2 ??????><no description>?????? [text/plain, 8bit, utf-8, 0,1K]
> ?? I???????? 3 ??????><no description>?????????? [multipa/related, 7bit, 101K]
> ?? I???????? 4???? ??????><no description> [text/html, quoted, utf-8, 0,3K]
> ?? I???????? 5???? ??????><no description>???????????? [image/jpeg, base64, 100K]
> 
> So, the problem is, in a general MUA (Thunderbird, any webmail client...) the
> image is not visible, but mail contains it.
> 
> 
> Bug 3:
> =====
> 
> The attached image is "pseduo" base64 encoded. The encode function is defined
> in email/contenmanager.py:
> 
> ???? 129?? # XXX: This is a cleaned-up version of base64mime.body_encode.?? It
> would
> ???? 130?? # be nice to drop both this and quoprimime.body_encode in favor of
> ???? 131?? # enhanced binascii routines that accepted a max_line_length
> parameter.
> ???? 132?? def _encode_base64(data, max_line_length):
> ???? 133?????????? encoded_lines = []
> ???? 134?????????? unencoded_bytes_per_line = max_line_length * 3 // 4
> ???? 135?????????? for i in range(0, len(data), unencoded_bytes_per_line):
> ???? 136?????????????????? thisline = data[i:i+unencoded_bytes_per_line]
> ???? 137?????????????????? encoded_lines.append(binascii.b2a_base64(thisline).decode
> ('ascii'))
> ???? 138?????????? return ''.join(encoded_lines)
> 
> But this code generates this form of base64:
> 
> --===============8598821442385181731==
> Content-Type: image/jpeg
> Content-Transfer-Encoding: base64
> Content-ID: <[3]20151122160934.12051.88999 at myhost.com>
> MIME-Version: 1.0
> Content-Disposition: inline
> 
> /9j/
> 4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA==
> BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA
> ==
> 
> 
> I don't know, why had been created a new encoder here, because there is the
> email/encoders.py module, which contains a correct base64 encoder. With that,
> I've got this form (with same image):
> 
> --===============6414765018955620772==
> Content-Type: image/jpeg
> Content-Transfer-Encoding: base64
> Content-ID: <[4]20151122161400.14276.87008 at myhost.com>
> MIME-Version: 1.0
> Content-Disposition: inline
> 
> /9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA
> AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA
> 
> 
> I've checked this routine with another MIME tree, where image should be
> visible, but the user agent could't show that.
> 
> Whit the correct tree and correct encoding, the e-mail visible as correctly,
> with inline image.
> 
> 
> I don't know, how can I report this connected bugs? I have a good and working
> example - but it uses not exactly modules, than in example, however it builds
> a correct e-mail message.
> (I don't know, what does it mean the "Provisional API" - and what is the
> eventual?)
> 
> 
> Thanks,
> 
> 
> a.
> 
> References:
> 
> [1] https://docs.python.org/3.4/library/email-examples.html
> [2] https://docs.python.org/3.4/library/email-examples.html#examples-using-the-p
> rovisional-api
> [3] mailto:20151122160934.12051.88999 at myhost.com
> [4] mailto:20151122161400.14276.87008 at myhost.com
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
> 
> 
> ------- End of Forwarded Message
> _______________________________________________
> Roto-Rooters mailing list
> Roto-Rooters at wooz.org
> Your options: http://www.wooz.org/mailman/options/roto-rooters/rdmurray%40bitdance.com
> Subscribed as: rdmurray at bitdance.com

From victor.stinner at gmail.com  Wed Nov 25 04:54:34 2015
From: victor.stinner at gmail.com (victor.stinner at gmail.com)
Date: Wed, 25 Nov 2015 09:54:34 -0000
Subject: [docs] Document that tp_setattro and tp_setattr are used for
 deleting attributes (issue 25701)
Message-ID: <20151125095434.12758.61812@psf.upfronthosting.co.za>


http://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst
File Doc/c-api/object.rst (right):

http://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst#newcode72
Doc/c-api/object.rst:72: otherwise set it to *v* (``o.attr_name = v``).
Returns ``-1`` on failure.
I know that it's not a common Python doc, but I prefer to explicitly say
that an exception is raised in case of error. I suggest:

Raise an exception and returns -1 on failure, return 0 on success.

(Same change for other functions below)

http://bugs.python.org/review/25701/diff/16034/Include/abstract.h
File Include/abstract.h (right):

http://bugs.python.org/review/25701/diff/16034/Include/abstract.h#newcode196
Include/abstract.h:196: (o.attr_name=v). Returns -1 on failure.
Raise an exception and returns -1 on failure, return 0 on success.

http://bugs.python.org/review/25701/

From report at bugs.python.org  Wed Nov 25 06:00:00 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Nov 2015 11:00:00 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448449200.85.0.80452309254.issue25730@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ezio.melotti, georg.brandl, terry.reedy
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Wed Nov 25 06:14:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Nov 2015 11:14:36 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448450076.03.0.822217500855.issue25701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python-Dev discussion:

http://comments.gmane.org/gmane.comp.python.devel/155474

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From lac at openend.se  Wed Nov 25 06:45:41 2015
From: lac at openend.se (Laura Creighton)
Date: Wed, 25 Nov 2015 12:45:41 +0100
Subject: [docs] Docs.python.org/3/download.html no-go
In-Reply-To: <BLU436-SMTP16AA7D86E430D6C4A78E02D9070@phx.gbl>
References: <BLU436-SMTP16AA7D86E430D6C4A78E02D9070@phx.gbl>
Message-ID: <201511251145.tAPBjfGe016682@fido.openend.se>

In a message of Mon, 23 Nov 2015 09:03:04 -0700, Marc Tofsted writes:
>Gentlemen,
>
>None of the links on this page are working today. 
>
>Thanks for your help.  
>
>Marc Tofsted 

They work for me.  Are they still not working for the two of you?

Laura Creighton
(not a 'Gentleman', but still willing to track down the problem if it
persists)


From report at bugs.python.org  Wed Nov 25 09:14:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Nov 2015 14:14:30 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <20151125141421.13413.24609@psf.io>


Roundup Robot added the comment:

New changeset 68c7c6ac82d9 by Serhiy Storchaka in branch '3.4':
Issue #25697: Fixed rough alphabetical order in Misc/ACKS.
https://hg.python.org/cpython/rev/68c7c6ac82d9

New changeset 9925fb41c1d9 by Serhiy Storchaka in branch '3.5':
Issue #25697: Fixed rough alphabetical order in Misc/ACKS.
https://hg.python.org/cpython/rev/9925fb41c1d9

New changeset e61a864b703c by Serhiy Storchaka in branch 'default':
Issue #25697: Fixed rough alphabetical order in Misc/ACKS.
https://hg.python.org/cpython/rev/e61a864b703c

New changeset 8bdf8e7dd085 by Serhiy Storchaka in branch '2.7':
Issue #25697: Fixed rough alphabetical order in Misc/ACKS.
https://hg.python.org/cpython/rev/8bdf8e7dd085

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Wed Nov 25 09:17:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Nov 2015 14:17:06 +0000
Subject: [docs] [issue25697] Fix rough alphabetical order in Misc/ACKS
In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za>
Message-ID: <1448461026.21.0.306691424403.issue25697@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25697>
_______________________________________

From report at bugs.python.org  Wed Nov 25 09:44:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Nov 2015 14:44:08 +0000
Subject: [docs] [issue25732] functools.total_ordering does not correctly
 implement not equal behaviour
In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za>
Message-ID: <1448462648.14.0.667146312599.issue25732@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25732>
_______________________________________

From report at bugs.python.org  Wed Nov 25 12:26:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Nov 2015 17:26:25 +0000
Subject: [docs] [issue20923] ConfigParser should nested [] in section names.
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1448472384.97.0.0544069682988.issue20923@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Victor, I reopened this a a doc issue to add the sentence that would have cut short the discussion.  Please leave it.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Wed Nov 25 12:28:59 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Nov 2015 17:28:59 +0000
Subject: [docs] [issue20923] ConfigParser should nested [] in section names.
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1448472539.06.0.309872018039.issue20923@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: docs at python -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Wed Nov 25 12:31:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Nov 2015 17:31:23 +0000
Subject: [docs] [issue20923] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1448472683.54.0.178537349674.issue20923@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: ConfigParser should nested [] in section names. -> Explain ConfigParser 'valid section name' and .SECTCRE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Wed Nov 25 12:36:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Nov 2015 17:36:12 +0000
Subject: [docs] [issue20923] Explain ConfigParser 'valid section name' and
 .SECTCRE
In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za>
Message-ID: <1448472971.91.0.879995243749.issue20923@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, the doc issue is separate from the other bug, since that one will apply only to 3.6, and the doc changes apply to all maintenance releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20923>
_______________________________________

From report at bugs.python.org  Wed Nov 25 13:20:44 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Nov 2015 18:20:44 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448475644.1.0.497746970581.issue25730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Hiroaki, please include a bit of text explanation.  What 'default.css' are you referring to?  If it is a Sphinx file and not in the CPython repository /Doc, then this should be closed here and reopened on the separate Sphinx tracker.

In any case, this is not a security issue for python code, and hence not for 3.2, 3,3.  3.4 will be security patch only in a few weeks.

----------
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Wed Nov 25 14:41:31 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Wed, 25 Nov 2015 19:41:31 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448480491.54.0.749623339733.issue25730@psf.upfronthosting.co.za>


hiroaki itoh added the comment:

Ah, sorry I'd mistaked.

I don't know if this is Sphinx issue, but CPython repo has Doc/tools/static, Doc/tools/templates, so I still think, this can be fixed by customizing these, for example overriding style at layout.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Wed Nov 25 14:44:31 2015
From: report at bugs.python.org (John Yeung)
Date: Wed, 25 Nov 2015 19:44:31 +0000
Subject: [docs] [issue25735] math.factorial doc should mention integer
 return type
Message-ID: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>


New submission from John Yeung:

The math module docs state

Except when explicitly noted otherwise, all return values are floats.

But math.factorial isn't what I would call explicit about returning int:

math.factorial(x)
    Return x factorial. Raises ValueError if x is not integral or is negative.

At minimum, shouldn't the first sentence be "Return x factorial as an int."? I haven't tested on all Python versions, but math.factorial on 2.7 and 3.2 definitely return int (or long in Python 2 when necessary).

----------
assignee: docs at python
components: Documentation
messages: 255382
nosy: John.Yeung, docs at python
priority: normal
severity: normal
status: open
title: math.factorial doc should mention integer return type
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Wed Nov 25 15:25:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Nov 2015 20:25:36 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448483136.02.0.091243046975.issue25730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Can you create either a specific patch or perhaps more important a test that fails now but should pass with a proper patch?

----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Wed Nov 25 15:34:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Nov 2015 20:34:10 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448483650.72.0.794770157284.issue25730@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since it is a visual issue and we have no infrastructure for that kind of web view testing, I don't think a test is possible.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Thu Nov 26 04:06:57 2015
From: report at bugs.python.org (hiroaki itoh)
Date: Thu, 26 Nov 2015 09:06:57 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448528817.38.0.478936681786.issue25730@psf.upfronthosting.co.za>


hiroaki itoh added the comment:

Because there are a couple of ways (places) to fix this, I'll try them, so please wait. For testing, I think we can only visit all htmls manually and I'll make an effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Thu Nov 26 06:07:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Nov 2015 11:07:15 +0000
Subject: [docs] [issue22989] HTTPResponse.msg not as documented
In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za>
Message-ID: <20151126110711.652.85020@psf.io>


Roundup Robot added the comment:

New changeset fa3c9faabfb0 by Martin Panter in branch '3.4':
Issues #22989, #21228: Document HTTP response object for urlopen()
https://hg.python.org/cpython/rev/fa3c9faabfb0

New changeset b55c006b79bc by Martin Panter in branch '3.5':
Issue #22989, #21228: Merge urlopen() doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/b55c006b79bc

New changeset c6930661599b by Martin Panter in branch 'default':
Issue #22989, #21228: Merge urlopen() doc from 3.5
https://hg.python.org/cpython/rev/c6930661599b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22989>
_______________________________________

From report at bugs.python.org  Thu Nov 26 06:07:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Nov 2015 11:07:15 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
 methods of urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <20151126110711.652.45566@psf.io>


Roundup Robot added the comment:

New changeset fa3c9faabfb0 by Martin Panter in branch '3.4':
Issues #22989, #21228: Document HTTP response object for urlopen()
https://hg.python.org/cpython/rev/fa3c9faabfb0

New changeset b55c006b79bc by Martin Panter in branch '3.5':
Issue #22989, #21228: Merge urlopen() doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/b55c006b79bc

New changeset c6930661599b by Martin Panter in branch 'default':
Issue #22989, #21228: Merge urlopen() doc from 3.5
https://hg.python.org/cpython/rev/c6930661599b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21228>
_______________________________________

From report at bugs.python.org  Thu Nov 26 06:12:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 Nov 2015 11:12:49 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
 methods of urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1448536369.24.0.674327125723.issue21228@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21228>
_______________________________________

From report at bugs.python.org  Thu Nov 26 06:19:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 Nov 2015 11:19:03 +0000
Subject: [docs] [issue22989] HTTPResponse.msg not as documented
In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za>
Message-ID: <1448536743.68.0.79705440675.issue22989@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation now mentions the ?msg? quirk and the info() method.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22989>
_______________________________________

From report at bugs.python.org  Thu Nov 26 06:20:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 Nov 2015 11:20:40 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
 methods of urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1448536840.09.0.966384722597.issue21228@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21228>
_______________________________________

From report at bugs.python.org  Thu Nov 26 09:56:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Nov 2015 14:56:49 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448549809.2.0.151829377964.issue25730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I intentionally said 'test' rather than 'unittest' or 'automated test' to allow for the possibility of a human-operated view test script posted here on the issue.  

IDLE now has a view test framework to run tests for either one or all modules with visual displays.  For all:
  python -m idlelib.idle_test.htest
This has been very useful when modifying files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:09:31 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Nov 2015 17:09:31 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1448557771.57.0.0540245650948.issue25730@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see what you mean.  It's still tricky for web stuff, though, because what you see can completely depend on things like window size and browser version.  So a detailed description of how to produce the error would be good, and we'll see if we actually can :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25730>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:16:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Nov 2015 17:16:39 +0000
Subject: [docs] [issue13275] Recommend xml.etree for XML processing
In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za>
Message-ID: <1448558199.24.0.142961847374.issue13275@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13275>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:17:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Nov 2015 17:17:05 +0000
Subject: [docs] [issue10942] xml.etree.ElementTree.tostring returns type
 bytes, expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1448558225.94.0.901557814052.issue10942@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:21:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Nov 2015 17:21:29 +0000
Subject: [docs] [issue8426] multiprocessing.Queue fails to get() very large
 objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1448558489.57.0.617611057799.issue8426@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Nov 26 12:53:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Nov 2015 17:53:58 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1448560438.25.0.617131974688.issue18911@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18911>
_______________________________________

From report at bugs.python.org  Fri Nov 27 04:24:04 2015
From: report at bugs.python.org (Firat Ozgul)
Date: Fri, 27 Nov 2015 09:24:04 +0000
Subject: [docs] [issue25741] Usual Installation Directory
Message-ID: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>


New submission from Firat Ozgul:

Official documentation reads: "On Windows machines, the Python installation is usually placed in C:\Python35"

However, as of Python 3.5.0, usual installation directory on Windows is %LOCALAPPDATA%\Programs\Python.

----------
assignee: docs at python
components: Documentation
messages: 255455
nosy: docs at python, firatozgul
priority: normal
severity: normal
status: open
title: Usual Installation Directory
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 05:02:20 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 27 Nov 2015 10:02:20 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448618540.32.0.194482306773.issue25741@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Where does it go if the user hasn't set %LOCALAPPDATA% ?

----------
nosy: +lac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 05:20:48 2015
From: report at bugs.python.org (Firat Ozgul)
Date: Fri, 27 Nov 2015 10:20:48 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448619648.46.0.914364533167.issue25741@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Correct me if I am wrong, but as far as I know, %LOCALAPPDATA% is always set in Windows. When you want to install Python for just one user (which is the default), files are installed into this directory (LOCALAPPDATA). If you choose to install Python for all users, however, files are installed into %PROGRAMFILES% or %PROGRAMFILES(x86)%

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 05:28:48 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 27 Nov 2015 10:28:48 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448620128.05.0.300395424731.issue25741@psf.upfronthosting.co.za>


Laura Creighton added the comment:

I don't know the answer, but from the point of view of a webmaster who
gets support requests and doesn't have a windows system, it would be
very useful to already know where a person's python is supposed to
be, and thus good if the documentation said something along the
lines of:

If the user does not specify %LOCALAPPDATA% then it defaults to
<wherever that is> 

assuming there is such a default, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 05:56:07 2015
From: report at bugs.python.org (Firat Ozgul)
Date: Fri, 27 Nov 2015 10:56:07 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448621767.59.0.558707644614.issue25741@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Actually, under 'Using Python on Windows' at https://docs.python.org/3/using/windows.html, the documentation correctly refers to %LOCALAPPDATA% and %PROGRAMFILES% or %PROGRAMFILES(x86)% environment variables as the default installation directories for just-for-me installs and for all-user installs, respectively. The information provided in the tutorial part of the documentation (where it refers C:\Python35 as the default location) contradicts the one provided under 'Using Python on Windows'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 10:50:58 2015
From: report at bugs.python.org (Zack Weinberg)
Date: Fri, 27 Nov 2015 15:50:58 +0000
Subject: [docs] [issue25743] Clarify exactly what \w matches in UNICODE mode
Message-ID: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za>


New submission from Zack Weinberg:

The `re` module documentation does not do a good job of explaining exactly what `\w` matches.  Quoting https://docs.python.org/3.5/library/re.html :

> \w
> For Unicode (str) patterns:
> Matches Unicode word characters; this includes most characters
> that can be part of a word in any language, as well as numbers
> and the underscore.

Empirically, this appears to mean "everything in Unicode general categories L* and N*, plus U+005F (underscore)".  That is a perfectly sensible definition and the documentation should state it in those terms.  "Unicode word characters" could mean any number of different things; note for instance that UTS#18 gives a very different definition.

(Further reading: https://gist.github.com/zackw/3077f387591376c7bf67 plus links therefrom).

----------
assignee: docs at python
components: Documentation
messages: 255463
nosy: docs at python, zwol
priority: normal
severity: normal
status: open
title: Clarify exactly what \w matches in UNICODE mode
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25743>
_______________________________________

From report at bugs.python.org  Fri Nov 27 11:14:25 2015
From: report at bugs.python.org (Andi McClure)
Date: Fri, 27 Nov 2015 16:14:25 +0000
Subject: [docs] [issue25743] Clarify exactly what \w matches in UNICODE mode
In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za>
Message-ID: <1448640865.65.0.17947416032.issue25743@psf.upfronthosting.co.za>


Andi McClure added the comment:

I would like to request also a clear explanation be given for the documentation in the 2.7 branch. From https://docs.python.org/2.7/library/re.html :

"\w ... If UNICODE is set, this will match the characters [0-9_] plus whatever is classified as alphanumeric in the Unicode character properties database"

This is ambiguous. Does it mean the "Alphabetic" property from UAX#44? Does it mean something else?

----------
nosy: +Andi McClure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25743>
_______________________________________

From report at bugs.python.org  Fri Nov 27 11:35:23 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 27 Nov 2015 16:35:23 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448642123.44.0.753916449247.issue25741@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 11:40:30 2015
From: report at bugs.python.org (Zack Weinberg)
Date: Fri, 27 Nov 2015 16:40:30 +0000
Subject: [docs] [issue25743] Clarify exactly what \w matches in UNICODE mode
In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za>
Message-ID: <1448642430.55.0.605684152245.issue25743@psf.upfronthosting.co.za>


Zack Weinberg added the comment:

FWIW, the actual behavior of \w matching "everything in Unicode general categories L* and N*, plus U+005F (underscore)" is consistent across all versions I can conveniently test (2.7, 3.4, 3.5).

In 2.7, there are four characters in general category Nl that \w doesn't match, but I believe that is just a bug, not an intentional difference of behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25743>
_______________________________________

From report at bugs.python.org  Fri Nov 27 12:25:42 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 27 Nov 2015 17:25:42 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448645142.59.0.172389708324.issue25741@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a patch to try to modernize the whole section a bit, and to remove one of the two other instances of 'Python35' in the docs (the other instance is in the docs for pyvenv, which needs its own overhaul in a separate issue).

----------
keywords: +patch
nosy: +zach.ware
versions: +Python 3.6
Added file: http://bugs.python.org/file41172/issue25741.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Fri Nov 27 14:53:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Nov 2015 19:53:29 +0000
Subject: [docs] [issue25735] math.factorial doc should mention integer
 return type
In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>
Message-ID: <1448654009.7.0.457512251249.issue25735@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree.  In testing, I discovered this bug
>>> factorial(decimal.Decimal(5.2))
120
I don't know if this is a glitch in factorial or Decimal.

I also noticed
>>> fac(fractions.Fraction(4, 1))
Traceback (most recent call last):
  File "<pyshell#10>", line 1, in <module>
    fac(fractions.Fraction(4, 1))
TypeError: an integer is required (got type Fraction)
Perhaps this is due to no __int__ method.

----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Fri Nov 27 18:22:05 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 27 Nov 2015 23:22:05 +0000
Subject: [docs] [issue25756] asyncio WriteTransport documentation typo
Message-ID: <1448666524.97.0.228973534452.issue25756@psf.upfronthosting.co.za>


New submission from ???? ?????????:

Here is the match against master.


Doc/library/asyncio-protocol.rst:

@@ -156,9 +156,9 @@ WriteTransport
       high-water limit is given, the low-water limit defaults to an
       implementation-specific value less than or equal to the
       high-water limit.  Setting *high* to zero forces *low* to zero as
-      well, and causes :meth:`pause_writing` to be called whenever the
+      well, and causes :meth:`resume_writing` to be called whenever the
       buffer becomes non-empty.  Setting *low* to zero causes
-      :meth:`resume_writing` to be called only once the buffer is empty.
+      :meth:`pause_writing` to be called only once the buffer is empty.
       Use of zero for either limit is generally sub-optimal as it
       reduces opportunities for doing I/O and computation
       concurrently.

----------
assignee: docs at python
components: Documentation
messages: 255508
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: asyncio WriteTransport documentation typo
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25756>
_______________________________________

From report at bugs.python.org  Fri Nov 27 23:36:35 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 28 Nov 2015 04:36:35 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448685395.72.0.0335769163984.issue25741@psf.upfronthosting.co.za>


Steve Dower added the comment:

That patch looks good to me.

LOCALAPPDATA is set by the operating system, typically to C:\Users\<username>\AppData\Local (at least since Vista I think? Certainly since Win7). While it's possible to customize it, people who know how to do that won't be emailing webmasters expecting technical support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Sat Nov 28 04:11:39 2015
From: report at bugs.python.org (Firat Ozgul)
Date: Sat, 28 Nov 2015 09:11:39 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448701899.45.0.144301973754.issue25741@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Maybe that part of the tutorial should also include a link to https://docs.python.org/3/using/windows.html. This document contains all the details for using Python on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Sat Nov 28 05:38:45 2015
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 28 Nov 2015 10:38:45 +0000
Subject: [docs] [issue25741] Usual Installation Directory
In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za>
Message-ID: <1448707125.13.0.32352291339.issue25741@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> LOCALAPPDATA is set by the operating system, typically to 
> C:\Users\<username>\AppData\Local (at least since Vista I
> think? Certainly since Win7

Vista introduced LOCALAPPDATA, so there's no problem referencing it in the docs for 3.5+. 

On a related note, section 3.4.4.1 [1] could be changed to use %LOCALAPPDATA% instead of referring to the shell function SHGetFolderPath and CSIDL_LOCAL_APPDATA. 

[1]: https://docs.python.org/3.5/using/windows.html#customization-via-ini-files

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25741>
_______________________________________

From report at bugs.python.org  Sat Nov 28 09:29:08 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Nov 2015 14:29:08 +0000
Subject: [docs] [issue25735] math.factorial doc should mention integer
 return type
In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>
Message-ID: <1448720948.63.0.705145103221.issue25735@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

[Terry]

>>> factorial(decimal.Decimal(5.2))
120

Yep, that's definitely wrong. If we want to behave the same way as for float, we should accept only integral Decimal values. (Though I'm not much of a fan of the float behaviour: I would have preferred math.factorial not to accept floats at all.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Sat Nov 28 10:43:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Nov 2015 15:43:25 +0000
Subject: [docs] [issue20836] Pickle Nonetype
In-Reply-To: <1393800619.38.0.666577692495.issue20836@psf.upfronthosting.co.za>
Message-ID: <1448725405.66.0.115383228941.issue20836@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20836>
_______________________________________

From report at bugs.python.org  Sun Nov 29 00:44:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Nov 2015 05:44:43 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1448775883.79.0.700485990418.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch with the following changes:

* Clarified that wbits affects the container format as well as windows size
* Undid some word wrapping to make the diff simpler
* Added zero and 32 + n for decompression
* Added full list of options under decompressobj(), and link decompress() to that. Otherwise we end up saying decompression generates a header, when it really parses the header.
* Added tests for various wbits values
* Compressing with window bits = 8 not actually supported (Zlib bumps it to 9: <https://github.com/madler/zlib/commit/8e34b3a#diff-8940271ef2146523af486ca4408361daR264>. The change log says ?Force windowBits > 8 to avoid a bug in the encoder for a window size of 256 bytes?.)
* Updated doc strings

----------
keywords: +patch
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file41187/zlib-wbits.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Sun Nov 29 02:11:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Nov 2015 07:11:06 +0000
Subject: [docs] =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor?=
 =?utf-8?b?4oCZcyBmbHVzaCgpIG1ldGhvZA==?=
In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za>
Message-ID: <1448781065.95.0.486155768482.issue23200@psf.upfronthosting.co.za>


Martin Panter added the comment:

And regarding other internal buffers and state, calling flush() or decompress() guarantees you get as much data as possible, but there is no error checking. You have to check the eof attribute to ensure everything is done, otherwise I don?t think there is a way to differentiate a truncated stream from a properly ended stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23200>
_______________________________________

From report at bugs.python.org  Sun Nov 29 15:07:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Nov 2015 20:07:21 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448827641.86.0.621061267788.issue25759@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are aware that you can't use existing pre-compiled extension modules with your 2015 build, right?

It would be great if you could open a separate issue for the double close problem.  This should be a doc issue for fixing the docs.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, r.david.murray
stage:  -> needs patch
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From report at bugs.python.org  Sun Nov 29 15:30:32 2015
From: report at bugs.python.org (Kovid Goyal)
Date: Sun, 29 Nov 2015 20:30:32 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448829032.14.0.854326624381.issue25759@psf.upfronthosting.co.za>


Kovid Goyal added the comment:

Yes, I am aware. I embed python in my application, which includes large C++ libraries. Those libraries are going to start requiring to be compiled with a modern compiler soon, which means I need python to also be compiled with a modern compiler. I already manually compile all python extensions in my build system, so that is not a problem. And before someone suggests I upgrade to python 3, porting half a million lines of python is simply not worth it for me. 

I'll be happy to open a separate bug report, but first I want some advice. I have got all the other tests passing as well, except one single test. test_gzip.test_many_append. 

The reason that test fails is apparently because of a buffering bug in the stdio C functions in VS 2015. Combining lots of seeks relative to SEEK_CUR causes read() to return incorrect data. I can make the test pass by modify the gzip module to open files with bufferring=0, or by putting in a seek(0, 0) to cause the stdio layer to flush its read buffer at the appropriate point. However, this is not an actual fix, just an inefficient workaround.

My question is, how do I properly workaround this bug? And how come this bug is not triggered in Python 3.5.0? Am I diagnosing this correctly? Any other alternative explanations?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From report at bugs.python.org  Sun Nov 29 17:21:29 2015
From: report at bugs.python.org (Elizabeth Myers)
Date: Sun, 29 Nov 2015 22:21:29 +0000
Subject: [docs] [issue25767] asyncio documentation section 18.5.2.3.1.
 (Windows) links to French Wikipedia in English docs
Message-ID: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

The link for HPET in the asyncio documentation (18.5.2.3.1 Windows, final paragraph, see https://docs.python.org/3/library/asyncio-eventloops.html#windows) links to https://fr.wikipedia.org/wiki/High_Precision_Event_Timer for the HPET link even though the document is in English (it should link to the English Wikipedia version instead).

----------
assignee: docs at python
components: Documentation
messages: 255598
nosy: Elizacat, docs at python
priority: normal
severity: normal
status: open
title: asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25767>
_______________________________________

From report at bugs.python.org  Sun Nov 29 17:44:15 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 29 Nov 2015 22:44:15 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
Message-ID: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

I'm using the public functions of Python's built-in compileall module.

https://docs.python.org/3/library/compileall.html#public-functions

There doesn't appear to be documentation of what each of these functions returns.

I figured out, for example, that compileall.compile_file() returns 1 when the file compiles successfully, and 0 if not.

If this is "official" behavior, it would be good to see it documented so that we can rely on it.

I'd be happy to submit a patch to fix this if a committer is willing to shepherd a new contributor (me) through the process. Otherwise, this is probably a quick fix for experienced contributors.

----------
assignee: docs at python
components: Documentation
messages: 255600
nosy: Nicholas Chammas, docs at python
priority: normal
severity: normal
status: open
title: compileall functions do not document return values
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25768>
_______________________________________

From report at bugs.python.org  Sun Nov 29 23:32:51 2015
From: report at bugs.python.org (Kovid Goyal)
Date: Mon, 30 Nov 2015 04:32:51 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448857971.55.0.910346895751.issue25759@psf.upfronthosting.co.za>


Kovid Goyal added the comment:

To answer part of my question, the reason the fseek()+fread() bug does not affect python 3.5.0 appears to be because it implements its own buffering and does not use fseek()/fread() at all. 

Sigh, I really hope the answer does not end up being that I have to re-implement fseek()/ftell()/fread()/fwrite() using lseek()/read()/write() on windows. Or I could wait and hope Microsoft fixes the bug :)

As a first step, to confirm that the bug is in the CRT, I'll have the gzip module record all reads/seeks/tells and then see if I can reproduce the bug in a plain C program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From report at bugs.python.org  Mon Nov 30 00:43:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Nov 2015 05:43:30 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1448862210.55.0.569777596582.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

In the python-dev thread, Nick Coghlan gave some arguments and examples where PyObject_SetAttr() is intended to be used for deletion. So I will keep my changes for PyObject_SetAttr(), and also _SetAttrString() for consistency.

My second patch documents deletion with sq_ass_item(), mp_ass_subscript(), and PySequence_SetItem().

PyObject_SetItem() does not look like it deletes items. It explicitly considers value == NULL to be an error. As a consequence, PyMapping_SetItemString() does not delete either.

PySequence_SetItem() does accept NULL to delete the item. I think this is reasonable, to keep it consistent with sq_ass_item(), so I documented it.

PySequence_SetSlice() also accepts NULL to delete the slice. But I am more reluctant to document this, because I don?t know of any slot or other code that would benefit. So I have left it as is for the time being.

----------
Added file: http://bugs.python.org/file41194/setattr.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25701>
_______________________________________

From report at bugs.python.org  Mon Nov 30 01:10:42 2015
From: report at bugs.python.org (Kovid Goyal)
Date: Mon, 30 Nov 2015 06:10:42 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448863842.11.0.661577792842.issue25759@psf.upfronthosting.co.za>


Kovid Goyal added the comment:

Doesn't seem like a bug in the CRT, I cannot reproduce in a plain CRT program, so now I get to try to figure out what is broken in fileobject.c by VS 2015. That's a relief :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From python at anselm.kiefner.de  Fri Nov 27 07:51:48 2015
From: python at anselm.kiefner.de (Anselm Kiefner)
Date: Fri, 27 Nov 2015 13:51:48 +0100
Subject: [docs] sum( ) in generator bugged
Message-ID: <565851E4.7070405@anselm.kiefner.de>

Hi,

I just found this bug:

Python 3.4.3+ (default, Oct 14 2015, 16:03:50)
[GCC 5.2.1 20151010] on linux

>>> L = [1,2,3]
>>> L_g = (x for x in L)
>>> a = [x*sum(L) for x in L]
>>> b = (x*sum(L_g) for x in L_g)
>>> print(a, list(b))
[6, 12, 18] [5]

whether b is a generator or not doesn't make a difference, it seems to
be a problem with sum() operating on L_g while L_g is consumed.
I stumbled over the problem first in ipython notebook running python
kernel 3.5.0, but couldn't find anything about it in the bugtracker.

Thanks,
Anselm

From vadmium+py at gmail.com  Mon Nov 30 00:38:00 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 30 Nov 2015 05:38:00 -0000
Subject: [docs] Document that tp_setattro and tp_setattr are used for
 deleting attributes (issue 25701)
Message-ID: <20151130053800.595.53787@psf.upfronthosting.co.za>


https://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst
File Doc/c-api/object.rst (right):

https://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst#newcode72
Doc/c-api/object.rst:72: otherwise set it to *v* (``o.attr_name = v``).
Returns ``-1`` on failure.
On 2015/11/25 10:54:34, haypo wrote:
> Raise an exception and returns -1 on failure, return 0 on success.
> 
> (Same change for other functions below)

Done with slightly different wording, also for the new functions
referenced in the new patch.

https://bugs.python.org/review/25701/diff/16034/Include/abstract.h
File Include/abstract.h (right):

https://bugs.python.org/review/25701/diff/16034/Include/abstract.h#newcode196
Include/abstract.h:196: (o.attr_name=v). Returns -1 on failure.
On 2015/11/25 10:54:34, haypo wrote:
> Raise an exception and returns -1 on failure, return 0 on success.

Applied slightly different wording to all three modified functions in my
new patch.

https://bugs.python.org/review/25701/

From report at bugs.python.org  Mon Nov 30 05:24:15 2015
From: report at bugs.python.org (Kovid Goyal)
Date: Mon, 30 Nov 2015 10:24:15 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448879055.66.0.832044779058.issue25759@psf.upfronthosting.co.za>


Kovid Goyal added the comment:

I take it back, my methodology in reproducing the function calls used by the gzip module was flawed. 

It does look like a bug in the CRT, but I have not been able to isolate a simple way of reproducing it. I have however, found a workaround for it, that has an acceptable performance impact. 

https://github.com/kovidgoyal/cpython/commit/72ae720ab057b1ac0402d67a7195d575d34afbbd

Now all tests pass (except for tcl/tk and distutils, neither of which I care about -- well I will probably need to fix up distutils at some point, but not now :). Running testsuite as

./PCbuild/amd64/python_d.exe Lib/test/regrtest.py -u network,cpu,subprocess,urlfetch

@steve: Thank you for all the work you did porting python 3.x to VS 2015, that certainly made by life a lot easier.

I would of course, be ecstatic if you were to consider merging my work into the python 2.7 branch, but if not, I understand -- no one likes to maintain a legacy codebase.

In any case, for interested third parties, my work is available here:

https://github.com/kovidgoyal/cpython (2.7 branch)

and instructions on building python on windows using a nice cygwin environment are here: 

https://github.com/kovidgoyal/calibre/blob/master/setup/installer/windows/notes2.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From report at bugs.python.org  Mon Nov 30 09:00:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Nov 2015 14:00:45 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448892045.59.0.669601261713.issue25759@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unfortunately it is unlikely we'll merge it, since because of the compiled extension issue we have a negative motivation for supporting anything other than the release compiler currently used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From report at bugs.python.org  Mon Nov 30 10:10:49 2015
From: report at bugs.python.org (Kovid Goyal)
Date: Mon, 30 Nov 2015 15:10:49 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1448896249.19.0.995210947057.issue25759@psf.upfronthosting.co.za>


Kovid Goyal added the comment:

No worries, as I said, I understand, I would probably do the same, were I in your shoes. I have found that being a maintainer of a complex software project tends to naturally increase conservatism :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25759>
_______________________________________

From report at bugs.python.org  Mon Nov 30 23:57:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Dec 2015 04:57:37 +0000
Subject: [docs] [issue25767] asyncio documentation section 18.5.2.3.1.
 (Windows) links to French Wikipedia in English docs
In-Reply-To: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za>
Message-ID: <20151201045734.27936.62082@psf.io>


Roundup Robot added the comment:

New changeset f475379bf22c by Zachary Ware in branch '3.4':
Issue #25767: Link to English Wikipedia instead of French.
https://hg.python.org/cpython/rev/f475379bf22c

New changeset fee19d2d7713 by Zachary Ware in branch '3.5':
Issue #25767: Merge with 3.4
https://hg.python.org/cpython/rev/fee19d2d7713

New changeset 734247d5d0f9 by Zachary Ware in branch 'default':
Closes #25767: Merge with 3.5
https://hg.python.org/cpython/rev/734247d5d0f9

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25767>
_______________________________________

From report at bugs.python.org  Mon Nov 30 23:57:52 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 01 Dec 2015 04:57:52 +0000
Subject: [docs] [issue25767] asyncio documentation section 18.5.2.3.1.
 (Windows) links to French Wikipedia in English docs
In-Reply-To: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za>
Message-ID: <1448945871.99.0.199128243577.issue25767@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report!

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25767>
_______________________________________