From report at bugs.python.org  Tue Dec  1 03:02:50 2015
From: report at bugs.python.org (Juchen Zeng)
Date: Tue, 01 Dec 2015 08:02:50 +0000
Subject: [docs] [issue25772] Misleading descriptions about built-in type
 `super.`
Message-ID: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za>


New submission from Juchen Zeng:

A few days ago, I was learning built-in type `super` through [python official doc](https://docs.python.org/2/library/functions.html#super).  
And I was mislead by its documentation, in the part of how `__mro__` resolution works. Below is the part which confuse me:

"""
super(type[, object-or-type])

# ISSUE IRRELEVANT DOC OMITTED

The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super(). The attribute is dynamic and can change whenever the inheritance hierarchy is updated.
"""

>From the description of the doc we can see that `super()` takes two arguments, the first is `type` and the second is an optional `object-or-type`. So, when I saw the doc statement: `The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super(). `, I naturally thought here the `type` refers to the compulsory first `type` argument. But after doing a series of [experiments][EXP_REF]. It turns out in `super()` was using the second `type`'s `__mro__` attribute! And if the second argument is an object, it will use `object.__class__.__mro__` as its resolution order. Unless a learner experimented it throughly like me, he will have lots of difficulty to figured out that `type` mentioned in the doc refers to the second optional argument. I think here the doc should be clearly specified that the second argument's `__mro__` is what super relies on. I suggest to add distinctions on arguments name or add more clarification informations in the doc here.

By the way, the python3 document has the same issue.  
If you decided to fix this, maybe you want to fix its python3 version, too.

 

[EXP_REF]: http://stackoverflow.com/questions/33890918/how-does-super-interacts-with-a-classs-mro-attribute-in-multiple-inheri/33891281#33891281

----------
assignee: docs at python
components: Documentation
messages: 255643
nosy: Juchen Zeng, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Misleading descriptions about built-in type `super.`
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  1 04:54:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 01 Dec 2015 09:54:47 +0000
Subject: [docs] [issue25772] Misleading descriptions about built-in type
 `super.`
In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za>
Message-ID: <1448963687.79.0.697216515749.issue25772@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree. I think Issue 23674 already covers this. I will try to propose some changes there.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> super() documentation isn't very clear

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

From waox1234 at qq.com  Tue Dec  1 09:15:17 2015
From: waox1234 at qq.com (=?gb18030?B?s9TlZcuOtcR3YW94?=)
Date: Tue, 1 Dec 2015 22:15:17 +0800
Subject: [docs]
 https://docs.python.org/3/library/os.html?highlight=os#module-os
Message-ID: <tencent_5BBB951B1AFD7226017E115A@qq.com>

Hi,I found confuse when I learn it
os.rename(src, dst, *, src_dir_fd=None, dst_dir_fd=None)
Rename the file or directory src to dst. If dst is a directory, OSError will be raised.

but rename can deal with dir well(of course)


my mother language is not english so maybe I just made a joke but can you explain the mean 
 If dst is a directory, OSError will be raised.
to me?


THX!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151201/c9d6e8c3/attachment-0001.html>

From report at bugs.python.org  Tue Dec  1 10:36:31 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Dec 2015 15:36:31 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448984191.33.0.669223517365.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

At this point the return values are probably as official as they are going to be since these are such old functions.

If you want to write a patch, Nicholas, please see https://docs.python.org/devguide/ for instructions on how to do that.

----------
nosy: +brett.cannon

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

From storchaka at gmail.com  Tue Dec  1 10:50:59 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Tue, 01 Dec 2015 15:50:59 -0000
Subject: [docs] Document that tp_setattro and tp_setattr are used for
 deleting attributes (issue 25701)
Message-ID: <20151201155059.7651.81446@psf.upfronthosting.co.za>

Reviewers: haypo, vadmium,


http://bugs.python.org/review/25701/diff/16071/Doc/c-api/object.rst
File Doc/c-api/object.rst (right):

http://bugs.python.org/review/25701/diff/16071/Doc/c-api/object.rst#newcode71
Doc/c-api/object.rst:71: object *o*.  If *v* is *NULL*, delete the value
(``del o.attr_name``),
May be refer to PyObject_DelAttr if v is NULL?

http://bugs.python.org/review/25701/diff/16071/Doc/c-api/object.rst#newcode72
Doc/c-api/object.rst:72: otherwise set it to *v* (``o.attr_name = v``).
Raises an exception and
It looks to me that "Return" and "Raise" are more preferable to
"Returns" and "Raises" in the documentation.



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

Affected files:
  Doc/c-api/object.rst
  Doc/c-api/sequence.rst
  Doc/c-api/typeobj.rst
  Include/abstract.h


# HG changeset patch
# Parent  ebec1a98ab81d19245e4bde2da03ccb489b9eb5f
Issue #25701: Document C API functions that both set and delete objects

diff -r ebec1a98ab81 Doc/c-api/object.rst
--- a/Doc/c-api/object.rst	Mon Nov 23 16:44:30 2015 +0200
+++ b/Doc/c-api/object.rst	Mon Nov 30 05:38:20 2015 +0000
@@ -67,26 +67,29 @@
 
 .. c:function:: int PyObject_SetAttr(PyObject *o, PyObject *attr_name, PyObject *v)
 
-   Set the value of the attribute named *attr_name*, for object *o*, to the value
-   *v*. Returns ``-1`` on failure.  This is the equivalent of the Python statement
-   ``o.attr_name = v``.
+   Set or delete the value of the attribute named *attr_name*, for
+   object *o*.  If *v* is *NULL*, delete the value (``del o.attr_name``),
+   otherwise set it to *v* (``o.attr_name = v``). Raises an exception and
+   returns ``-1`` on failure; returns ``0`` on success.
 
 
 .. c:function:: int PyObject_SetAttrString(PyObject *o, const char *attr_name, PyObject *v)
 
-   Set the value of the attribute named *attr_name*, for object *o*, to the value
-   *v*. Returns ``-1`` on failure.  This is the equivalent of the Python statement
-   ``o.attr_name = v``.
+   Set or delete the value of the attribute named *attr_name*, for
+   object *o*.  If *v* is *NULL*, delete the value (``del o.attr_name``),
+   otherwise set it to *v* (``o.attr_name = v``). Raises an exception and
+   returns ``-1`` on failure; returns ``0`` on success.
 
 
 .. c:function:: int PyObject_GenericSetAttr(PyObject *o, PyObject *name, PyObject *value)
 
-   Generic attribute setter function that is meant to be put into a type
+   Generic attribute setter and deleter function that is meant to be put into a type
    object's ``tp_setattro`` slot.  It looks for a data descriptor in the
    dictionary of classes in the object's MRO, and if found it takes preference
-   over setting the attribute in the instance dictionary. Otherwise, the
-   attribute is set in the object's :attr:`~object.__dict__` (if present).
-   Otherwise, an :exc:`AttributeError` is raised and ``-1`` is returned.
+   over setting or deleting the attribute in the instance dictionary. Otherwise, the
+   attribute is set or deleted in the object's :attr:`~object.__dict__` (if present).
+   On success, ``0`` is returned, otherwise an :exc:`AttributeError`
+   is raised and ``-1`` is returned.
 
 
 .. c:function:: int PyObject_DelAttr(PyObject *o, PyObject *attr_name)
@@ -378,7 +381,8 @@
 
 .. c:function:: int PyObject_SetItem(PyObject *o, PyObject *key, PyObject *v)
 
-   Map the object *key* to the value *v*.  Returns ``-1`` on failure.  This is the
+   Map the object *key* to the value *v*.  Raises an exception and
+   returns ``-1`` on failure; returns ``0`` on success.  This is the
    equivalent of the Python statement ``o[key] = v``.
 
 
diff -r ebec1a98ab81 Doc/c-api/sequence.rst
--- a/Doc/c-api/sequence.rst	Mon Nov 23 16:44:30 2015 +0200
+++ b/Doc/c-api/sequence.rst	Mon Nov 30 05:38:20 2015 +0000
@@ -62,8 +62,10 @@
 
 .. c:function:: int PySequence_SetItem(PyObject *o, Py_ssize_t i, PyObject *v)
 
-   Assign object *v* to the *i*\ th element of *o*.  Returns ``-1`` on failure.  This
-   is the equivalent of the Python statement ``o[i] = v``.  This function *does
+   Assign object *v* to the *i*\ th element of *o*, or delete the
+   element if *v* is *NULL*.  Raises an exception and returns ``-1`` on
+   failure; returns ``0`` on success.  This is the equivalent of the
+   Python statements ``o[i] = v`` and ``del o[i]``.  This function *does
    not* steal a reference to *v*.
 
 
diff -r ebec1a98ab81 Doc/c-api/typeobj.rst
--- a/Doc/c-api/typeobj.rst	Mon Nov 23 16:44:30 2015 +0200
+++ b/Doc/c-api/typeobj.rst	Mon Nov 30 05:38:20 2015 +0000
@@ -208,7 +208,7 @@
 
 .. c:member:: setattrfunc PyTypeObject.tp_setattr
 
-   An optional pointer to the set-attribute-string function.
+   An optional pointer to the function for setting and deleting attributes.
 
    This field is deprecated.  When it is defined, it should point to a function
    that acts the same as the :c:member:`~PyTypeObject.tp_setattro` function, but taking a C string
@@ -351,7 +351,7 @@
 
 .. c:member:: setattrofunc PyTypeObject.tp_setattro
 
-   An optional pointer to the set-attribute function.
+   An optional pointer to the function for setting and deleting attributes.
 
    The signature is the same as for :c:func:`PyObject_SetAttr`.  It is usually
    convenient to set this field to :c:func:`PyObject_GenericSetAttr`, which
@@ -724,7 +724,7 @@
       typedef struct PyGetSetDef {
           char *name;    /* attribute name */
           getter get;    /* C function to get the attribute */
-          setter set;    /* C function to set the attribute */
+          setter set;    /* C function to set or delete the attribute */
           char *doc;     /* optional doc string */
           void *closure; /* optional additional data for getter and setter */
       } PyGetSetDef;
@@ -775,7 +775,8 @@
 
 .. c:member:: descrsetfunc PyTypeObject.tp_descr_set
 
-   An optional pointer to a "descriptor set" function.
+   An optional pointer to a function for setting and deleting
+   a descriptor's value.
 
    The function signature is ::
 
@@ -1171,9 +1172,11 @@
 
 .. c:member:: objobjargproc PyMappingMethods.mp_ass_subscript
 
-   This function is used by :c:func:`PyObject_SetItem` and has the same
-   signature.  If this slot is *NULL*, the object does not support item
-   assignment.
+   This function is used by :c:func:`PyObject_SetItem` and
+   :c:func:`PyObject_DelItem`.  It has the same signature as
+   :c:func:`PyObject_SetItem`, but *v* can also be set to *NULL* to delete
+   an item.  If this slot is *NULL*, the object does not support item
+   assignment and deletion.
 
 
 .. _sequence-structs:
@@ -1222,7 +1225,7 @@
 
    This function is used by :c:func:`PySequence_SetItem` and has the same
    signature.  This slot may be left to *NULL* if the object does not support
-   item assignment.
+   item assignment and deletion.
 
 .. c:member:: objobjproc PySequenceMethods.sq_contains
 
diff -r ebec1a98ab81 Include/abstract.h
--- a/Include/abstract.h	Mon Nov 23 16:44:30 2015 +0200
+++ b/Include/abstract.h	Mon Nov 30 05:38:20 2015 +0000
@@ -191,9 +191,10 @@
 
      int PyObject_SetAttrString(PyObject *o, const char *attr_name, PyObject *v);
 
-     Set the value of the attribute named attr_name, for object o,
-     to the value, v. Returns -1 on failure.  This is
-     the equivalent of the Python statement: o.attr_name=v.
+     Set or delete the value of the attribute named attr_name, for object o.
+     If v is NULL, delete the value (del o.attr_name), otherwise set it to v
+     (o.attr_name=v). Raises an exception and returns -1 on failure; returns
+     0 on success.
 
        */
 
@@ -201,9 +202,10 @@
 
      int PyObject_SetAttr(PyObject *o, PyObject *attr_name, PyObject *v);
 
-     Set the value of the attribute named attr_name, for object o,
-     to the value, v. Returns -1 on failure.  This is
-     the equivalent of the Python statement: o.attr_name=v.
+     Set or delete the value of the attribute named attr_name, for object o.
+     If v is NULL, delete the value (del o.attr_name), otherwise set it to v
+     (o.attr_name=v). Raises an exception and returns -1 on failure; returns
+     0 on success.
 
        */
 
@@ -993,9 +995,10 @@
      PyAPI_FUNC(int) PySequence_SetItem(PyObject *o, Py_ssize_t i, PyObject *v);
 
        /*
-     Assign object v to the ith element of o.  Returns
-     -1 on failure.  This is the equivalent of the Python
-     statement: o[i]=v.
+     Assign object v to the ith element of o, or delete the element if v is
+     NULL.  Raises an exception and returns -1 on failure; returns 0 on
+     success.  This is the equivalent of the Python statements: "o[i]=v" and
+     "del o[i]".
        */
 
      PyAPI_FUNC(int) PySequence_DelItem(PyObject *o, Py_ssize_t i);



From report at bugs.python.org  Tue Dec  1 11:07:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Dec 2015 16:07:36 +0000
Subject: [docs] [issue25772] Misleading descriptions about built-in `super.`
In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za>
Message-ID: <1448986056.01.0.504770223127.issue25772@psf.upfronthosting.co.za>


R. David Murray added the comment:

Just FYI, 'super' is not a type, it is a function that returns a proxy.  (In python3 there is also compiler magic involved in the no-argument form, but it is still a function :)

----------
nosy: +r.david.murray
title: Misleading descriptions about built-in type `super.` -> Misleading descriptions about built-in `super.`

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

From report at bugs.python.org  Tue Dec  1 11:27:30 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Dec 2015 16:27:30 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448987250.86.0.462593892885.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Exciting! I'm on it.

----------

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

From report at bugs.python.org  Tue Dec  1 11:59:08 2015
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 01 Dec 2015 16:59:08 +0000
Subject: [docs] [issue25772] Misleading descriptions about built-in `super.`
In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za>
Message-ID: <1448989148.91.0.738811162565.issue25772@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> Just FYI, 'super' is not a type

No, super is a type:

    >>> super
    <type 'super'>

It's one of 3 types defined in Objects/typeobject.c: 

    PyBaseObject_Type : "object"
    PyType_Type       : "type"
    PySuper_Type      : "super"

A super instance (CPython superobject) has the following members: 

     __thisclass__  : the class invoking super()
     __self__       : the instance invoking super()
     __self_class__ : the type of the instance invoking super()

super has a cutsom __getattribute__ (tp_getattro) slot, super_getattro, which proxies attribute access starting at the parent/sibling of __thisclass__ in the __mro__ of __self_class__. 

super even defines a __get__ descriptor (tp_descr_get) method, super_descr_get, though I've never used it as such.

----------
nosy: +eryksun

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

From report at bugs.python.org  Tue Dec  1 12:05:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Dec 2015 17:05:51 +0000
Subject: [docs] [issue25772] Misleading descriptions about built-in `super.`
In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za>
Message-ID: <1448989551.5.0.597369707325.issue25772@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh.  OK, learn something new every day.

----------

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

From report at bugs.python.org  Tue Dec  1 12:51:52 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Dec 2015 17:51:52 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448992312.31.0.192333235621.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

OK, here's a patch.

I reviewed the doc style guide [0] but I'm not 100% sure if I'm using the appropriate tense. There are also a couple of lines that go a bit over 80 characters, but the file already had a few of those.

Am happy to make any adjustments, if necessary.

[0] https://docs.python.org/devguide/documenting.html#style-guide

----------
keywords: +patch
Added file: http://bugs.python.org/file41201/compileall-doc.patch

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

From report at bugs.python.org  Tue Dec  1 12:55:53 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Dec 2015 17:55:53 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448992553.06.0.403398573688.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

And I just signed the contributor agreement. (Some banner showed up when I attached the patch to this issue asking me to do so.)

----------

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

From report at bugs.python.org  Tue Dec  1 13:33:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Dec 2015 18:33:42 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448994822.61.0.172650194423.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks, Nicholas! I'll have a look when I have a chance (hopefully no later than Friday).

----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Tue Dec  1 14:33:40 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Dec 2015 19:33:40 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448998420.77.0.502911189725.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

:thumbsup: Take your time.

----------

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

From report at bugs.python.org  Tue Dec  1 14:40:38 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Dec 2015 19:40:38 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448998838.82.0.516847583335.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Oh derp. It appears this is dup of issue24386. Apologies.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 14:41:05 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Tue, 01 Dec 2015 19:41:05 +0000
Subject: [docs] [issue25768] compileall functions do not document return
 values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1448998865.46.0.267817292528.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Whoops, wrong issue. Reopening.

----------
status: closed -> open

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

From report at bugs.python.org  Tue Dec  1 19:52:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 02 Dec 2015 00:52:56 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1449017576.56.0.117345798389.issue23674@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here are some specific changes I suggest:

1. Most confusing: super() uses the MRO of the second argument, not the first.

2. Clarify that is is not just the first argument that is skipped in the MRO, it is all preceding classes as well. The first argument does not have to be the class at the start of the MRO.

3. Revise signature and use consistent parameter names in text. Currently, ?obj? and ?type2? are only defined in the doc string. Perhaps super(subclass[, self]). Or maybe super(type[, obj]), matching error messages, or super(thisclass[, self]), matching the special attributes. Type and type2 are too confusing for my taste.

4. Link to the glossary rather than getattr().

5. Explain more about unbound super objects, when the second argument is omitted. Apparently they are descriptors; when you set them on a class and then ?get? them in an instance, you get a new version bound to that instance. This is obscure, but I feel it might help the general understanding. [It seems you cannot bind a super() object to a class this way; maybe that is a bug.]

6. Explain more about ?bound? super objects: getting a method from the super object binds the method to the second argument. [This also works for getting data properties, but not setting or deleting them; see Issue 14965.]

7. Not only isinstance() or issubclass() must be satisfied, but the first argument must be a concrete class. Virtual subclassing is not sufficient if the subclass is not in the MRO. This would address Issue 20503. Also, the first argument should be a derived class, not ?object? itself.

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

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

From report at bugs.python.org  Tue Dec  1 20:02:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 02 Dec 2015 01:02:16 +0000
Subject: [docs] [issue20503] super behaviour and abstract base classes
 (either implementation or documentation/error message is wrong)
In-Reply-To: <1391441802.61.0.557224247712.issue20503@psf.upfronthosting.co.za>
Message-ID: <1449018136.44.0.105473893382.issue20503@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am proposing some documentation changes in Issue 23674 which would address this.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
dependencies: +super() documentation isn't very clear
nosy: +docs at python, martin.panter
versions: +Python 2.7, Python 3.6

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

From report at bugs.python.org  Wed Dec  2 01:49:10 2015
From: report at bugs.python.org (Sonali Gupta)
Date: Wed, 02 Dec 2015 06:49:10 +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: <1449038950.05.0.152894607644.issue25735@psf.upfronthosting.co.za>


Sonali Gupta added the comment:

States that math.factorial(x) returns x factorial as an integer.

----------
keywords: +patch
nosy: +mine0901
Added file: http://bugs.python.org/file41206/bug.patch

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

From report at bugs.python.org  Wed Dec  2 05:53:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2015 10:53:25 +0000
Subject: [docs] [issue22039] PyObject_SetAttr doesn't mention value = NULL
In-Reply-To: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za>
Message-ID: <1449053605.61.0.146815473449.issue22039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See two alternative issues: issue25701 for documenting existing behavior, and issue25773 for deprecating it (and converting PyObject_DelAttr to a function).

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

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

From report at bugs.python.org  Wed Dec  2 06:48:49 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Dec 2015 11:48:49 +0000
Subject: [docs] [issue25756] asyncio WriteTransport documentation typo
In-Reply-To: <1448666524.97.0.228973534452.issue25756@psf.upfronthosting.co.za>
Message-ID: <1449056929.25.0.17298616557.issue25756@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I think the doc is correct.
`pause_writing` is called when write buffer becomes non empty, empty buffer is precondition for `resume_writing` call.

----------
nosy: +asvetlov
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec  2 07:22:21 2015
From: report at bugs.python.org (Juchen Zeng)
Date: Wed, 02 Dec 2015 12:22:21 +0000
Subject: [docs] [issue25777] Misleading descriptions in docs about invoking
 descriptors.
Message-ID: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za>


New submission from Juchen Zeng:

[Doc Link](https://docs.python.org/2/howto/descriptor.html#invoking-descriptors)

In descriptions about how to invoke descriptors with super(), it says:

    The call super(B, obj).m() searches obj.__class__.__mro__ for the base class A immediately following B and then returns A.__dict__['m'].__get__(obj, B). If not a descriptor, m is returned unchanged. If not in the dictionary, m reverts to a search using object.__getattribute__().

But the call ` super(B, obj).m()` will not return `A.__dict__['m'].__get__(obj, B)`, it will trigger the `__call__` method of ` A.__dict__['m'].__get__(obj, B)` if it has that attr, and return what this `__call__` method returns.  It could be anything.
It's actually `super(B, obj).m` returns `A.__dict__['m'].__get__(obj, B)` if m is a descriptor.

In short, the original description in the doc can be abbreviated to:
`The call super(B, obj).m() [did something] and returns A.__dict__['m'].__get__(obj, B).`
Which is obviously misleading.

As the method/function call isn't the core part in this sentence. I suggest the doc to be fixed like this:

    The action super(B, obj).m searches obj.__class__.__mro__ for the base class A immediately following B and then returns A.__dict__['m'].__get__(obj, B).

----------
assignee: docs at python
components: Documentation
messages: 255712
nosy: Juchen Zeng, docs at python, martin.panter
priority: normal
severity: normal
status: open
title: Misleading descriptions in docs about invoking descriptors.
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  2 16:48:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Dec 2015 21:48:34 +0000
Subject: [docs] [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1449092914.33.0.764979633179.issue25500@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Wed Dec  2 19:15:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 03 Dec 2015 00:15:37 +0000
Subject: [docs] [issue25777] Misleading descriptions in docs about invoking
 descriptors.
In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za>
Message-ID: <1449101737.29.0.99379430675.issue25777@psf.upfronthosting.co.za>


Martin Panter added the comment:

Agreed. The same problem is also present in the Python 3 documentation. (Beware there is another report somewhere about updating this how-to more generally for Python 3.)

Maybe we could be more explicit and start off ?The attribute lookup super(B, obj).m searches .?.?.?

Also, I find the last sentence confusing: ?If not in the dictionary, m reverts to a search using object.__getattribute__().? I guess it is describing how super(B, obj).__self__ accesses the internal attribute of the super object itself. Maybe it should say ?If not in any base class, the lookup resorts to attributes of the super instance itself using object.__getattribute__().?

----------
stage:  -> needs patch
versions: +Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Dec  2 22:29:40 2015
From: report at bugs.python.org (Karl Richter)
Date: Thu, 03 Dec 2015 03:29:40 +0000
Subject: [docs] [issue25787] Add an explanation what happens with subprocess
 parent and child processes when signals are sent
Message-ID: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za>


New submission from Karl Richter:

The [documentation of subprocess](https://docs.python.org/3.6/library/subprocess.html) doesn't contain a substantial statement how signals are handled which are send to the python interpreter. After reading the referenced docs it should be clear

  * whether a signal is passed to both the parent and the child (If yes in which order? What happens if the child process spawns a process which isn't controlled by python?)
  * whether signal handlers are inherited (judging from the `restore_signals` parameter some are overwritten -> what's the purpose of this?). Are changes of a signal handler in the parent reflected in the child?

----------
assignee: docs at python
components: Documentation
messages: 255802
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Add an explanation what happens with subprocess parent and child processes when signals are sent
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec  3 05:35:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2015 10:35:07 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1449138906.42.0.648784807131.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Using readlines() instead of readline() was added in 4dbbf322a9df for performance. But it looks that now this is not needed. Naive implementation with readline() is about 2 times slower, but with careful optimization we can achieve the same performance (or better).

Here are results of benchmarks.

Unpatched:

$ mkdir testdir
$ for i in `seq 10`; do for j in `seq 1000`; do echo "$j"; done >"testdir/file$i"; done
$ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "f = fileinput.input(files)" "while f.readline(): pass"
10 loops, best of 3: 56.4 msec per loop
$ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "list(fileinput.input(files))"10 loops, best of 3: 68.4 msec per loop

Patched:

$ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "f = fileinput.input(files)" "while f.readline(): pass"
10 loops, best of 3: 47.4 msec per loop
$ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "list(fileinput.input(files))"
10 loops, best of 3: 63.1 msec per loop

The patch also fixes original issue.

It also fixes yet one issue. Currently lines are buffered and you need to enter many lines first then get first line:

>>> import fileinput
>>> fi = fileinput.input()
>>> line = fi.readline()
qwerty
asdfgh
zxcvbn
^D
>>> line
'qwerty\n'

With the patch you get the line just as it entered.

----------
assignee: docs at python -> serhiy.storchaka
stage: needs patch -> patch review
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file41224/fileinput_no_buffer.patch

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

From report at bugs.python.org  Thu Dec  3 05:45:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2015 10:45:23 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1449139523.44.0.909686483769.issue15068@psf.upfronthosting.co.za>


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


----------
nosy: +gvanrossum

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

From report at bugs.python.org  Thu Dec  3 05:49:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2015 10:49:25 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1449139765.99.0.661951497155.issue15068@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file41224/fileinput_no_buffer.patch

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

From report at bugs.python.org  Thu Dec  3 05:49:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2015 10:49:40 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1449139780.24.0.764398763674.issue15068@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file41225/fileinput_no_buffer.patch

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

From report at bugs.python.org  Thu Dec  3 06:00:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2015 11:00:30 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1449140430.21.0.210466314284.issue15068@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7
Added file: http://bugs.python.org/file41226/fileinput_no_buffer-2.7.patch

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

From report at bugs.python.org  Thu Dec  3 12:16:05 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 03 Dec 2015 17:16:05 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449162965.38.0.648746883953.issue23936@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I also ran into confusion with this while trying to write an import hook.

Attached is my shot at a docs patch. I've done a slightly larger rewording, trying to make it easier to understand, and added more links between parts of the docs.

I left mentions of the deprecated find_module and find_loader methods in the 'finder' glossary entry, but for sys.meta_path I have only described find_spec() - it does still fall back to the deprecated methods, but I thought that trying to explain that would make the description of meta_path harder to follow.

----------
nosy: +takluyver
Added file: http://bugs.python.org/file41227/finders_and_specs.patch

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

From report at bugs.python.org  Thu Dec  3 12:17:45 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Dec 2015 17:17:45 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449163065.35.0.655363402687.issue23936@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Thu Dec  3 13:04:17 2015
From: report at bugs.python.org (Karl Richter)
Date: Thu, 03 Dec 2015 18:04:17 +0000
Subject: [docs] [issue25787] Add an explanation what happens with subprocess
 parent and child processes when signals are sent
In-Reply-To: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za>
Message-ID: <1449165857.8.0.947957421262.issue25787@psf.upfronthosting.co.za>


Karl Richter added the comment:

Please also explain how to deal with process replacement in child processes (assuming that http://stackoverflow.com/questions/34059576/how-to-register-a-signal-handler-for-a-subprocess/34065587#34065587 is correct).

----------

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

From report at bugs.python.org  Thu Dec  3 18:07:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 03 Dec 2015 23:07:21 +0000
Subject: [docs] [issue25787] Add an explanation what happens with subprocess
 parent and child processes when signals are sent
In-Reply-To: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za>
Message-ID: <1449184041.28.0.350232556994.issue25787@psf.upfronthosting.co.za>


Martin Panter added the comment:

These are mainly questions of the OS, not really of Python or the subprocess module. I?m not sure the Python documentation is the right place for this information, unless it gives a misleading impression.

At least in Unix, signals may be sent to the child process only, or to a process group including the parent and the child. Processes can run concurrently, in which case the order is meaningless.

Signal handlers are inherited when os.fork() or similar copies a process, but cannot be inherited when a process is replaced or spawned, because the child is not a copy of the parent.

I think the ?restore_signals? flag is an unnecessary and could be deprecated. The purpose of Python ignoring some signals is so that things like writing to a disconnected pipe or socket does not trigger the default signal handling.

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

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

From report at bugs.python.org  Thu Dec  3 18:59:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 03 Dec 2015 23:59:53 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449187193.04.0.579011480117.issue23936@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for adding that link to ModuleSpec, it is definitely needed to make sense of a lot of stuff.

I left some review comments and questions.

If the behaviour of sys.meta_path has changed, I think it needs a ?New/changed in version X? notice. If it makes the modern description hard to follow, maybe keep it in a separate paragraph.

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

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

From report at bugs.python.org  Thu Dec  3 21:27:56 2015
From: report at bugs.python.org (irdb)
Date: Fri, 04 Dec 2015 02:27:56 +0000
Subject: [docs] [issue23220] Documents input/output effects of how IDLE runs
 user code
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1449196076.68.0.947348528045.issue23220@psf.upfronthosting.co.za>


Changes by irdb <electro.nnn at gmail.com>:


----------
nosy: +irdb

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

From report at bugs.python.org  Fri Dec  4 07:48:26 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 04 Dec 2015 12:48:26 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449233306.22.0.812853429874.issue23936@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Updated patch attached, responding to Martin's suggestions.

I'm not quite sure what to do about the 'finder' glossary entry. 'Finder' now seems to be a more abstract classification covering two distinct kinds of thing: *meta path finders* and *path entry finders*. They have similar methods (find_spec, find_module), but with slightly different signatures. Is 'finder' a sufficiently meaningful concept to remain in the glossary, or should we take it out and be explicit about what type of finder is meant elsewhere in the docs?

----------
Added file: http://bugs.python.org/file41237/finders_and_specs2.patch

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

From 1328968413 at qq.com  Fri Dec  4 04:56:51 2015
From: 1328968413 at qq.com (=?gb18030?B?uqu/objV?=)
Date: Fri, 4 Dec 2015 17:56:51 +0800
Subject: [docs] Reporting Bugs
Message-ID: <tencent_77C2A89B1634D8274A7EC7C2@qq.com>

21.12.3. Examples
>>> data == b'' True
may be:
print(data ==b'')






url : https://docs.python.org/3.4/library/http.client.html#httpresponse-objects
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151204/bc7abc47/attachment.html>

From hanjungang at hotmail.com  Fri Dec  4 05:11:01 2015
From: hanjungang at hotmail.com (=?gb2312?B?uqu/objV?=)
Date: Fri, 4 Dec 2015 10:11:01 +0000
Subject: [docs] Reporting Bugs
Message-ID: <SNT152-W462786DC773CCDDD2DE447D60C0@phx.gbl>

21.12.3. Examples>>> data == b''
Truemay be:print(data ==b'')


url : https://docs.python.org/3.4/library/http.client.html#httpresponse-objects 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151204/c4a12c85/attachment.html>

From takowl at gmail.com  Fri Dec  4 07:42:01 2015
From: takowl at gmail.com (takowl at gmail.com)
Date: Fri, 04 Dec 2015 12:42:01 -0000
Subject: [docs] Wrong references to deprecated find_module instead of
 find_spec (issue 23936)
Message-ID: <20151204124201.14661.14759@psf.upfronthosting.co.za>


http://bugs.python.org/review/23936/diff/16097/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/23936/diff/16097/Doc/glossary.rst#newcode312
Doc/glossary.rst:312: implement at least one of the methods
:meth:`find_spec`,
On 2015/12/04 00:51:30, vadmium wrote:
> Which find_spec()? MetaPathFinder.find_spec() or
PathEntryFinder.find_spec(). Or
> is the assumed signature such that the differences do not matter?

That depends on which kind of finder it is. My understanding is that as
of Python 3.3, 'finder' is a rather abstract notion that encompasses the
two distinct kinds.

Maybe 'finder' should be removed from the glossary entirely, and other
parts of the docs should be explicit about which type of finder they
want. But if there is anywhere appropriate to describe the more abstract
notion of a 'finder', it's probably in the glossary.

http://bugs.python.org/review/23936/diff/16097/Doc/library/sys.rst
File Doc/library/sys.rst (right):

http://bugs.python.org/review/23936/diff/16097/Doc/library/sys.rst#newcode782
Doc/library/sys.rst:782: A list of :term:`meta path finder` objects that
have their :meth:`find_spec`
On 2015/12/04 00:51:30, vadmium wrote:
> :meth:`~importlib.abc.MetaPathFinder.find_spec`; also twice below

Done.

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

From vadmium+py at gmail.com  Tue Dec  1 23:19:25 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 02 Dec 2015 04:19:25 -0000
Subject: [docs] Document that tp_setattro and tp_setattr are used for
 deleting attributes (issue 25701)
Message-ID: <20151202041925.27688.28516@psf.upfronthosting.co.za>


http://bugs.python.org/review/25701/diff/16071/Doc/c-api/object.rst
File Doc/c-api/object.rst (right):

http://bugs.python.org/review/25701/diff/16071/Doc/c-api/object.rst#newcode71
Doc/c-api/object.rst:71: object *o*.  If *v* is *NULL*, delete the value
(``del o.attr_name``),
On 2015/12/01 16:50:59, storchaka wrote:
> May be refer to PyObject_DelAttr if v is NULL?

Good idea (if we decide not to deprecate this)

http://bugs.python.org/review/25701/diff/16071/Doc/c-api/object.rst#newcode72
Doc/c-api/object.rst:72: otherwise set it to *v* (``o.attr_name = v``).
Raises an exception and
On 2015/12/01 16:50:59, storchaka wrote:
> It looks to me that "Return" and "Raise" are more preferable to
"Returns" and
> "Raises" in the documentation.

Agreed. I was keeping the mood the same as the original, but now I see
it would be better to agree with the first two sentences.

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

From vadmium+py at gmail.com  Thu Dec  3 18:51:30 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Thu, 03 Dec 2015 23:51:30 -0000
Subject: [docs] Wrong references to deprecated find_module instead of
 find_spec (issue 23936)
Message-ID: <20151203235130.1755.28495@psf.upfronthosting.co.za>


https://bugs.python.org/review/23936/diff/16097/Doc/glossary.rst
File Doc/glossary.rst (right):

https://bugs.python.org/review/23936/diff/16097/Doc/glossary.rst#newcode312
Doc/glossary.rst:312: implement at least one of the methods
:meth:`find_spec`,
Which find_spec()? MetaPathFinder.find_spec() or
PathEntryFinder.find_spec(). Or is the assumed signature such that the
differences do not matter?

https://bugs.python.org/review/23936/diff/16097/Doc/glossary.rst#newcode313
Doc/glossary.rst:313: :meth:`find_loader` or :meth:`find_module`.
Perhaps linking to :meth:`~importlib.abc.PathEntryFinder.find_loader`
and :meth:`~importlib.abc.Finder.find_module` would be appropriate here?

https://bugs.python.org/review/23936/diff/16097/Doc/library/sys.rst
File Doc/library/sys.rst (right):

https://bugs.python.org/review/23936/diff/16097/Doc/library/sys.rst#newcode782
Doc/library/sys.rst:782: A list of :term:`meta path finder` objects that
have their :meth:`find_spec`
:meth:`~importlib.abc.MetaPathFinder.find_spec`; also twice below

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

From ak at tml-software.com  Fri Dec  4 08:47:47 2015
From: ak at tml-software.com (Arthur Kristmann)
Date: Fri, 4 Dec 2015 13:47:47 +0000
Subject: [docs] Inconsistent macro documentation
Message-ID: <0E4B49F157917C46BB3B8F098FC02D8A1E31859D@wExchange.wobe-team.wbt>

Hello everyone,

I'm using the Python C API to make our library available to Python. It's working well, but I found a some inconsistencies in the documentation of macro definitions.
To use the DateTime Objects the documentations states that I need to invoke the macro "PyDateTime_IMPORT" to initialise the datetime module. (https://docs.python.org/3.4/c-api/datetime.html)

I got an error for a missing semicolon and I fix this by adding a semicolon at the end of the macro "PyDateTime_IMPORT;".
Other macros from the same API such as "Py_BEGIN_ALLOW_THREADS" don't need to be close with an semicolon. (https://docs.python.org/3/c-api/init.html#c.Py_BEGIN_ALLOW_THREADS)
At the end of the day it's not a big deal if you know it, but then I would expect that it's documented.

It's actually good to not use default semicolons, because macros like "PyDateTime_GET_YEAR(o)" feels more like a function that needs to be closed at the end. But in this case it would be nice, if you would add semicolons in the documentation when it's needed like in the datetime section.

Thanks for your time.

Best regard,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151204/f8c5290a/attachment-0001.html>

From report at bugs.python.org  Fri Dec  4 12:47:31 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2015 17:47:31 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449251251.86.0.858706802592.issue23936@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The generic "finder" glossary entry should be rather generic and then point to "meta path finder" and "path entry finder" for dis-ambiguity (and both of those terms are already in the glossary).

----------

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

From report at bugs.python.org  Fri Dec  4 12:57:09 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 04 Dec 2015 17:57:09 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449251829.45.0.986301676538.issue23936@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

That's basically what I was aiming for. Should the description be briefer and more generic?

----------

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

From report at bugs.python.org  Fri Dec  4 13:09:52 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2015 18:09:52 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449252592.23.0.271002690347.issue23936@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I vote for more generic; left a review to that effect.

----------

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

From report at bugs.python.org  Fri Dec  4 13:18:14 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 04 Dec 2015 18:18:14 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449253094.9.0.152485563041.issue23936@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Third revision of patch responding to Brett's suggestions.

----------
Added file: http://bugs.python.org/file41240/finders_and_specs3.patch

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

From report at bugs.python.org  Fri Dec  4 14:37:06 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2015 19:37:06 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449257825.95.0.0717291721359.issue23936@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM; I will commit it when I have a chance.

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

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

From report at bugs.python.org  Fri Dec  4 15:14:04 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Fri, 04 Dec 2015 20:14:04 +0000
Subject: [docs] [issue25039] Docs: Link to Stackless Python in Design and
 History FAQ section is broken
In-Reply-To: <1441789710.22.0.139129124794.issue25039@psf.upfronthosting.co.za>
Message-ID: <1449260044.45.0.32437399806.issue25039@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Hi everyone on the nosy list!
I think this issue can be closed. 
The maintainer of the stackless website
http://www.stackless.com/ has posted a message about technical problems and included links to the docs for the project.

----------

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

From report at bugs.python.org  Fri Dec  4 15:32:32 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 04 Dec 2015 20:32:32 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449261152.08.0.485310667254.issue23936@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks Brett :-)

----------

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

From report at bugs.python.org  Fri Dec  4 15:39:41 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 04 Dec 2015 20:39:41 +0000
Subject: [docs] [issue25039] Docs: Link to Stackless Python in Design and
 History FAQ section is broken
In-Reply-To: <1441789710.22.0.139129124794.issue25039@psf.upfronthosting.co.za>
Message-ID: <1449261581.3.0.741422512171.issue25039@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 17:52:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Dec 2015 22:52:16 +0000
Subject: [docs] [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <20151204225212.21245.25659@psf.io>


Roundup Robot added the comment:

New changeset 567baf74ebad by Brett Cannon in branch '3.5':
Issue #25500: Fix the language reference to not claim that import
https://hg.python.org/cpython/rev/567baf74ebad

New changeset 0259c2c555fb by Brett Cannon in branch 'default':
Merge for issue #25500
https://hg.python.org/cpython/rev/0259c2c555fb

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

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

From report at bugs.python.org  Fri Dec  4 17:54:12 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2015 22:54:12 +0000
Subject: [docs] [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1449269652.58.0.892384289026.issue25500@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the bug report, Sergei! I fixed the docs in the end.

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

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

From report at bugs.python.org  Fri Dec  4 18:23:21 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2015 23:23:21 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1449271401.87.0.174382700691.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I just realized there are no tests for this in test_compileall either. Nicholas, do you have any interest in attempting to add tests for the return values before we document them?

----------
title: compileall functions do not document return values -> compileall functions do not document or test return values
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Fri Dec  4 18:46:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Dec 2015 23:46:51 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <20151204234647.29957.31132@psf.io>


Roundup Robot added the comment:

New changeset 88cee7d16ccb by Brett Cannon in branch '3.5':
Issue #23936: Clarify what finders are.
https://hg.python.org/cpython/rev/88cee7d16ccb

New changeset 1b1900d2a537 by Brett Cannon in branch 'default':
Merge for issue #23936
https://hg.python.org/cpython/rev/1b1900d2a537

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

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

From report at bugs.python.org  Fri Dec  4 18:48:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2015 23:48:42 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
 instead of find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1449272922.0.0.808630565591.issue23936@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the bug report, Ra?l, and the patch, Thomas!

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Fri Dec  4 19:00:10 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Dec 2015 00:00:10 +0000
Subject: [docs] [issue21240] Add an abstactmethod directive to the Python
 ReST domain
In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za>
Message-ID: <1449273610.01.0.575359088382.issue21240@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Are you willing to check this in, Berker? Or is it not needed anymore?

----------
assignee: docs at python -> berker.peksag
nosy: +brett.cannon

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

From report at bugs.python.org  Fri Dec  4 19:01:03 2015
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 05 Dec 2015 00:01:03 +0000
Subject: [docs] [issue13368] Possible problem in documentation of module
 subprocess, method send_signal
In-Reply-To: <1320722594.89.0.739080107592.issue13368@psf.upfronthosting.co.za>
Message-ID: <1449273663.84.0.921373037088.issue13368@psf.upfronthosting.co.za>


Eryk Sun added the comment:

You can send CTRL_C_EVENT to a process group. But it requires the group leader to manually enable Ctrl+C handling. Initially it's disabled when creating a process with CREATE_NEW_PROCESS_GROUP. 

The attached script demonstrates sending CTRL_C_EVENT to a process group. The child process is the group leader, so CTRL+C event processing has to be manually enabled in it by calling SetConsoleCtrlHandler(NULL, FALSE). This flag gets inherited by the grandchild process. Example output:

    Process 0300: created process 0464
    Process 0464: created process 0456
    Process 0464: received CTRL+C
    Process 0456: received CTRL+C

That said, given that MSDN [erroneously] claims that this isn't possible, probably the subprocess docs should only mention sending CTRL_BREAK_EVENT.

----------
nosy: +eryksun
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file41242/proc_group_ctrl_c.py

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

From report at bugs.python.org  Fri Dec  4 20:23:11 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 05 Dec 2015 01:23:11 +0000
Subject: [docs] [issue14911] generator.throw() documentation inaccurate
In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>
Message-ID: <1449278591.68.0.967181456834.issue14911@psf.upfronthosting.co.za>


Martin Panter added the comment:

Changes in throw-3x.v2.patch:

* Split into two signatures
* Added parallel coroutine.throw(value) signature
* *Value* should be an exception instance; drop mentioning other options
* Default value is instantiated from *type*
* __traceback__ can be cleared
* Dropped the example
* Update generator and coroutine doc strings with double signatures

----------
Added file: http://bugs.python.org/file41245/throw-3x.v2.patch

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

From report at bugs.python.org  Sat Dec  5 08:09:22 2015
From: report at bugs.python.org (Dingyuan Wang)
Date: Sat, 05 Dec 2015 13:09:22 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
 concurrent.futures documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <1449320962.53.0.860319791675.issue23962@psf.upfronthosting.co.za>


Changes by Dingyuan Wang <abcdoyle888 at gmail.com>:


----------
nosy: +gumblex

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

From report at bugs.python.org  Sat Dec  5 09:54:16 2015
From: report at bugs.python.org (Isobel Hooper)
Date: Sat, 05 Dec 2015 14:54:16 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1449327256.17.0.428582991588.issue1753718@psf.upfronthosting.co.za>


Isobel Hooper added the comment:

Attached patch fixes library/base64.rst as requested, and adds a mention of RFC 3548 into the b2a_base64() docs in library/binascii.rst.

I'm not sure I've made the changes against the right version of the docs - I think this might be against the 3.3 docs.

----------
keywords: +patch
nosy: +Isobel Hooper
Added file: http://bugs.python.org/file41250/issue-1753718.patch

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

From report at bugs.python.org  Sat Dec  5 12:25:57 2015
From: report at bugs.python.org (Ben Schreib)
Date: Sat, 05 Dec 2015 17:25:57 +0000
Subject: [docs] [issue25808] The Python Tutorial 5.3. Tuples and Sequences
Message-ID: <1449336357.7.0.799444279603.issue25808@psf.upfronthosting.co.za>


New submission from Ben Schreib:

The example given in section 5.3 shows an output of "t[0] = 88888" but I believe it should be "t[0] = 12345"

>>> t
(12345, 54321, 'hello!')
>>> # Tuples may be nested:
... u = t, (1, 2, 3, 4, 5)
>>> u
((12345, 54321, 'hello!'), (1, 2, 3, 4, 5))
>>> # Tuples are immutable:
... t[0] = 88888

----------
assignee: docs at python
components: Documentation
messages: 255962
nosy: Ben Schreib, docs at python
priority: normal
severity: normal
status: open
title: The Python Tutorial 5.3. Tuples and Sequences
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Dec  5 12:45:46 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 05 Dec 2015 17:45:46 +0000
Subject: [docs] [issue25808] The Python Tutorial 5.3. Tuples and Sequences
In-Reply-To: <1449336357.7.0.799444279603.issue25808@psf.upfronthosting.co.za>
Message-ID: <1449337546.64.0.0758463336246.issue25808@psf.upfronthosting.co.za>


SilentGhost added the comment:

No, what this piece of code shows is that trying to assign a value to a tuple element will cause an error. Of course, the same error would be raise when using the the value 12345, but it's more instructive to use a different value to not confuse the reader.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Dec  5 15:13:23 2015
From: report at bugs.python.org (Andre Roberge)
Date: Sat, 05 Dec 2015 20:13:23 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
Message-ID: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>


New submission from Andre Roberge:

The documentation for eval() indicates that it takes keyword arguments:

eval(expression, globals=None, locals=None)

However, that is incorrect, as indicated by the builtin help:

>>> help(eval)
Help on built-in function eval in module builtins:

eval(...)
    eval(source[, globals[, locals]]) -> value

----------
assignee: docs at python
components: Documentation
messages: 255969
nosy: aroberge, docs at python
priority: normal
severity: normal
status: open
title: Python 3 documentation for eval is incorrect
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/issue25810>
_______________________________________

From report at bugs.python.org  Sat Dec  5 15:25:45 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 05 Dec 2015 20:25:45 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449347145.0.0.0918815598051.issue25810@psf.upfronthosting.co.za>


SilentGhost added the comment:

I think this is the case where hard-coded strings where not updated in the C files.

----------
nosy: +SilentGhost
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Dec  5 15:29:56 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 05 Dec 2015 20:29:56 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449347396.09.0.579846116003.issue25810@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec  5 15:35:39 2015
From: report at bugs.python.org (random832)
Date: Sat, 05 Dec 2015 20:35:39 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449347739.11.0.875737881174.issue25810@psf.upfronthosting.co.za>


random832 added the comment:

Whatever the case may be, it *doesn't* support keyword arguments. e.g.:

>>> eval("a+b", globals={'a':1}, locals={'b':2})
TypeError: eval() takes no keyword arguments

So as the current situation stands, the documentation is wrong, and the help string is consistent with the code's actual behavior. Confirmed in Python 3.5.0.

----------
nosy: +random832
versions: +Python 3.5

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

From report at bugs.python.org  Sat Dec  5 15:39:41 2015
From: report at bugs.python.org (random832)
Date: Sat, 05 Dec 2015 20:39:41 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449347981.39.0.688110156107.issue25810@psf.upfronthosting.co.za>


random832 added the comment:

Oh, I just noticed, the help string is also wrong in 3.5 (which explains why you removed 3.5 from the versions list, which I hadn't noticed until after posting my previous comment).

----------

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

From report at bugs.python.org  Sat Dec  5 15:48:22 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 05 Dec 2015 20:48:22 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449348502.43.0.688811084082.issue25810@psf.upfronthosting.co.za>


SilentGhost added the comment:

Yes, whatever Andre's posted is not an output from 3.5. It's 3.4 or earlier.

Also it's a wider problem because the same issue exists for exec: built-in help shows keyword arguments, while docs and implementation require only positional.

----------
versions: +Python 3.6

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

From report at bugs.python.org  Sat Dec  5 15:56:29 2015
From: report at bugs.python.org (random832)
Date: Sat, 05 Dec 2015 20:56:29 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449348989.07.0.526308565428.issue25810@psf.upfronthosting.co.za>


random832 added the comment:

I guess the next question is what the intent is. Was there an intent, which was not followed through on, to upgrade these methods to support keyword arguments? Or is there an intent (here and everywhere) that documentation using keyword argument syntax is appropriate to use to document methods that have default values but do not in fact support keyword arguments? What does the "/" in the help text mean?

According to PEP 0436 (Argument Clinic), the "/" here indicates that the preceding parameters are positional-only, despite the apparent use of keyword syntax. Should this convention also be used in the documentation?

----------

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

From report at bugs.python.org  Sat Dec  5 16:00:05 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 05 Dec 2015 21:00:05 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449349205.46.0.910906019807.issue25810@psf.upfronthosting.co.za>


SilentGhost added the comment:

I'm not sure how the people are supposed to discover this convention according to pep 436. Or is this now intended as two separate incompatible conventions for online docs and built-in help?

----------

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

From report at bugs.python.org  Sat Dec  5 16:01:18 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 05 Dec 2015 21:01:18 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449349278.48.0.757426173096.issue25810@psf.upfronthosting.co.za>


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


----------
nosy: +larry

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

From report at bugs.python.org  Sat Dec  5 16:52:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 05 Dec 2015 21:52:58 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449352378.63.0.594993074667.issue25810@psf.upfronthosting.co.za>


Martin Panter added the comment:

See Issue 23738 where my current patch proposes using the PEP 457 slash (/) notation in the RST documentation, including for eval(). I?m not sure if there is a clear concensus for applying my patch however. An alternative would be to use the square-bracket notation, and explain in the text that the default values are None.

See also Issue 21314 about explaining the slash notation used by Argument Clinic and pydoc.

----------
nosy: +martin.panter
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  5 17:02:14 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Sat, 05 Dec 2015 22:02:14 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1449352934.38.0.293861730963.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Absolutely. I'll add a "bad source file" to `setUp()` [0] and check return values as part of the existing checks in `test_compile_files()` [1].

Does that sound like a good plan to you?

Also, I noticed that `compile_path()` has no tests. Should I test it as part of `test_compile_files()` or as part of a different test function?

[0] https://hg.python.org/cpython/file/tip/Lib/test/test_compileall.py#l14
[1] https://hg.python.org/cpython/file/tip/Lib/test/test_compileall.py#l57

----------

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

From report at bugs.python.org  Sat Dec  5 17:11:14 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 05 Dec 2015 22:11:14 +0000
Subject: [docs] [issue25813] co_flags section of inspect module docs out of
 date
Message-ID: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

It states "bitmap: 1=optimized | 2=newlocals | 4=*arg | 8=**arg" which is identical to the 2.7 docs.  Hence it bears no resemblance to the latest code.h, which for example has #define CO_ITERABLE_COROUTINE   0x0100.

----------
assignee: docs at python
components: Documentation
messages: 255985
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: co_flags section of inspect module docs out of date
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Dec  5 18:03:46 2015
From: report at bugs.python.org (random832)
Date: Sat, 05 Dec 2015 23:03:46 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449356626.67.0.628894562668.issue25810@psf.upfronthosting.co.za>


random832 added the comment:

What about fixing all methods so that they can take keywords? Are the functions with their current C signatures part of the stable ABI? Is there somewhere we could centrally add some magic "convert tuple+keywords to tuple, given list of names" code?

----------

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

From report at bugs.python.org  Sat Dec  5 18:05:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 05 Dec 2015 23:05:17 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
 concurrent.futures documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <1449356717.5.0.510551782321.issue23962@psf.upfronthosting.co.za>


Martin Panter added the comment:

A similar problem used to exist with asyncio.TimeoutError: Issue 21376.

There is no class called concurrent.future.Error, so I would remove that bit. Otherwise, the rest of the patch looks worthwhile.

With asyncio and multiprocessing, the exception name is spelt out in full, including the module prefix. Maybe it could also be done here to be less ambiguous. When reading it with an ordinary web browser, you don?t get to see the target of the hyperlinks. On the other hand, a full ?concurrent.futures.TimeoutError? is rather long and unwieldy. I?m not sure.

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

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

From report at bugs.python.org  Sat Dec  5 18:14:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 05 Dec 2015 23:14:25 +0000
Subject: [docs] [issue25777] Misleading descriptions in docs about invoking
 descriptors.
In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za>
Message-ID: <1449357265.46.0.897016825687.issue25777@psf.upfronthosting.co.za>


Martin Panter added the comment:

Similar change needed for <https://docs.python.org/dev/reference/datamodel.html#invoking-descriptors>. There, it uses the noun ?binding?, which seems an appropriate description of the action.

----------

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

From report at bugs.python.org  Sat Dec  5 18:21:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 05 Dec 2015 23:21:59 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449357719.15.0.851741475118.issue25810@psf.upfronthosting.co.za>


Martin Panter added the comment:

See Issue 8706 about changing functions and methods to accept keyword arguments. But this cannot be done in general. What would you call the first argument to dict() such that all possible keyword arguments still work? What is the first range() argument called: start or stop?

----------

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

From report at bugs.python.org  Sat Dec  5 18:27:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 05 Dec 2015 23:27:17 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
 default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1449358037.73.0.39673110297.issue23738@psf.upfronthosting.co.za>


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


----------
dependencies: +Python 3 documentation for eval is incorrect

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

From report at bugs.python.org  Sat Dec  5 20:25:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Dec 2015 01:25:39 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
 default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1449365138.15.0.44167136386.issue23738@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a more conservative patch using square brackets, and documenting the defaults in the text. I updated all the documentation from my previous patch, and added new changes for the ?io? module.

One quirk was that BufferedReader.read1() does not actually support the value ?1. Therefore I changed the base class to BufferedIOBase.read1([size]) without mentioning what happens when size is omitted. Related: Issue 23214.

----------
Added file: http://bugs.python.org/file41253/square-brackets.patch

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

From report at bugs.python.org  Sun Dec  6 01:12:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Dec 2015 06:12:15 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1449382335.64.0.960038615558.issue23674@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch against Python 3 with my suggestions. Let me know what you think, if I got anything wrong, extra bits that could be changed, etc.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file41255/super.patch

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

From report at bugs.python.org  Sun Dec  6 03:57:55 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 06 Dec 2015 08:57:55 +0000
Subject: [docs] [issue25813] co_flags section of inspect module docs out of
 date
In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za>
Message-ID: <1449392275.51.0.152809547499.issue25813@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

None of these constants are documented either:-
inspect.CO_COROUTINE
inspect.CO_GENERATOR
inspect.CO_ITERABLE_COROUTINE
inspect.CO_NESTED
inspect.CO_NEWLOCALS
inspect.CO_NOFREE
inspect.CO_OPTIMIZED
inspect.CO_VARARGS
inspect.CO_VARKEYWORDS

----------

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

From report at bugs.python.org  Sun Dec  6 10:30:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Dec 2015 15:30:17 +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: <1449415817.28.0.210441617491.issue25701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think the conclusion of Python_Dev discussion is that it is not worth to deprecate this behavior in the code. Current behavior of  PyObject_SetAttr and PySequence_SetItem should be documented with a deprecation notice.

----------

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

From report at bugs.python.org  Sun Dec  6 13:29:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2015 18:29:59 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1449426599.53.0.837915756305.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also the discussion in issue 25495.  I will try to review both of these issues soon.

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Dec  6 13:30:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2015 18:30:55 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1449426655.22.0.222013879311.issue25495@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also Issue 1753718.  I will try to review both of these issues soon.

----------

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

From report at bugs.python.org  Sun Dec  6 13:42:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Dec 2015 18:42:46 +0000
Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1449427366.63.0.191230891873.issue25810@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I recall it, in the python2 docs we used the [... notation, sometimes even when the actual arguments were or accepted keywords.  In the python3 docs we converted to always using keyword notation...and then realized that that also caused confusion, in the other direction.  Some things we converted back to [... notation.  Then argument clinic came along, and we kind of postponed worrying about it until we converted as much as practical to argument clinic.

I think we are moving toward using (and documenting in the main docs) the / notation.  Especially since it shows up in the inspect module as well as the docstring help.

Martin, if you don't think you have consensus on your patch, perhaps it is time to ping python-dev.

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

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

From report at bugs.python.org  Sun Dec  6 16:51:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Dec 2015 21:51:24 +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: <1449438683.98.0.637127467345.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay, I will look at making it say deleting via SetAttr etc is possible but is not the main purpose, and using DelAttr etc is recommended instead.

----------

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

From report at bugs.python.org  Sun Dec  6 20:14:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 07 Dec 2015 01:14:04 +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: <1449450844.03.0.113591071213.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

setattr.3.patch changes to documenting setting as the main purpose, but mentions deleting also works but is deprecated in favour of the main deletion functions. I also clarified that the slots have to support deleting via NULL.

----------
Added file: http://bugs.python.org/file41259/setattr.3.patch

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

From report at bugs.python.org  Mon Dec  7 01:28:32 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Dec 2015 06:28:32 +0000
Subject: [docs] [issue25777] Misleading descriptions in docs about invoking
 descriptors.
In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za>
Message-ID: <1449469712.54.0.0962698446678.issue25777@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Dec  7 05:02:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Dec 2015 10:02:47 +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: <1449482567.19.0.672945843528.issue25701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM. Thanks Martin.

----------

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

From report at bugs.python.org  Mon Dec  7 07:09:44 2015
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 07 Dec 2015 12:09:44 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1449490184.65.0.498882482696.issue15068@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <sweskman at gmail.com>:


----------
nosy:  -kristjan.jonsson

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

From brett at python.org  Fri Dec  4 13:09:25 2015
From: brett at python.org (brett at python.org)
Date: Fri, 04 Dec 2015 18:09:25 -0000
Subject: [docs] Wrong references to deprecated find_module instead of
 find_spec (issue 23936)
Message-ID: <20151204180925.23054.91779@psf.upfronthosting.co.za>

Overall LGTM, just some tweaks the "finder" entry to make it fairly
generic and push details down to the more concrete meta path and path
entry finder entries.


http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode313
Doc/glossary.rst:313: :meth:`find_loader` or :meth:`find_module`.
I would drop the method specifications and let people read the details
from the more concrete finder types.

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode315
Doc/glossary.rst:315: Since Python 3.3, there are two types of finder:
:term:`meta path finders
"two types of finders"

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode316
Doc/glossary.rst:316: <meta path finder>` and :term:`path entry finders
<path entry finder>`.
"meta path finders for use with sys.meta_path and path entry finders for
use with sys.path.

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

From cheljin1320 at gmail.com  Sun Dec  6 11:41:47 2015
From: cheljin1320 at gmail.com (=?UTF-8?B?QuG6o28gTmd1eeG7hW4gUXXhu5Fj?=)
Date: Sun, 6 Dec 2015 23:41:47 +0700
Subject: [docs] Python error
Message-ID: <CAN7ORwqvGJQuka=xzNL4pB0VYjFu7a9rrTF9nOBRGrPc2Au+CA@mail.gmail.com>

Dear Sir/Madam,
My name is Bao, I am a student interested in PYTHON programing.
I have some problems when I run a python code.
I already tried to search and solve the problem many times by internet, but
I can not.
So, could you help me see what is problem is that? And how can I solve this?
Please refer the attachment for your information.
I am looking forward to hearing from you.
Thanks and best regards.

Bao, Nguyen Quoc (Mr.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151206/0c593756/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code error.py
Type: text/x-python
Size: 52509 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20151206/0c593756/attachment-0002.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.py
Type: text/x-python
Size: 852 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20151206/0c593756/attachment-0003.py>

From nyctnk at gmail.com  Sun Dec  6 18:36:39 2015
From: nyctnk at gmail.com (Nadi Khalil)
Date: Sun, 6 Dec 2015 18:36:39 -0500
Subject: [docs] Building python extension with C
Message-ID: <CAEZmnqM1JF-WXHb0g1LaLuK_ZGPFoE-bCwkmXXs4k=Q2hTP=nA@mail.gmail.com>

I am looking for good example to use in Windows platform to:
- Create python module *.py
- Create C source file *.c

I need simple working steps to enable me to compile and link python module
to C module.

Appreciate information with simple working example that help me to
accomplish the above.

Best regards,
Nadi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151206/6f164f89/attachment.html>

From takowl at gmail.com  Fri Dec  4 13:17:11 2015
From: takowl at gmail.com (takowl at gmail.com)
Date: Fri, 04 Dec 2015 18:17:11 -0000
Subject: [docs] Wrong references to deprecated find_module instead of
 find_spec (issue 23936)
Message-ID: <20151204181711.23054.94019@psf.upfronthosting.co.za>


http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode313
Doc/glossary.rst:313: :meth:`find_loader` or :meth:`find_module`.
On 2015/12/04 19:09:25, brett.cannon wrote:
> I would drop the method specifications and let people read the details
from the
> more concrete finder types.

Done.

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode315
Doc/glossary.rst:315: Since Python 3.3, there are two types of finder:
:term:`meta path finders
On 2015/12/04 19:09:25, brett.cannon wrote:
> "two types of finders"

To my mind, either could be correct, but 'two types of finder' reads
much more comfortably. It may be one of those differences between
English dialects.

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode316
Doc/glossary.rst:316: <meta path finder>` and :term:`path entry finders
<path entry finder>`.
On 2015/12/04 19:09:25, brett.cannon wrote:
> "meta path finders for use with sys.meta_path and path entry finders
for use
> with sys.path.

Done.

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

From lac at openend.se  Mon Dec  7 10:36:07 2015
From: lac at openend.se (Laura Creighton)
Date: Mon, 07 Dec 2015 16:36:07 +0100
Subject: [docs] Python error
In-Reply-To: <CAN7ORwqvGJQuka=xzNL4pB0VYjFu7a9rrTF9nOBRGrPc2Au+CA@mail.gmail.com>
References: <CAN7ORwqvGJQuka=xzNL4pB0VYjFu7a9rrTF9nOBRGrPc2Au+CA@mail.gmail.com>
Message-ID: <201512071536.tB7Fa74M001900@fido.openend.se>

docs is not the place for general python support.  Please subscribe to
python-list at python.org for such questions.

https://mail.python.org/mailman/listinfo/python-list

or maybe the tutor mailing list if this is about learning python.
https://mail.python.org/mailman/listinfo/tutor

The first thing you need to do is to find the smallest bit
of python code that demonstrates the problem you are having.
Nobody wants to search through tons and tons and tons of code trying
to find one hidden error, we want a sample where the error is
quite prominent.  The second thing that you need to do is to
tell us what the problem is.  The code doesn't run and I get
this traceback (include the traceback), it runs but doesn't give
the result I wanted (I wanted this, and I got that).

Without both of the above it will be very difficult for anybody
to help you, so difficult that most people just won't bother.

Laura Creighton


In a message of Sun, 06 Dec 2015 23:41:47 +0700, B?o Nguy?n Qu?c writes:
>Dear Sir/Madam,
>My name is Bao, I am a student interested in PYTHON programing.
>I have some problems when I run a python code.
>I already tried to search and solve the problem many times by internet, but
>I can not.
>So, could you help me see what is problem is that? And how can I solve this?
>Please refer the attachment for your information.
>I am looking forward to hearing from you.
>Thanks and best regards.
>
>Bao, Nguyen Quoc (Mr.)
>
>>> text/x-python content
>>> text/x-python content
>_______________________________________________
>docs mailing list
>docs at python.org
>https://mail.python.org/mailman/listinfo/docs
>

From lac at openend.se  Mon Dec  7 10:39:04 2015
From: lac at openend.se (Laura Creighton)
Date: Mon, 07 Dec 2015 16:39:04 +0100
Subject: [docs] Building python extension with C
In-Reply-To: <CAEZmnqM1JF-WXHb0g1LaLuK_ZGPFoE-bCwkmXXs4k=Q2hTP=nA@mail.gmail.com>
References: <CAEZmnqM1JF-WXHb0g1LaLuK_ZGPFoE-bCwkmXXs4k=Q2hTP=nA@mail.gmail.com>
Message-ID: <201512071539.tB7Fd48j002158@fido.openend.se>

In a message of Sun, 06 Dec 2015 18:36:39 -0500, Nadi Khalil writes:
>I am looking for good example to use in Windows platform to:
>- Create python module *.py
>- Create C source file *.c
>
>I need simple working steps to enable me to compile and link python module
>to C module.
>
>Appreciate information with simple working example that help me to
>accomplish the above.
>
>Best regards,
>Nadi

The docs mailing list is not the place for such things.
Subscribe to python-list and ask general python programming
languages questions there.
https://mail.python.org/mailman/listinfo/python-list

Also check out Cython http://cython.org/ and see if this is what 
you are looking for.  There are lots of Cython tutorials on the net.

Laura Creighton


From report at bugs.python.org  Mon Dec  7 16:58:17 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Dec 2015 21:58:17 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1449525497.54.0.203313271514.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Your solution to the problem SGTM. And testing compile_path() can be separate method.

----------

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

From report at bugs.python.org  Mon Dec  7 18:58:32 2015
From: report at bugs.python.org (Anthony Green)
Date: Mon, 07 Dec 2015 23:58:32 +0000
Subject: [docs] [issue25821] Documentation for threading.enumerate /
 threading.Thread.is_alive is contradictory.
Message-ID: <1449532712.65.0.37494597143.issue25821@psf.upfronthosting.co.za>


Changes by Anthony Green <phoniel at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: anthonygreen, docs at python, pitrou
priority: normal
severity: normal
status: open
title: Documentation for threading.enumerate / threading.Thread.is_alive is contradictory.
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/issue25821>
_______________________________________

From report at bugs.python.org  Mon Dec  7 19:03:40 2015
From: report at bugs.python.org (Anthony Green)
Date: Tue, 08 Dec 2015 00:03:40 +0000
Subject: [docs] [issue25821] Documentation for threading.enumerate /
 threading.Thread.is_alive is contradictory.
Message-ID: <1449533020.35.0.749010589041.issue25821@psf.upfronthosting.co.za>


New submission from Anthony Green:

The documentation at https://docs.python.org/3/library/threading.html#threading.Thread.is_alive relates:

> The module function enumerate() returns a list of all alive threads.

The documentation at https://docs.python.org/3/library/threading.html#threading.enumerate relates:

> Return a list of all Thread objects currently alive. The list includes daemonic threads, dummy thread objects created by current_thread(), and the main thread.

This is a contradiction, since if the main thread has stopped, is_alive(main_thread) will return False, but it will still be included in the list returned by threading.enumerate.

Note that this is not a TOCTTOU issue. The issue is that enumerate actually includes "all alive threads, plus one [or more? I can't tell from the code] other[s]."

----------

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

From report at bugs.python.org  Mon Dec  7 19:07:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Dec 2015 00:07:35 +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: <20151208000730.90189.90197@psf.io>


Roundup Robot added the comment:

New changeset 50711c80ff76 by Martin Panter in branch '3.5':
Issue #25701: Document C API functions that both set and delete objects
https://hg.python.org/cpython/rev/50711c80ff76

New changeset 7bb7173cd97a by Martin Panter in branch 'default':
Issue #25701: Merge set and delete documentation from 3.5
https://hg.python.org/cpython/rev/7bb7173cd97a

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

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

From report at bugs.python.org  Mon Dec  7 19:09:37 2015
From: report at bugs.python.org (Anthony Green)
Date: Tue, 08 Dec 2015 00:09:37 +0000
Subject: [docs] [issue25821] Documentation for threading.enumerate /
 threading.Thread.is_alive is contradictory.
In-Reply-To: <1449533020.35.0.749010589041.issue25821@psf.upfronthosting.co.za>
Message-ID: <1449533377.75.0.642566069211.issue25821@psf.upfronthosting.co.za>


Anthony Green added the comment:

The following example comes from IRC user ztane:

> import threading, time
>
> main_thread = threading.current_thread()
> 
> def foo():
>     time.sleep(10)
>     print(main_thread.is_alive())
>     print(list(threading.enumerate()))
> 
> t = threading.Thread(target=foo)
> t.start()

False
[<_MainThread(MainThread, stopped 140040101766976)>, <Thread(Thread-1, started 140040068695808)>]

----------

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

From report at bugs.python.org  Mon Dec  7 19:12:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 08 Dec 2015 00:12:59 +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: <1449533579.81.0.386971463416.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

I committed my patch to 3.5+. I will leave this open in case someone wants to look into how things work in 2.7. I presume things might be different in Python 2; all I know is there are two kinds of classes and objects, and the slots are a bit different (__setslice__?).

----------
versions:  -Python 3.4

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

From report at bugs.python.org  Tue Dec  8 04:45:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Dec 2015 09:45:33 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1449567933.21.0.71314918048.issue22341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM.

But while we are here, wouldn't be worth to unify the name of second parameter of binascii and zlib CRC calculation functions? And unify the description of crc_hqx() with other functions.

----------

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

From report at bugs.python.org  Tue Dec  8 05:15:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Dec 2015 10:15:31 +0000
Subject: [docs] [issue21240] Add an abstactmethod directive to the Python
 ReST domain
In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za>
Message-ID: <20151208101528.1968.28881@psf.io>


Roundup Robot added the comment:

New changeset 1d0d8b27a4e6 by Berker Peksag in branch '3.5':
Issue #21240: Add an abstractmethod directive to mark abstract methods in the docs more explicitly
https://hg.python.org/cpython/rev/1d0d8b27a4e6

New changeset 84468e1aea61 by Berker Peksag in branch 'default':
Issue #21240: Add an abstractmethod directive to mark abstract methods in the docs more explicitly
https://hg.python.org/cpython/rev/84468e1aea61

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

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

From report at bugs.python.org  Tue Dec  8 05:21:14 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 08 Dec 2015 10:21:14 +0000
Subject: [docs] [issue21240] Add an abstactmethod directive to the Python
 ReST domain
In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za>
Message-ID: <1449570074.39.0.0288117107536.issue21240@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for reminding me of this issue, Brett. I have also updated numbers and selectors docs to use the new directive.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

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

From magiccatinteractive at gmail.com  Mon Dec  7 13:02:26 2015
From: magiccatinteractive at gmail.com (Blake Blackwell)
Date: Mon, 7 Dec 2015 13:02:26 -0500
Subject: [docs] Docs
Message-ID: <F4C9339F-0F8D-435E-B1D5-3AB646C767D6@gmail.com>

Hello, I am trying to download the documentation for my python version (3.5) and I keep getting this error for every download link and file extension

404 Not Found

nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151207/411fd7ae/attachment.html>

From tritium-list at sdamon.com  Tue Dec  8 06:50:25 2015
From: tritium-list at sdamon.com (Alexander Walters)
Date: Tue, 08 Dec 2015 06:50:25 -0500
Subject: [docs] css/rendering issue with 2.7.11 docs?
Message-ID: <5666C401.6070600@sdamon.com>

The names of modules in the side navigation show up with a white 
background, with light green text - which is not very readable.

http://i.imgur.com/Q7aV50r.png

http://i.imgur.com/VdsvBzH.png

I am using Firefox 42.0 on windows 10.

From lac at openend.se  Tue Dec  8 08:18:55 2015
From: lac at openend.se (Laura Creighton)
Date: Tue, 08 Dec 2015 14:18:55 +0100
Subject: [docs] Docs
In-Reply-To: <F4C9339F-0F8D-435E-B1D5-3AB646C767D6@gmail.com>
References: <F4C9339F-0F8D-435E-B1D5-3AB646C767D6@gmail.com>
Message-ID: <201512081318.tB8DItwq027567@fido.openend.se>

In a message of Mon, 07 Dec 2015 13:02:26 -0500, Blake Blackwell writes:
>Hello, I am trying to download the documentation for my python version (3.5) and I keep getting this error for every download link and file extension
>
>404 Not Found
>
>nginx

You may need to clear your cache.
We put up new docs on the 6th of Decemeber.
Are you trying to get your docs here:
https://docs.python.org/3.5/download.html

or someplace else?

Laura Creighton


From zachary.ware+pydocs at gmail.com  Tue Dec  8 12:56:17 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 8 Dec 2015 11:56:17 -0600
Subject: [docs] sum( ) in generator bugged
In-Reply-To: <565851E4.7070405@anselm.kiefner.de>
References: <565851E4.7070405@anselm.kiefner.de>
Message-ID: <CAKJDb-P9rLc38irxRFnM=m8_g3Pr1cTHbhcicAxvy9mge7O36Q@mail.gmail.com>

Hi Anselm,

On Fri, Nov 27, 2015 at 6:51 AM, Anselm Kiefner
<python at anselm.kiefner.de> wrote:
> 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.

First off, this is not the place to report bugs; that should be done
on the bug tracker or reported to python-list at python.org (and someone
there will either explain why it's not a bug, or make sure it's
reported properly).  This list is for discussion about the
documentation of Python rather than its inner workings (except where
that affects the documentation :)).

However, this is not a bug in Python, but rather in your expectations.
In `b = (x*sum(L_g) for x in L_g)` you're trying to loop over the same
iterator multiple times, which actually works out such that `for x in
L_g` consumes the first value (1), then `x*sum(L_g)` consumes the rest
(2, 3), so `x*sum(L_g)` expands to `1*(2 + 3)`, which gives 5.  Next
time around the loop, L_g is already exhausted, so the for loop ends.
If you want to iterate over the same values multiple times, you need
either a concrete list of the values, or to calculate the values
separately on every iteration.  Either of the following will work the
way you expected in the first place; performance will depend on your
real use case; if you're concerned about memory use but have cycles to
spare, go for the first; if you have memory but want shorter runtime,
go for the second.

First:
   >>> L = [1,2,3]
   >>> def gen(lst):
   ...     for x in lst:
   ...         yield x
   ...
   >>> b = (x * sum(gen(L)) for x in gen(L))
   >>> list(b)
   [6, 12, 18]

Second:
   >>> g_L = list(x for x in L)
   >>> b2 = (x*sum(g_L) for x in g_L)
   >>> list(b2)
   [6, 12, 18]

Hope this helps,
-- 
Zach

From python at anselm.kiefner.de  Tue Dec  8 16:08:37 2015
From: python at anselm.kiefner.de (Anselm Kiefner)
Date: Tue, 8 Dec 2015 22:08:37 +0100
Subject: [docs] sum( ) in generator bugged
In-Reply-To: <CAKJDb-P9rLc38irxRFnM=m8_g3Pr1cTHbhcicAxvy9mge7O36Q@mail.gmail.com>
References: <565851E4.7070405@anselm.kiefner.de>
 <CAKJDb-P9rLc38irxRFnM=m8_g3Pr1cTHbhcicAxvy9mge7O36Q@mail.gmail.com>
Message-ID: <566746D5.1010003@anselm.kiefner.de>

Hey Zach,

Thanks for your answer and explanation.
I just posted here following the advice on
https://docs.python.org/3.5/bugs.html ("If you?re short on time, you can
also email your bug report to docs at python.org. ?docs@? is a mailing list
run by volunteers; your request will be noticed, though it may take a
while to be processed.").

Now, I'm fairly aware how that code works and how to work around it, but
I must say I almost felt insulted by your claim that my "expectations
are bugged". Considering the Zen of Python ("There should be one - and
preferrably only one- obvious way to do it") and the Principle of least
astonishment I'd rather argue that my expectations on this one are
rather well within what could be considered normal.

When I, as a user, replace a list or a list comprehension with a
generator - that is simply by replacing [] with (), I would expect that
the items are now generated on the fly and not held in memory anymore
(that's the speed to memory tradeoff you were talking about) - but the
result of both should be the same, logically.
This is also how it works in most cases without any trouble.

Now, applying sum() on a list in general returns the same result as it
does when applied on a generator, and it works as expected inside the
list comprehension when applied on the list. So you see, the described
behaviour of sum() applied on a generator inside a list comprehension is
clearly an exception of the general behaviour.
Let me quote the Zen of Python again: Special cases aren't special
enough to break the rules.

Yes, surely there are ways to work around it, but I hope you agree now
that this is not a flaw in my expectations rather than in the code.

Thanks for your time and kind regards,
Anselm





Am 08.12.2015 um 18:56 schrieb Zachary Ware:
> Hi Anselm,
> 
> On Fri, Nov 27, 2015 at 6:51 AM, Anselm Kiefner
> <python at anselm.kiefner.de> wrote:
>> 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.
> 
> First off, this is not the place to report bugs; that should be done
> on the bug tracker or reported to python-list at python.org (and someone
> there will either explain why it's not a bug, or make sure it's
> reported properly).  This list is for discussion about the
> documentation of Python rather than its inner workings (except where
> that affects the documentation :)).
> 
> However, this is not a bug in Python, but rather in your expectations.
> In `b = (x*sum(L_g) for x in L_g)` you're trying to loop over the same
> iterator multiple times, which actually works out such that `for x in
> L_g` consumes the first value (1), then `x*sum(L_g)` consumes the rest
> (2, 3), so `x*sum(L_g)` expands to `1*(2 + 3)`, which gives 5.  Next
> time around the loop, L_g is already exhausted, so the for loop ends.
> If you want to iterate over the same values multiple times, you need
> either a concrete list of the values, or to calculate the values
> separately on every iteration.  Either of the following will work the
> way you expected in the first place; performance will depend on your
> real use case; if you're concerned about memory use but have cycles to
> spare, go for the first; if you have memory but want shorter runtime,
> go for the second.
> 
> First:
>    >>> L = [1,2,3]
>    >>> def gen(lst):
>    ...     for x in lst:
>    ...         yield x
>    ...
>    >>> b = (x * sum(gen(L)) for x in gen(L))
>    >>> list(b)
>    [6, 12, 18]
> 
> Second:
>    >>> g_L = list(x for x in L)
>    >>> b2 = (x*sum(g_L) for x in g_L)
>    >>> list(b2)
>    [6, 12, 18]
> 
> Hope this helps,
> 

From lac at openend.se  Tue Dec  8 23:09:00 2015
From: lac at openend.se (Laura Creighton)
Date: Wed, 09 Dec 2015 05:09:00 +0100
Subject: [docs] sending bugs to docs ... was  sum( ) in generator
In-Reply-To: <566746D5.1010003@anselm.kiefner.de>
References: <565851E4.7070405@anselm.kiefner.de>
 <CAKJDb-P9rLc38irxRFnM=m8_g3Pr1cTHbhcicAxvy9mge7O36Q@mail.gmail.com>
 <566746D5.1010003@anselm.kiefner.de>
Message-ID: <201512090409.tB9490F5021923@fido.openend.se>

re: https://docs.python.org/3.5/bugs.html 
("If you?re short on time, you can also email your bug report to 
docs at python.org. ?docs@? is a mailing list run by volunteers; your 
request will be noticed, though it may take a
while to be processed.").

Should we change this?  

Laura


From zachary.ware+pydocs at gmail.com  Tue Dec  8 23:13:43 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 8 Dec 2015 22:13:43 -0600
Subject: [docs] sending bugs to docs ... was sum( ) in generator
In-Reply-To: <201512090409.tB9490F5021923@fido.openend.se>
References: <565851E4.7070405@anselm.kiefner.de>
 <CAKJDb-P9rLc38irxRFnM=m8_g3Pr1cTHbhcicAxvy9mge7O36Q@mail.gmail.com>
 <566746D5.1010003@anselm.kiefner.de>
 <201512090409.tB9490F5021923@fido.openend.se>
Message-ID: <CAKJDb-M2Q4N3LH4VaE0VVqDDRb+_3=KAr=c+zZEU9yXv-+Ftww@mail.gmail.com>

On Tue, Dec 8, 2015 at 10:09 PM, Laura Creighton <lac at openend.se> wrote:
> re: https://docs.python.org/3.5/bugs.html
> ("If you?re short on time, you can also email your bug report to
> docs at python.org. ?docs@? is a mailing list run by volunteers; your
> request will be noticed, though it may take a
> while to be processed.").
>
> Should we change this?

Yes.  The intention was '...email your *documentation* bug report...'
since the section is about documentation bugs, but apparently it's
being taken more generally.  I will get a fix in soon, unless somebody
beats me to it.

-- 
Zach

From report at bugs.python.org  Tue Dec  8 23:47:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 09 Dec 2015 04:47:14 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1449636434.79.0.50037140353.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

In crc-sign.v5.patch I have changed the binascii.crc_hqx() and crc32() documentation to use ?value?, matching the zlib documentation. Is that what you had in mind?

----------
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41271/crc-sign.v5.patch

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

From report at bugs.python.org  Wed Dec  9 01:56:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Dec 2015 06:56:31 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1449644191.19.0.636992716698.issue22341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, thank you Martin.

----------
assignee: docs at python -> martin.panter
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Dec  9 02:58:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Dec 2015 07:58:43 +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: <1449647923.84.0.577094292212.issue23200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

After reading zlib manual it looks to me that your are right, flush() has no other effect except a little less memory consumption. This can be not important in the context of Python. Hope Nadeem will confirm this.

----------
assignee: docs at python -> nadeem.vawda
type:  -> enhancement

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

From report at bugs.python.org  Wed Dec  9 03:54:06 2015
From: report at bugs.python.org (Ian Macartney)
Date: Wed, 09 Dec 2015 08:54:06 +0000
Subject: [docs] [issue25787] Add an explanation what happens with subprocess
 parent and child processes when signals are sent
In-Reply-To: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za>
Message-ID: <1449651246.72.0.225714961371.issue25787@psf.upfronthosting.co.za>


Ian Macartney added the comment:

I don't have much experience with what should and shouldn't be in the python docs, however I was recently bitten by a subtlety in signal/subprocess that might be worth documenting.

Anything written to stdout in a signal handler could end up in the stdout of a process returned by Popen, if stdout gets flushed in the signal handler during a critical part of the Popen call. Furthermore, any output buffered before calling Popen could also be flushed by the signal handler, showing up in the child process's stdout. The same goes for stderr.

On 2.7.7 at least, the window where this can happen is between lines 1268-1290 in subprocess.py, where the child process has duplicated stdout, but hasn't yet called execvp.

This is a result of signal inheritance that caught me off guard, and wasn't clear to me by reading the documentation.

----------
nosy: +Ian Macartney
Added file: http://bugs.python.org/file41273/bug.py

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

From report at bugs.python.org  Wed Dec  9 05:32:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 09 Dec 2015 10:32:22 +0000
Subject: [docs] [issue25787] Add an explanation what happens with subprocess
 parent and child processes when signals are sent
In-Reply-To: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za>
Message-ID: <1449657142.56.0.949375453565.issue25787@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Karl?s original report was mainly about normal signal handling in the long term in the child, i.e. behaviour after exec() succeeds.

Ian, your problem sounds more like a bug or unfortunate quirk of the window between fork() and exec(). Maybe it is possible to solve it by blocking or resetting signal handlers, or using posix_spawn() (Issue 20104).

----------

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

From zachary.ware+pydocs at gmail.com  Wed Dec  9 15:10:21 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 9 Dec 2015 14:10:21 -0600
Subject: [docs] sum( ) in generator bugged
In-Reply-To: <566746D5.1010003@anselm.kiefner.de>
References: <565851E4.7070405@anselm.kiefner.de>
 <CAKJDb-P9rLc38irxRFnM=m8_g3Pr1cTHbhcicAxvy9mge7O36Q@mail.gmail.com>
 <566746D5.1010003@anselm.kiefner.de>
Message-ID: <CAKJDb-Pr2RiL0Gpqi+z6mu8AkCM2f5EWTrB7VtuT22YHUT232g@mail.gmail.com>

On Tue, Dec 8, 2015 at 3:08 PM, Anselm Kiefner <python at anselm.kiefner.de> wrote:
> Hey Zach,
>
> Thanks for your answer and explanation.
> I just posted here following the advice on
> https://docs.python.org/3.5/bugs.html ("If you?re short on time, you can
> also email your bug report to docs at python.org. ?docs@? is a mailing list
> run by volunteers; your request will be noticed, though it may take a
> while to be processed.").

Ah, that line is meant for documentation bugs; I've clarified the
wording.  For further discussion on this issue, please send your
message to python-list at python.org.

> Now, I'm fairly aware how that code works and how to work around it, but
> I must say I almost felt insulted by your claim that my "expectations
> are bugged".

My apologies; insulting was far from my intent.

> Considering the Zen of Python ("There should be one - and
> preferrably only one- obvious way to do it") and the Principle of least
> astonishment I'd rather argue that my expectations on this one are
> rather well within what could be considered normal.
>
> When I, as a user, replace a list or a list comprehension with a
> generator - that is simply by replacing [] with (), I would expect that
> the items are now generated on the fly and not held in memory anymore
> (that's the speed to memory tradeoff you were talking about) - but the
> result of both should be the same, logically.
> This is also how it works in most cases without any trouble.

As long as you don't try to iterate over the generator more than once.

> Now, applying sum() on a list in general returns the same result as it
> does when applied on a generator, and it works as expected inside the
> list comprehension when applied on the list. So you see, the described
> behaviour of sum() applied on a generator inside a list comprehension is
> clearly an exception of the general behaviour.

How should `sum` behave differently?  A generator is a one-shot
iterator, it cannot be reset (how would you reset a generator that
yields random values?).  `sum` is just a consumer of iterables, just
like `list()`, `max()`, `any()`, 'for' loops, comprehensions, and
generator expressions.  All of those follow the same protocol: call
`iter()` on the iterable, whose __iter__() method returns some object
with a __next__() method (an iterator), then call next() on that
object until __next__() raises StopIteration.

For the record, just replacing [] with () makes no difference.  Your
example 'a' (`a = [x*sum(L) for x in L]`) is a list comprehension that
iterates over a list multiple times.  Your example 'b' (`b =
(x*sum(L_g) for x in L_g)`) is a generator expression that attempts to
iterate over a generator multiple times.  It's the second change that
makes the difference; `c = (x*sum(L) for x in L)` would give the same
result as 'a', as would `d = (x*sum(L) for x in L_g)`.  This would
give the same answer as b: `e = [x*sum(L_g) for x in L_g]`.  This
would give an entirely different answer: `f = [x*sum(L_g) for x in
L]`.

> Let me quote the Zen of Python again: Special cases aren't special
> enough to break the rules.

I'm not clear on what is breaking what rule.  Everything is following
the iterator protocol, which is documented here:
https://docs.python.org/3/library/stdtypes.html#typeiter

> Yes, surely there are ways to work around it, but I hope you agree now
> that this is not a flaw in my expectations rather than in the code.

The examples I gave in my previous message were not workarounds, they
were the two options you have to get what you expected while using
generators everywhere.  If you want a reusable lazy iterator, you'll
need something other than a generator.

I'm sorry if I'm not explaining things well.  You may have better luck
starting a thread on python-list; there are several knowledgable
people there who are quite willing to explain the finer points of
things like this better than I can.

Regards,
-- 
Zach

From report at bugs.python.org  Wed Dec  9 16:17:49 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Wed, 09 Dec 2015 21:17:49 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1449695869.35.0.513446282825.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

I've added the tests as we discussed. A couple of comments:

* I found it difficult to reuse the existing setUp() code so had to essentially repeat a bunch of very similar code to create "bad" files. Let me know if you think there is a better way to do this.
* I'm having trouble with the test for compile_path(). Specifically, it doesn't seem to actually use the value for skip_curdir. Do you understand why?

----------
Added file: http://bugs.python.org/file41277/compileall.patch

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

From report at bugs.python.org  Wed Dec  9 16:42:41 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 09 Dec 2015 21:42:41 +0000
Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1449697361.24.0.173217530956.issue5501@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Hi everyone!
It has been a while since this issue has been updated. 
The addition requested by Brandon Corfman is a simple clarification of what happens when the freeze_support function from multiprocessing is called on non-Windows platforms (if I understand correctly, the primary purpose of freeze_support is to help in creating Windows executables). 
Although there is already some documentation which suggests that no adverse effects will occur when running code that calls freeze_support on OS X and Unix, I added a sentence in the docs that will hopefully clarify this. 

Patch attached.

----------
keywords: +patch
nosy: +Winterflower
Added file: http://bugs.python.org/file41278/issue5501-v1.patch

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

From anna at whoishostingthismail.com  Wed Dec  9 22:30:54 2015
From: anna at whoishostingthismail.com (anna at whoishostingthismail.com)
Date: Thu, 10 Dec 2015 11:30:54 +0800
Subject: [docs] Quick message - This link is broken
Message-ID: <52ab11aa70e139a06062f35146d8df62@whoishostingthismail.com>

Hi,

I've been compiling resources to include in our guide to MPI and I came 
across a link that isn't working on your site.

It's on this page: http://pyacts.sourceforge.net/

I'm getting an error message when I visit this link: 
http://www-unix.mcs.anl.gov/mpi/mpich/

If you are planning on updating this page on your site, perhaps our 
guide to MPI -  http://wiht.link/MPIguide would make a suitable 
replacement.

Anna



From report at bugs.python.org  Thu Dec 10 09:08:20 2015
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 10 Dec 2015 14:08:20 +0000
Subject: [docs] [issue25832] Document weird behavior of `finally` when it
 has `break` in it
Message-ID: <1449756500.07.0.727119628461.issue25832@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Today I spent 30 minutes because of weird behavior of `finally` when it has a `break` statement inside of it. (The behavior is that the exception gets suppressed, which I found unexpected.) I think this behavior should be documented.

Example:

    
    
    c:\Users\Administrator\Desktop>cat s.py                    
    for x in [1, 2, 3]:                                        
      try:                                                     
        1/0                                                    
      finally:                                                 
        break                                                  
    print(x)                                                   
                                                              
    c:\Users\Administrator\Desktop>c:\Python34\python.exe s.py 
    1

----------
assignee: docs at python
components: Documentation
messages: 256173
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: Document weird behavior of `finally` when it has `break` in it
type: enhancement

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

From report at bugs.python.org  Thu Dec 10 09:59:33 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 10 Dec 2015 14:59:33 +0000
Subject: [docs] [issue25832] Document weird behavior of `finally` when it
 has `break` in it
In-Reply-To: <1449756500.07.0.727119628461.issue25832@psf.upfronthosting.co.za>
Message-ID: <1449759573.79.0.301704018103.issue25832@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

You used explicit control flow keywords and you're surprised that it listened?

Regardless, this is already documented https://docs.python.org/3/reference/compound_stmts.html#finally :

"If the finally clause executes a return or break statement, the saved exception is discarded"

----------
nosy: +josh.r

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

From report at bugs.python.org  Thu Dec 10 10:06:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Dec 2015 15:06:11 +0000
Subject: [docs] [issue25832] Document weird behavior of `finally` when it
 has `break` in it
In-Reply-To: <1449756500.07.0.727119628461.issue25832@psf.upfronthosting.co.za>
Message-ID: <1449759971.34.0.846623968792.issue25832@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Dec 10 23:13:55 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 11 Dec 2015 04:13:55 +0000
Subject: [docs] [issue25836] Documentation of MAKE_FUNCTION is still
 incorrect
Message-ID: <1449807235.86.0.17166679506.issue25836@psf.upfronthosting.co.za>


New submission from Russell Keith-Magee:

Refs Issue16554, Issue13026, Issue14349, and probably others.

The documentation for the interpretation of the argc argument to MAKE_FUNCTION in Doc/library/dis.rst is incorrect. 

As of 13 August 2015, the docs say:

"""
Pushes a new function object on the stack.  From bottom to top, the consumed
stack must consist of:

   * ``argc & 0xFF`` default argument objects in positional order
   * ``(argc >> 8) & 0xFF`` pairs of name and default argument, with the name
     just below the object on the stack, for keyword-only parameters
   * ``(argc >> 16) & 0x7FFF`` parameter annotation objects
   * a tuple listing the parameter names for the annotations (only if there are
     ony annotation objects)
   * the code associated with the function (at TOS1)
   * the :term:`qualified name` of the function (at TOS)
"""

However, this doesn't capture the fact that:

 * if there are annotations, the number of default arguments returned by `argc & 0xFF` must be reduced by `(argc >> 16) & 0x7FFF`

 * The value `(argc >> 16) & 0x7FFF` for the number of annotations *includes* the "extra" entry for the tuple describing which arguments the annotations apply to. This means that `(argc >> 16) & 0x7FFF` will be either 0, or 2+; it can't be 1 (because if you have one annotation, you must also have a tuple describing which arguments is annotated).

----------
assignee: docs at python
components: Documentation
messages: 256189
nosy: docs at python, freakboy3742
priority: normal
severity: normal
status: open
title: Documentation of MAKE_FUNCTION is still incorrect
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/issue25836>
_______________________________________

From report at bugs.python.org  Thu Dec 10 23:14:44 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 11 Dec 2015 04:14:44 +0000
Subject: [docs] [issue25836] Documentation of MAKE_FUNCTION is still
 incorrect
In-Reply-To: <1449807235.86.0.17166679506.issue25836@psf.upfronthosting.co.za>
Message-ID: <1449807284.35.0.390307024463.issue25836@psf.upfronthosting.co.za>


Changes by Russell Keith-Magee <freakboy3742 at gmail.com>:


----------
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Dec 11 01:04:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Dec 2015 06:04:45 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <20151211060442.11505.13582@psf.io>


Roundup Robot added the comment:

New changeset 03c4ca1a34e2 by Martin Panter in branch '3.5':
Issue #22341: Drop Python 2 workaround and document CRC initial value
https://hg.python.org/cpython/rev/03c4ca1a34e2

New changeset 360c1326d8d1 by Martin Panter in branch 'default':
Issue #22341: Merge CRC doc from 3.5
https://hg.python.org/cpython/rev/360c1326d8d1

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

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

From report at bugs.python.org  Fri Dec 11 01:07:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 11 Dec 2015 06:07:02 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1449814022.75.0.0507313727502.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the reviews

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

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

From ryano.mcc13 at gmail.com  Thu Dec 10 19:30:57 2015
From: ryano.mcc13 at gmail.com (Ryan McCafferty)
Date: Thu, 10 Dec 2015 19:30:57 -0500
Subject: [docs] Found a bug in the os.path.join function
Message-ID: <CALpOjJkUUWSyLZWoywbQaLfJV_=_w=B53ngiQnOweBZnix9__g@mail.gmail.com>

Hello,

I am running python v3.4.2 on a Raspberry Pi 2 running raspbian jesse. I
found what I think is a bug with the os.path.join function. When passing
multiple arguments to this function, which is usually the case, if any of
the arguments contain a leading slash, all of the arguments that come
before the one with the leading slash get truncated from the resulting path.

>>> os.path.join('a', 'b', 'c')
'a/b/c'   # this is expected
>>> os.path.join('a', '/b', 'c')
'/b/c'   # expecting a/b/c
>>> os.path.join('a', 'b', '/c')
'/c'      # expecting a/b/c
>>> os.path.join('a', '/b', '/c')
'/c'      # expecting a/b/c

?
I think this is a bug, because I believe the reasoning for these path join
functions is so users do not have to worry about which path components
contain leading or trailing slashes.

Thank you,

Ryan McCafferty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151210/be0c72b8/attachment.html>

From mail at timgolden.me.uk  Fri Dec 11 01:13:47 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Fri, 11 Dec 2015 06:13:47 +0000
Subject: [docs] Found a bug in the os.path.join function
In-Reply-To: <CALpOjJkUUWSyLZWoywbQaLfJV_=_w=B53ngiQnOweBZnix9__g@mail.gmail.com>
References: <CALpOjJkUUWSyLZWoywbQaLfJV_=_w=B53ngiQnOweBZnix9__g@mail.gmail.com>
Message-ID: <566A699B.4040602@timgolden.me.uk>

On 11/12/2015 00:30, Ryan McCafferty wrote:
> Hello,
>
> I am running python v3.4.2 on a Raspberry Pi 2 running raspbian jesse. I
> found what I think is a bug with the os.path.join function. When passing
> multiple arguments to this function, which is usually the case, if any
> of the arguments contain a leading slash, all of the arguments that come
> before the one with the leading slash get truncated from the resulting path.
>
> | >>> os.path.join('a', 'b', 'c') 'a/b/c' # this is expected >>>
> os.path.join('a', '/b', 'c') '/b/c' # expecting a/b/c >>>
> os.path.join('a', 'b', '/c') '/c' # expecting a/b/c >>>
> os.path.join('a', '/b', '/c') '/c' # expecting a/b/c |
>
> ?
> I think this is a bug, because I believe the reasoning for these path
> join functions is so users do not have to worry about which path
> components contain leading or trailing slashes.

Ryan, the documentation for os.path.join:

   https://docs.python.org/3.4/library/os.path.html#os.path.join

explicitly mentions this behaviour: "...  If a component is an absolute 
path, all previous components are thrown away and joining continues from 
the absolute path component."

So, while it might not match your intuition, it's not a bug either in 
the code or in the docs.

TJG

From report at bugs.python.org  Fri Dec 11 01:25:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 11 Dec 2015 06:25:13 +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: <1449815113.32.0.949783076367.issue25666@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think I figured out the problem. The signal module has a ?main_pid? variable which it checks inside the low-level handler: <https://hg.python.org/cpython/file/v3.5.1/Modules/signalmodule.c#l300>. It looks like main_pid gets updated inside PyOS_AfterFork(), but I guess there is a race with a signal being received before main_pid is updated.

Maybe there should be some signal masking/blocking or something in the critical section between fork() and PyOS_AfterFork()?

----------
versions:  -Python 3.4

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

From report at bugs.python.org  Fri Dec 11 10:42:25 2015
From: report at bugs.python.org (Denis Savenko)
Date: Fri, 11 Dec 2015 15:42:25 +0000
Subject: [docs] [issue25841] In FancyURLopener error in example with http
 address.
Message-ID: <1449848545.54.0.701964592914.issue25841@psf.upfronthosting.co.za>


New submission from Denis Savenko:

In documentation from this page https://docs.python.org/3.5/library/urllib.request.html#examples in examples uses default address to python site with http. ( http://python.org/ ). But now python.org use https. When i try use example in ipython i get I/0 error, but error is very simple - http change by https. I found this error on many pages, where use http://python.org/ address, but on FancyURLopener example compiller error very difficult for understanding.

----------
assignee: docs at python
components: Documentation
messages: 256221
nosy: Denis Savenko, docs at python
priority: normal
severity: normal
status: open
title: In FancyURLopener error in example with http address.
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Dec 11 10:47:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Dec 2015 15:47:56 +0000
Subject: [docs] [issue25841] In FancyURLopener error in example with http
 address.
In-Reply-To: <1449848545.54.0.701964592914.issue25841@psf.upfronthosting.co.za>
Message-ID: <1449848876.74.0.797891222108.issue25841@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
versions: +Python 2.7 -Python 3.3, Python 3.4

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

From leewangzhong+python at gmail.com  Fri Dec 11 15:27:19 2015
From: leewangzhong+python at gmail.com (Franklin? Lee)
Date: Fri, 11 Dec 2015 15:27:19 -0500
Subject: [docs] `contextlib.contextmanager` should include example with
 exception-handling
Message-ID: <CAB_e7iy+YAz4F4+CFRr2KGAjjthwWBeAPFJvuD8t7Cz7iJ-_dg@mail.gmail.com>

(Link to docs: https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager)

I was surprised when I tried to use `contextmanager` with a block that
threw an exception. After flailing around a bit on the REPL, I read
the docs more carefully and saw that I had to wrap the `yield` with a
`try-finally` block.

I first learned about the `with` statement as a way to open files and
guarantee (to some extent) that they'll be closed even if something
went wrong. I associate `with` with C++'s RAII, where destructors are
used to guarantee things happening at the end of scope. With that
intuition, it was surprising to me that the default behavior did not
handle exceptions, er, for me.

I admit I could have been more careful, but maybe others have the same
intuition, and would benefit from try-finally standing out more (i.e.
an example) on that page.

From report at bugs.python.org  Fri Dec 11 18:22:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 11 Dec 2015 23:22:45 +0000
Subject: [docs] [issue25730] invisible sidebar content with code snippets
In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za>
Message-ID: <1449876165.82.0.465353020293.issue25730@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This can be reproduced at https://docs.python.org/3/faq/windows.html

You can find the CSS file at Doc/tools/pydoctheme/static/pydoctheme.css. You can override .highlight there, but the actual problem is that Sphinx creates the outer highlight-python3 div with "position: relative;". I think your CSS fix is good enough to commit. Thanks!

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Fri Dec 11 19:12:40 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 12 Dec 2015 00:12:40 +0000
Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1449879160.16.0.59090303708.issue5501@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +davin

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

From report at bugs.python.org  Fri Dec 11 20:59:32 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Dec 2015 01:59:32 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1449885572.62.0.916992210498.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Do the tests take much longer with all of the added stuff in setUp()/tearDown()? It's just that all of it has to run for all tests. You could make a mixin or put all of it in a method that you selectively call and which registers the proper cleanup method.

As for skip_curdir, if you look at https://hg.python.org/cpython/file/default/Lib/compileall.py#l188 you will notice it requires the current directory to be on sys.path and I don't see you make any such change to sys.path (and if you do you can use test_importlib.util.import_state to temporarily mutate sys.path (https://hg.python.org/cpython/file/default/Lib/test/test_importlib/util.py#l165).

----------

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

From report at bugs.python.org  Fri Dec 11 22:21:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 12 Dec 2015 03:21:58 +0000
Subject: [docs] [issue25841] In FancyURLopener error in example with http
 address.
In-Reply-To: <1449848545.54.0.701964592914.issue25841@psf.upfronthosting.co.za>
Message-ID: <1449890518.58.0.862120916585.issue25841@psf.upfronthosting.co.za>


Martin Panter added the comment:

Assuming you meant http://www.python.org/ (added the www), I cannot produce any error with any example that requests directly to the site. The ?http:? server already redirects to ?https:?, so there is no problem. Obviously the examples that depend on made-up servers like proxy.example.com are going to fail.

In particular, the second FancyURLopener example works for me. Modified slightly to avoid copious output:

$ python3.5 -bWall
Python 3.5.0 (default, Sep 20 2015, 11:28:25) 
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>> opener = urllib.request.FancyURLopener({})
__main__:1: DeprecationWarning: FancyURLopener style of invoking requests is deprecated. Use newer urlopen functions/methods
>>> with opener.open("http://www.python.org/") as f:
...     response = f.read().decode('utf-8')
... 
>>> response[:100]
'<!doctype html>\n<!--[if lt IE 7]>   <html class="no-js ie6 lt-ie7 lt-ie8 lt-ie9">   <![endif]-->\n<!-'

Please try this in the plain Python interpreter rather than I-Python, or be more specific about what you are trying to do and what the result is.

BTW I dunno what the FancyUrlopener example is doing there. In the Python 3 documentation, FancyURLopener is not introduced until the ?Legacy interface? section later on. Perhaps the example should be moved.

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

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

From report at bugs.python.org  Sat Dec 12 05:09:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Dec 2015 10:09:36 +0000
Subject: [docs] [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1449914976.77.0.777636289962.issue16394@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec 13 18:15:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Dec 2015 23:15:07 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <20151213231503.13590.78777@psf.io>


Roundup Robot added the comment:

New changeset 7b137466e879 by R David Murray in branch '2.7':
#25495: Clarify b2a_base64 documentation vis 57 bytes.
https://hg.python.org/cpython/rev/7b137466e879

New changeset 3d5bf9bd15a3 by R David Murray in branch '3.4':
#25495: Clarify b2a_base64 documentation vis 57 bytes.
https://hg.python.org/cpython/rev/3d5bf9bd15a3

New changeset ea9951598bab by R David Murray in branch '3.5':
Merge: #25495: Clarify b2a_base64 documentation vis 57 bytes.
https://hg.python.org/cpython/rev/ea9951598bab

New changeset 35650db28afe by R David Murray in branch 'default':
Merge: #25495: Clarify b2a_base64 documentation vis 57 bytes.
https://hg.python.org/cpython/rev/35650db28afe

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

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

From report at bugs.python.org  Sun Dec 13 18:16:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Dec 2015 23:16:59 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1450048619.63.0.155714019451.issue25495@psf.upfronthosting.co.za>


R. David Murray added the comment:

I kept the 57 as part of an historical note explaining why the newline is added.  I dropped that sentence in the 3.6 docs, where a keyword to control the apending of the newline has been added.

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

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

From report at bugs.python.org  Sun Dec 13 19:40:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2015 00:40:47 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450053647.64.0.572958169635.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

I started tweaking this patch, and wound up going through the whole doc and fixing the references to 'byte string' and 'string' throughout, as well as making all the entries consistent in how they reference the function arguments and output (previously some did not reference the output at all, nor was it clear that the output is always bytes).  I believe I also clarified some confusing wordings along the way.

Since there are so many changes I need some eyes checking my work before I commit.

Note that the primary motivation for this change (the incorrect claim that both interfaces supported the RFC) is not made by the 2.7 docs, and since those docs are very different now, I don't plan to touch them.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file41296/issue-01753718.patch

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

From report at bugs.python.org  Sun Dec 13 20:30:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Dec 2015 01:30:39 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1450056639.58.0.165188912593.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for fixing this up David

----------

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

From report at bugs.python.org  Sun Dec 13 21:45:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Dec 2015 02:45:02 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450061102.57.0.281835774413.issue1753718@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left some review comments. I left a comment about the original patch as well, because I didn?t notice the new patch in time :)

Also, maybe we should say the input to the ?legacy? MIME decode() function should be multiple lines, since it calls readline() with no line limit.

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

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

From report at bugs.python.org  Sun Dec 13 21:58:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Dec 2015 02:58:17 +0000
Subject: [docs] [issue20837] Ambiguity words in base64 documentation
In-Reply-To: <1393803500.52.0.641070246037.issue20837@psf.upfronthosting.co.za>
Message-ID: <20151214025813.2700.69092@psf.io>


Roundup Robot added the comment:

New changeset e8cbebb273c6 by Martin Panter in branch '2.7':
Issue #20837: Base-64 alphabet clarification from revision 1853679c6f71
https://hg.python.org/cpython/rev/e8cbebb273c6

----------

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

From report at bugs.python.org  Sun Dec 13 22:01:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Dec 2015 03:01:24 +0000
Subject: [docs] [issue20837] Ambiguity words in base64 documentation
In-Reply-To: <1393803500.52.0.641070246037.issue20837@psf.upfronthosting.co.za>
Message-ID: <1450062084.88.0.60478884464.issue20837@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think it is too late for 3.3 now, but I did port the relevant bit to 2.7.

----------
nosy: +martin.panter
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7 -Python 3.3

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

From report at bugs.python.org  Mon Dec 14 00:14:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Dec 2015 05:14:47 +0000
Subject: [docs] [issue22088] base64 module still ignores non-alphabet
 characters
In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>
Message-ID: <20151214051443.26605.61098@psf.io>


Roundup Robot added the comment:

New changeset 937774aa1853 by Martin Panter in branch '2.7':
Issue #22088: Port base64 character ignoring doc and test from 857d9fe60169
https://hg.python.org/cpython/rev/937774aa1853

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

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

From report at bugs.python.org  Mon Dec 14 00:42:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Dec 2015 05:42:10 +0000
Subject: [docs] [issue20782] base64 module docs do not use the terms 'bytes'
 and 'string' consistently.
In-Reply-To: <1393427308.42.0.0461164572304.issue20782@psf.upfronthosting.co.za>
Message-ID: <1450071730.14.0.790797592571.issue20782@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hopefully the patch proposed for Issue 1753718 will address this issue. Many of my comments there would also apply to the patch here.

----------
dependencies: +base64 "legacy" functions violate RFC 3548
nosy: +martin.panter
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Dec 14 00:44:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Dec 2015 05:44:45 +0000
Subject: [docs] [issue22088] base64 module still ignores non-alphabet
 characters
In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>
Message-ID: <1450071884.98.0.899622180719.issue22088@psf.upfronthosting.co.za>


Martin Panter added the comment:

While porting the Python 3 changes over, I noticed some related problems in the Python 2 and 3 documentation:

* Due to the internal alphabet translation, characters that are in the original base-64 alphabet (+ and /) are not discarded, even if an alternative alphabet is specified
* Doc strings of standard_ and urlsafe_b64decode() need fixing as well
* Found some copy-paste errors in the doc strings
* There are only two distinct base-64 alphabets defined by the RFCs, not three. The URL-safe alphabet and the filename-safe alphabet are the same thing.

Here is a patch for review. I will hold off on this until Issue 1753718 has been sorted out to avoid conflicts in the Python 3 docs.

----------
keywords: +patch
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41301/base64-discard.patch

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

From vadmium+py at gmail.com  Sun Dec 13 20:33:05 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 14 Dec 2015 01:33:05 -0000
Subject: [docs] base64 "legacy" functions violate RFC 3548 (issue 1753718)
Message-ID: <20151214013305.3385.69235@psf.upfronthosting.co.za>


http://bugs.python.org/review/1753718/diff/16115/Doc/library/base64.rst
File Doc/library/base64.rst (right):

http://bugs.python.org/review/1753718/diff/16115/Doc/library/base64.rst#newcode34
Doc/library/base64.rst:34: interface does not implement :rfc:`3548`.
In my mind, MIME?s transfer encoding is an application of RFC 3548; it
does implement base 64 under the covers. The real point is it just adds
line breaking on top. What about:

?. . . and adds newlines every 76 characters. The legacy interface
implements MIME?s *base64* transfer encoding, as per :rfc:`2045`.?

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

From vadmium+py at gmail.com  Sun Dec 13 21:39:33 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 14 Dec 2015 02:39:33 -0000
Subject: [docs] base64 "legacy" functions violate RFC 3548 (issue
 1753718)
Message-ID: <20151214023933.18705.56768@psf.upfronthosting.co.za>

Mainly comments about data types accepted. Previous comment was made
before I noticed the new patch.


http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst
File Doc/library/base64.rst (right):

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode30
Doc/library/base64.rst:30: In addition to the above, the legacy
interface also provides for encoding and
This is a bit misleading, e.g. the ?legacy? interface doesn?t accept str
objects.

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode52
Doc/library/base64.rst:52: Optional *altchars* must be a
:term:`bytes-like object` of at least
Safer to say it must be a bytes object. The code does an assert using
len().

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode61
Doc/library/base64.rst:61: Decode the Base64 encoded :term:`bytes-like
object` *s* and return
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode64
Doc/library/base64.rst:64: Optional *altchars* must be a
:term:`bytes-like object` of
The code goes out of its way to also support ASCII character strings

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode85
Doc/library/base64.rst:85: Decode :term:`bytes-like object` *s* using
the standard Base64 alphabet
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode99
Doc/library/base64.rst:99: Decode :term:`bytes-like object` *s* using a
URL-safe alphabet, which
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode112
Doc/library/base64.rst:112: Decode the Base32 encoded :term:`bytes-like
object` *s* and return
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode139
Doc/library/base64.rst:139: Decode the Base16 encoded :term:`bytes-like
object` *s* and return the
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode175
Doc/library/base64.rst:175: Decode the Ascii85 encoded :term:`bytes-like
object` *s* and return
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode185
Doc/library/base64.rst:185: *ignorechars* should be a :term:`bytes-like
object` containing characters to ignore
Safer to just say bytes; the code tests ?x in ignorechars?

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode205
Doc/library/base64.rst:205: Decode the base85-encoded :term:`bytes-like
object` *b* and return
or ASCII str

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode233
Doc/library/base64.rst:233: Decode the :term:`bytes-like object` *s*,
which must contain one or more lines of base64
The object must also be a one-dimensional array of bytes (c, b or B
format)

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode234
Doc/library/base64.rst:234: encoded data, and return the decoded
:class:`bytes`  ``decodestring`` is a deprecated alias.
Dropped a full stop. Which is why I like starting sentences with capital
letters :)

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode252
Doc/library/base64.rst:252: Encode the :term:`bytes-like object` *s*,
which can contain arbitrary binary
Same 1-D byte array restriction applies

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

From vadmium+py at gmail.com  Mon Dec 14 00:37:31 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 14 Dec 2015 05:37:31 -0000
Subject: [docs] base64 "legacy" functions violate RFC 3548 (issue
 1753718)
Message-ID: <20151214053731.3385.8731@psf.upfronthosting.co.za>


https://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst
File Doc/library/base64.rst (right):

https://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode197
Doc/library/base64.rst:197: If *pad* is true, the input is padded with
"\\0" so its length is a
padded with b"\\0"

https://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode198
Doc/library/base64.rst:198: multiple of 4 characters before encoding.
four bytes

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

From report at bugs.python.org  Mon Dec 14 10:57:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2015 15:57:47 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450108667.46.0.256636332685.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

How about we just make the docs more correct and say that input is read until readline() returns an empty bytes object?  That should make it clear that a line-oriented file is expected.

----------

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

From report at bugs.python.org  Mon Dec 14 11:14:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2015 16:14:20 +0000
Subject: [docs] [issue20782] base64 module docs do not use the terms 'bytes'
 and 'string' consistently.
In-Reply-To: <1393427308.42.0.0461164572304.issue20782@psf.upfronthosting.co.za>
Message-ID: <1450109660.48.0.473974621854.issue20782@psf.upfronthosting.co.za>


R. David Murray added the comment:

Darn.  I *thought* I remembered there being an existing patch for this when I was working on that other issue, but I couldn't find it.

----------

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

From report at bugs.python.org  Mon Dec 14 11:41:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2015 16:41:58 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450111318.31.0.132004653886.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file41306/issue-01753718.patch

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

From report at bugs.python.org  Mon Dec 14 12:56:20 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Mon, 14 Dec 2015 17:56:20 +0000
Subject: [docs] [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1450115780.61.0.0550491458876.issue12174@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

This issue raises the fact that the 2.X documentation 
lists two logging levels (SUBDEBUG and SUBWARNING) 
without explaining how these two fit into the logging 
hierarchy of the logging levels provided by the standard library logging module
(ie, is SUBDEBUG between INFO and DEBUG). 

The patch (provided by JJeffries and modified by Petri Lehtinen) 
adds an explanatory note stating the hierarchy as follows


These are  :const:`SUBWARNING`,
+which fits between :const:`INFO` and :const:`WARNING` in the normal logging
+hierarchy, and :const:`SUBDEBUG`, which fits below :const:`DEBUG`


Review (this applies to the 2.X version of the documentation)

1. It would be nice to clarify that SUBDEBUG is between DEBUG and NOTSET
instead of saying that it is 'below' as this maybe misunderstood (at least it's not very clear to me). 

2. Slightly unrelated to the main issue of this patch

2a) "In addition to having these two logging functions, the multiprocessing also"

Should be 

"In addition to having these two logging functions, the multiprocessing module also"


3. The documentation for the multiprocessing module in Python 3.X has removed any mention
of SUBWARNING and SUBDEBUG, so I'm not sure if this patch is even relevant anymore?

4. Also, slightly tangent to this patch, but might be nice to pick up is the fact that
documentation for the 2.X version mentions that the logging level table can be viewed in 
the logging module documentation

"For a full table of logging levels, see the logging module."

which is not the case anymore. As Vinay Sajip mentions, in 2.X the logging level table
has moved to the how-to https://docs.python.org/2/howto/logging.html#logging-levels 
and so this link should be updated as well


TODO:
1. Check if SUBWARNING and SUBDEBUG are still part of the public API in 3.X and then 
suggest alterations to documentation based on that.

----------
nosy: +Winterflower

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

From report at bugs.python.org  Mon Dec 14 13:48:39 2015
From: report at bugs.python.org (Anish Shah)
Date: Mon, 14 Dec 2015 18:48:39 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450118919.07.0.267183925839.issue12484@psf.upfronthosting.co.za>


Anish Shah added the comment:

will try to create a patch for this issue in a day. Thanks!

----------
nosy: +Anish.Shah

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

From report at bugs.python.org  Mon Dec 14 14:27:35 2015
From: report at bugs.python.org (Anish Shah)
Date: Mon, 14 Dec 2015 19:27:35 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450121255.12.0.709665182652.issue12484@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file41310/remove_Py_InitModule_from_docs.patch

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

From report at bugs.python.org  Mon Dec 14 14:41:12 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Dec 2015 19:41:12 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450122072.67.0.711152171875.issue12484@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Dec 14 14:45:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Dec 2015 19:45:01 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450122301.71.0.135999692307.issue12484@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

3.4 is also on security fix only status.

----------
nosy: +terry.reedy
versions:  -Python 3.4

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

From report at bugs.python.org  Mon Dec 14 14:45:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Dec 2015 19:45:29 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450122329.91.0.246054248513.issue12484@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Mon Dec 14 14:47:22 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Dec 2015 19:47:22 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450122442.83.0.292202817636.issue12484@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Sorry, another week for 3.4

----------
versions: +Python 3.4

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

From report at bugs.python.org  Mon Dec 14 14:48:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Dec 2015 19:48:33 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450122513.04.0.458415894311.issue1753718@psf.upfronthosting.co.za>


Martin Panter added the comment:

The change to readline() works well.

Any thoughts regarding my other comments? In particular, altchars and ignorechars cannot be arbitrary bytes-like objects.

----------

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

From report at bugs.python.org  Mon Dec 14 15:56:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Dec 2015 20:56:58 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450126618.39.0.15799067314.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

I missed the other comments somehow.  Will take a look soon.

----------

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

From report at bugs.python.org  Tue Dec 15 02:47:24 2015
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 15 Dec 2015 07:47:24 +0000
Subject: [docs] [issue25865] 7.2 Assignment statements documentation is
 vague and slightly misleading
Message-ID: <1450165644.56.0.226489817502.issue25865@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

>From https://docs.python.org/3/reference/simple_stmts.html#assignment-statements

> If the target list contains one target prefixed with an asterisk, called a ?starred? target: The object must be a sequence with at least as many items as there are targets in the target list, minus one. The first items of the sequence are assigned, from left to right, to the targets before the starred target. The final items of the sequence are assigned to the targets after the starred target. A list of the remaining items in the sequence is then assigned to the starred target (the list can be empty).
> Else: The object must be a sequence with the same number of items as there are targets in the target list, and the items are assigned, from left to right, to the corresponding targets.

The word "sequence" is used here multiple times. But the object being assigned to the target list can be any iterable (including an iterator, a set, some weird custom iterable you invent, ...).

> If the target is a target list enclosed in parentheses or in square brackets: The object must be an iterable with the same number of items as there are targets in the target list, and its items are assigned, from left to right, to the corresponding targets.

This doesn't mention that you can have a starred target inside the parenthesized or bracketed target list. More importantly, it covers the exact same case already covered above. There's semantics for "assignment of an object to a target list, optionally enclosed in parentheses or square brackets", and then semantics for "Assignment of an object to a single target... If the target is a target list enclosed in parentheses or in square brackets".

According to the grammar, a single target (no commas, parens, or brackets) is a target list, but according to the previous paragraphs it seems like it isn't.

Finally, there's nothing that explains what distinguishes between target list assignment and single?target assignment. As far as I can tell, it's treated as a target list iff there's a comma, or there's square brackets around it (similar to the fact that tuples are defined by commas, but lists by square brackets--but without the exception for `()`); that should probably be documented.

There's also some needless repetition there.

I think better wording might be something like this:

> Assignment is recursively defined as follows.

> * If the target list is a comma-separated list of two or more targets, optionally enclosed in parentheses, or a comma-separated list of zero or more targets enclosed in square brackets:

(It might be worth having a note here pointing out that these are almost the same rules for non-comprehension tuple and list displays, except that () is a tuple but not a target list. Or would that just be confusing?)

(It might also be worth mentioning that this is the same feature referred to as "iterable unpacking", "sequence unpacking", and/or "tuple unpacking" in PEP 3132, the official tutorial, and lots of non-official materials?)

> ** If the target list contains one target prefixed with an asterisk, called a ?starred? target: The object must be an iterable with at least as many items as there are targets in the target list, minus one. The first items of the iterable are assigned, from left to right, to the targets before the starred target. The final items of the iterable are assigned to the targets after the starred target. A list of the remaining items in the iterable is then assigned to the starred target (the list can be empty).

> ** Else: The object must be an iterable with the same number of items as there are targets in the target list, and the items are assigned, from left to right, to the corresponding targets.

> * Otherwise, the target list is treated as a single target. 

> ** If the target is an identifier (name): ...

(No section on bracketed target list here; that's already covered above.)

> ** If the target is an attribute reference: ...

> ** ...

----------
assignee: docs at python
components: Documentation
messages: 256443
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: 7.2 Assignment statements documentation is vague and slightly misleading

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

From report at bugs.python.org  Tue Dec 15 02:51:34 2015
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 15 Dec 2015 07:51:34 +0000
Subject: [docs] [issue25865] 7.2 Assignment statements documentation is
 vague and slightly misleading
In-Reply-To: <1450165644.56.0.226489817502.issue25865@psf.upfronthosting.co.za>
Message-ID: <1450165894.08.0.0625011433056.issue25865@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

As a side note, why isn't () allowed as an empty target list, like []? Then the rules for target lists vs. single targets would be exactly parallel to the rules for tuple and list displays. And the error message `can't assign to ()` seems a bit weird--you can't really assign to the tuple `a, b, c` or `(a, b, c)`, but that's not what you're doing; you're just specifying a target list.

----------

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

From report at bugs.python.org  Tue Dec 15 03:12:47 2015
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 15 Dec 2015 08:12:47 +0000
Subject: [docs] [issue25866] Reference 3. Data Model: miscellaneous minor
 cleanups on the word "sequence".
Message-ID: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

None of the below are very serious or likely to mislead anyone using or implementing Python, but...

---

3.3.2. Customizing attribute access

The docs for `__dir__` say:

> A sequence must be returned. dir() converts the returned sequence to a list and sorts it.

At least in CPython and PyPy, this isn't enforced; any iterable can be returned (and it's then converted to a list and sorted). You can even make `__dir__` a generator function. (I've never seen that in the wild--but I have seen code that returns a `map` iterator.)

I think it would be better to say "An iterable must be returned. dir() converts the returned iterable to a list and sorts it."

---

3.3.2.3. __slots__

> This class variable can be assigned a string, iterable, or sequence of strings...

While it's true that you can assign any iterable, it's at best misleading to assign an iterator. For example, if you use `__slots__ = iter('abc')`, you will get a class with descriptors named `a`, `b`, and `c`, but with an empty iterator in `__slots__`. There's probably no reason to actually outlaw that, but it might be worth noting in 3.3.2.3.1 along with the other weird possibilities like assigning a mapping.

---

3.3.6. Emulating container types

The docs still say that the ABCs are in `collections` rather than `collections.abc`.

> ... for mappings, __iter__() should be the same as keys()

No; `__iter__()` should be an iterator over the keys; `keys()` _can_ be an iterator, but generally should be a view instead.

> The membership test operators (in and not in) are normally implemented as an iteration through a sequence. However, container objects can supply the following special method with a more efficient implementation, which also does not require the object be a sequence.

I don't think this should say "through a sequence". They're implemented as iteration through whatever the container is, whether it's a sequence, a set, a linked list, or anything else. The documentation on `__contains__` immediately below clarifies this, but it's probably better to be clear from the start.

----------
assignee: docs at python
components: Documentation
messages: 256445
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: Reference 3. Data Model: miscellaneous minor cleanups on the word "sequence".
type: enhancement

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

From report at bugs.python.org  Tue Dec 15 05:44:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 15 Dec 2015 10:44:55 +0000
Subject: [docs] [issue25865] 7.2 Assignment statements documentation is
 vague and slightly misleading
In-Reply-To: <1450165644.56.0.226489817502.issue25865@psf.upfronthosting.co.za>
Message-ID: <1450176295.68.0.440714340167.issue25865@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding assigning to (), see Issue 23275. Looks like there is a patch to enable it.

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

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

From report at bugs.python.org  Tue Dec 15 14:24:35 2015
From: report at bugs.python.org (Chris Wilcox)
Date: Tue, 15 Dec 2015 19:24:35 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
Message-ID: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>


New submission from Chris Wilcox:

This is a documentation change to make it easier to discover that XP is not a supported OS.  Content was taken from the 'whats new' section and added to the top of the main article.

----------
assignee: docs at python
components: Documentation
files: add-supported-versions-section-windows.diff
keywords: patch
messages: 256473
nosy: crwilcox, docs at python
priority: normal
severity: normal
status: open
title: Add notice that XP is not supported on Python 3.5+
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41319/add-supported-versions-section-windows.diff

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

From report at bugs.python.org  Tue Dec 15 14:30:00 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 15 Dec 2015 19:30:00 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
In-Reply-To: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>
Message-ID: <1450207800.48.0.868076558017.issue25874@psf.upfronthosting.co.za>


SilentGhost added the comment:

This seems fully covered in the What's new for 3.5: https://docs.python.org/3/whatsnew/3.5.html#unsupported-operating-systems

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec 15 18:35:47 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Dec 2015 23:35:47 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
In-Reply-To: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>
Message-ID: <1450222547.73.0.303859945101.issue25874@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Chris' patch, though, fixes a doc that fails to mention our support policy for Windows: https://www.python.org/dev/peps/pep-0011/#microsoft-windows . There should at least be a sentence saying that once Microsoft no longer supports an operating system release then Python also drops support and link to PEP 11 to the full explanation.

----------
nosy: +brett.cannon
resolution: not a bug -> 
status: closed -> open

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

From report at bugs.python.org  Tue Dec 15 18:35:56 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Dec 2015 23:35:56 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
In-Reply-To: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>
Message-ID: <1450222556.0.0.509518283269.issue25874@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Tue Dec 15 18:39:19 2015
From: report at bugs.python.org (Thomas Latimer)
Date: Tue, 15 Dec 2015 23:39:19 +0000
Subject: [docs] [issue25877] python av docs has broken links
Message-ID: <1450222759.52.0.72518805209.issue25877@psf.upfronthosting.co.za>


New submission from Thomas Latimer:

https://www.python.org/doc/av/

I was looking for an audio lecture on python to listen to on my drive. I found this page, which looked promising, except...

both 'python411' and 'a little bit of python' are broken links.

----------
assignee: docs at python
components: Documentation
messages: 256489
nosy: Thomas Latimer, docs at python
priority: normal
severity: normal
status: open
title: python av docs has broken links
type: behavior

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

From report at bugs.python.org  Tue Dec 15 20:37:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Dec 2015 01:37:20 +0000
Subject: [docs] [issue25877] python av docs has broken links
In-Reply-To: <1450222759.52.0.72518805209.issue25877@psf.upfronthosting.co.za>
Message-ID: <1450229840.86.0.0509867310924.issue25877@psf.upfronthosting.co.za>


R. David Murray added the comment:

The place to report web site bugs is https://github.com/python/pythondotorg.  I know that's not obvious, so I don't blame you for reporting it here ;)  (As far as web stuff goes, we only handle docs.python.org bugs here.)

(It's kind of weird closing this as third party, but that's the closest resolution we have.)

----------
nosy: +r.david.murray
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec 15 21:17:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Dec 2015 02:17:44 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450232264.07.0.158033613773.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

Updated patch that addresses most of the comments.

----------
Added file: http://bugs.python.org/file41325/issue-01753718.patch

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

From report at bugs.python.org  Tue Dec 15 21:17:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Dec 2015 02:17:52 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450232272.75.0.4288406635.issue1753718@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 2.7

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

From report at bugs.python.org  Wed Dec 16 03:14:44 2015
From: report at bugs.python.org (SilentGhost)
Date: Wed, 16 Dec 2015 08:14:44 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
In-Reply-To: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>
Message-ID: <1450253684.5.0.189258870036.issue25874@psf.upfronthosting.co.za>


SilentGhost added the comment:

Hm, may be I'm seeing things, but the content of the current what's new section is this:

Windows XP is no longer supported by Microsoft, thus, per :PEP:`11`, CPython     
3.5 is no longer officially supported on this OS.

The proposed patch adds two sentences on top of that:

Vista and Later versions of Windows are supported.
Please install the latest 3.4 version of CPython if you are using Windows XP.

I don't really see how that is a useful addition.

----------

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

From rdmurray at bitdance.com  Tue Dec 15 21:08:46 2015
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Wed, 16 Dec 2015 02:08:46 -0000
Subject: [docs] base64 "legacy" functions violate RFC 3548 (issue
 1753718)
Message-ID: <20151216020846.18705.34861@psf.upfronthosting.co.za>


http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst
File Doc/library/base64.rst (right):

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode30
Doc/library/base64.rst:30: In addition to the above, the legacy
interface also provides for encoding and
On 2015/12/14 03:39:33, vadmium wrote:
> This is a bit misleading, e.g. the ?legacy? interface doesn?t accept
str
> objects.

Ah, good point.  I thought I'd tested that, but obviously I didn't.

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode52
Doc/library/base64.rst:52: Optional *altchars* must be a
:term:`bytes-like object` of at least
On 2015/12/14 03:39:33, vadmium wrote:
> Safer to say it must be a bytes object. The code does an assert using
len().

Why is that an issue?  It accepts bytearray and memoryview, so saying
bytes object would be incorrect.

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode61
Doc/library/base64.rst:61: Decode the Base64 encoded :term:`bytes-like
object` *s* and return
On 2015/12/14 03:39:33, vadmium wrote:
> or ASCII str

Heh, fixed it in the intro and the forgot in the body.

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode64
Doc/library/base64.rst:64: Optional *altchars* must be a
:term:`bytes-like object` of
On 2015/12/14 03:39:33, vadmium wrote:
> The code goes out of its way to also support ASCII character strings

Oh, I tested encode but not decode.

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode185
Doc/library/base64.rst:185: *ignorechars* should be a :term:`bytes-like
object` containing characters to ignore
On 2015/12/14 03:39:33, vadmium wrote:
> Safer to just say bytes; the code tests ?x in ignorechars?

Again, why is this a problem?

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode233
Doc/library/base64.rst:233: Decode the :term:`bytes-like object` *s*,
which must contain one or more lines of base64
On 2015/12/14 03:39:33, vadmium wrote:
> The object must also be a one-dimensional array of bytes (c, b or B
format)

There was a lot of discussion around this when the terms were added to
and then modified in the glossary.  The actual requirement is a C
contiguous buffer (which the glossary defines), and if base64 actually
requires it to be one dimensional then that's a bug, either in the code
or in the glossary.

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

From vadmium+py at gmail.com  Tue Dec 15 23:30:51 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 16 Dec 2015 04:30:51 -0000
Subject: [docs] base64 "legacy" functions violate RFC 3548 (issue
 1753718)
Message-ID: <20151216043051.20191.32375@psf.upfronthosting.co.za>


http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst
File Doc/library/base64.rst (right):

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode52
Doc/library/base64.rst:52: Optional *altchars* must be a
:term:`bytes-like object` of at least
On 2015/12/16 03:08:46, r.david.murray wrote:
> On 2015/12/14 03:39:33, vadmium wrote:
> > Safer to say it must be a bytes object. The code does an assert
using len().
> 
> Why is that an issue?  It accepts bytearray and memoryview, so saying
bytes
> object would be incorrect.

I think it is better to document a subset of what is accepted than a
superset. According the the glossary and the buffer protocol, a
bytes-like object does not have to implement len(). For memoryviews, I
think len() returns the number of array elements, not necessarily equal
to nbytes. I usually use ctypes to test for bytes-like support:

>>> class Alts(ctypes.Structure):
...     _fields_ = (("a", ctypes.c_char), ("b", ctypes.c_char))
... 
>>> byteslike = Alts(*b"{}")
>>> bytes(byteslike)
b'{}'
>>> b64encode(b"\xFF\xFF\xFF", altchars=byteslike)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/base64.py", line 63, in b64encode
    assert len(altchars) == 2, repr(altchars)
TypeError: object of type 'Alts' has no len()

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode53
Doc/library/base64.rst:53: length 2 (additional characters are ignored)
which specifies an alternative
Just noticed it has to be exactly two bytes long; same for b64decode()

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode185
Doc/library/base64.rst:185: *ignorechars* should be a :term:`bytes-like
object` containing characters to ignore
On 2015/12/16 03:08:46, r.david.murray wrote:
> On 2015/12/14 03:39:33, vadmium wrote:
> > Safer to just say bytes; the code tests ?x in ignorechars?
> 
> Again, why is this a problem?

>>> a85decode(" ", ignorechars=ctypes.create_string_buffer(b"
\t\n\r\v"))
/home/proj/python/cpython/Lib/base64.py:412: BytesWarning: Comparison
between bytes and int
  elif x in ignorechars:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/base64.py", line 416, in a85decode
    raise ValueError('Non-Ascii85 digit found: %c' % x)
ValueError: Non-Ascii85 digit found:

http://bugs.python.org/review/1753718/diff/16149/Doc/library/base64.rst#newcode233
Doc/library/base64.rst:233: Decode the :term:`bytes-like object` *s*,
which must contain one or more lines of base64
On 2015/12/16 03:08:46, r.david.murray wrote:
> On 2015/12/14 03:39:33, vadmium wrote:
> > The object must also be a one-dimensional array of bytes (c, b or B
format)
> 
> There was a lot of discussion around this when the terms were added to
and then
> modified in the glossary.  The actual requirement is a C contiguous
buffer
> (which the glossary defines), and if base64 actually requires it to be
one
> dimensional then that's a bug, either in the code or in the glossary.

Yes, I see now that this contradicts the ?versionchanged:: 3.4?
statement at the top.

http://bugs.python.org/review/1753718/diff/16167/Doc/library/base64.rst
File Doc/library/base64.rst (right):

http://bugs.python.org/review/1753718/diff/16167/Doc/library/base64.rst#newcode48
Doc/library/base64.rst:48: .. function:: b64encode(s, aultchars=None)
Stray U got added here

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

From report at bugs.python.org  Wed Dec 16 20:43:19 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 17 Dec 2015 01:43:19 +0000
Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1450316599.01.0.0700634708806.issue5501@psf.upfronthosting.co.za>


Davin Potts added the comment:

Thank you, Winterflower, for the nudge to see this set right.

In truth, invoking multiprocessing.freeze_support() has zero effect on platforms other than Windows.

This should be reflected in the 2.7 docs as well as the 3.x docs that are still actively being updated.

Attached are 2 patches -- they should be cleanly applied to the 2.7, 3.5, and default (3.6) branches.  This change clarifies the last line of existing documentation around freeze_support() as well as clearly states what I mentioned above.

----------
assignee: jnoller -> davin
stage:  -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.2
Added file: http://bugs.python.org/file41330/issue_5501_explicit_freeze_support_nonWin_v27.patch

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

From report at bugs.python.org  Wed Dec 16 20:44:39 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 17 Dec 2015 01:44:39 +0000
Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1450316679.92.0.545075347838.issue5501@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


Added file: http://bugs.python.org/file41331/issue_5501_explicit_freeze_support_nonWin_v3x.patch

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

From report at bugs.python.org  Wed Dec 16 20:45:42 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 17 Dec 2015 01:45:42 +0000
Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1450316742.57.0.382809715089.issue5501@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


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

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

From report at bugs.python.org  Thu Dec 17 18:19:03 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2015 23:19:03 +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: <1450394343.7.0.129850158326.issue25580@psf.upfronthosting.co.za>


Yury Selivanov 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.


Exactly.  And in 3.7 they will be NAME tokens in any context.  That's why I'm reluctant to document them atm.

----------

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

From report at bugs.python.org  Thu Dec 17 18:26:11 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2015 23:26:11 +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: <1450394771.02.0.875549983144.issue25580@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Ah, I see that issue25580_2.diff does exactly what I proposed.  I'm committing it.

----------
keywords: +easy

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

From report at bugs.python.org  Thu Dec 17 18:27:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 17 Dec 2015 23:27: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: <20151217232658.83199.62357@psf.io>


Roundup Robot added the comment:

New changeset aa79b2a5b2e1 by Yury Selivanov in branch '3.5':
docs: Document ASYNC/AWAIT tokens (issue #25580)
https://hg.python.org/cpython/rev/aa79b2a5b2e1

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

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

From report at bugs.python.org  Thu Dec 17 18:27:28 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2015 23:27:28 +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: <1450394848.84.0.458917954448.issue25580@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks for the patch!

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

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

From report at bugs.python.org  Thu Dec 17 18:32:21 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2015 23:32:21 +0000
Subject: [docs] [issue14911] generator.throw() documentation inaccurate
In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>
Message-ID: <1450395141.33.0.874350564657.issue14911@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Martin, could you please rebase your patch on top of recent cpython default branch, so that a 'review' link appears?

----------

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

From report at bugs.python.org  Thu Dec 17 20:42:27 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 18 Dec 2015 01:42:27 +0000
Subject: [docs] [issue25836] Documentation of
 MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG is misleading
In-Reply-To: <1449807235.86.0.17166679506.issue25836@psf.upfronthosting.co.za>
Message-ID: <1450402947.72.0.549978632576.issue25836@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

It turns out I wasn't completely correct. As per my second point, the interpretation of annotations needs be clarified, but my first point about default_args including the annotation count is incorrect. 

My error was made because of the documentation for EXTENDED_ARG. The current text implies that you need to combine the argument value of the EXTENDED_ARG opcode with the argument value for the previous opcode. However if you're using dis.Bytecode() to extract bytecodes, that composition is done for you - you can effectively ignore the EXTENDED_ARG opcode.

----------
title: Documentation of MAKE_FUNCTION is still incorrect -> Documentation of MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG is misleading

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

From report at bugs.python.org  Thu Dec 17 21:51:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Dec 2015 02:51:10 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450407070.41.0.266493460736.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

The intent of the term "bytes-like object" it to make it possible to use it in documentation in the way I have used it here.  That the buffer has a len is clearly discussed in the Buffer Protocol documentation, but of course that's only talking about the C level API.  Perhaps what is needed is an addition to the bytes-like object description that clarifies that a bytes-like object is a Sequence that supports the buffer protocol?  (So: "A Sequence object that supports the Buffer Protocol and...")  Do we also need to clarify that the item size must be one byte?  That would seem to me to be implicit in the name.

I don't know if what ctypes produces is a bytes-like object in this sense, since I don't understand ctypes very well, but it sounds like it isn't.  Trying to wrap it in a memoryview gives an error ('unsupported format <c'), so I suspect it is not.

I'm adding Nick to nosy, since the commit log says he added the bytes-like object support to this module.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Dec 17 22:01:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Dec 2015 03:01:46 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450407706.02.0.792543254433.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

The altchars 2 char limit is an assertion.  That's a bug that should be dealt with separately.  Either it should be turned into an error, or it should be dropped to match the docs.  Probably the latter, since it is documented as OK and it might break code that is currently working in -O mode or on python2.

----------

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

From report at bugs.python.org  Thu Dec 17 22:03:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Dec 2015 03:03:55 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450407834.7.0.00846061670207.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed the spurious 'u'.

----------
Added file: http://bugs.python.org/file41343/issue-01753718.patch

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

From report at bugs.python.org  Thu Dec 17 22:08:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Dec 2015 03:08:09 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450408089.76.0.56313922655.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

"or on python2" should be "or ported from python2".

Also note that Nick's commit message specifically mentions a test for multi-dimensional input, so the module does indeed conform to the current bytes-like object definition in that regard.

----------

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

From report at bugs.python.org  Fri Dec 18 11:30:35 2015
From: report at bugs.python.org (Julien)
Date: Fri, 18 Dec 2015 16:30:35 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
Message-ID: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>


New submission from Julien:

o/

# Context

I'm trying to resuscitate the translation of Python doc in french, [python_doc_fr](https://github.com/AFPy/python_doc_fr).

I finished the translation of `tutorial.po` (that was partially translated by the AFPY team around 2012) and now working on `glossary.po` (~60%). :-)

# Problem

The homepage (`src/Doc/tools/templates/indexcontent.html`) is not translatable as is, as it misses the translation markers.

# Solution

I attached a patch to this issue adding them, it works well so I translated the generated `sphinx.po` and rebuilt the doc you can enjoy the result here:
 
http://www.afpy.org/doc/python/3.4/

----------
assignee: docs at python
components: Documentation
files: i18n.patch
keywords: patch
messages: 256691
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Documentation i18n: Added trans tags in sphinx templates
versions: Python 3.4
Added file: http://bugs.python.org/file41355/i18n.patch

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

From report at bugs.python.org  Fri Dec 18 11:45:14 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 18 Dec 2015 16:45:14 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1450457114.6.0.877509702187.issue25907@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


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

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

From report at bugs.python.org  Fri Dec 18 20:21:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 19 Dec 2015 01:21:05 +0000
Subject: [docs] [issue14911] generator.throw() documentation inaccurate
In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>
Message-ID: <1450488065.22.0.248824758823.issue14911@psf.upfronthosting.co.za>


Martin Panter added the comment:

This one is based on the public 3.5 branch, so should work. I corrected a small typo made in the previous patch.

----------
versions:  -Python 3.4
Added file: http://bugs.python.org/file41360/throw-3x.v3.patch

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

From report at bugs.python.org  Sat Dec 19 03:34:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2015 08:34:37 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1450514077.42.0.877797437741.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Benjamin, is it good to add PendingDeprecationWarning in 2.7?

----------
nosy: +benjamin.peterson
versions:  -Python 3.4

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

From report at bugs.python.org  Sat Dec 19 06:38:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2015 11:38:05 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
Message-ID: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The documentation and comments for PyMapping_Items, PyMapping_Keys and PyMapping_Values are not correct about return type.

The documentation says that return type is a list. For example for PyMapping_Items:

   On success, return a list of the items in object *o*, where each item is a tuple
   containing a key-value pair.  On failure, return *NULL*. This is equivalent to
   the Python expression ``list(o.items())``.

The comment in Include/abstract.h is more correct, it mentions tuple:

     On success, return a list or tuple of the items in object o,
     where each item is a tuple containing a key-value pair.
     On failure, return NULL.

Actually PyMapping_Items in 3.x can return a list, a tuple, or a dict view (for dict).

The same for PyMapping_Keys and PyMapping_Values.

----------
assignee: docs at python
components: Documentation
messages: 256727
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Incorrect documentation for PyMapping_Items and like
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Dec 19 08:09:04 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 19 Dec 2015 13:09:04 +0000
Subject: [docs] [issue25910] Fixing links in documentation
Message-ID: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>


New submission from SilentGhost:

I've run 'make linkcheck' on Doc and it highlighted a number of faulty links in documentation. I've tried fixing some of them and here is the resulting patch. It's a bit too long and touches many files, so to summarise:

* Most changes are http->https redirect (many from wikipedia and microsoft, but some from independent project)
* New domains, sometimes without redirect or any indication of how to find the same information. 
* Completely new locations, only discoverable via search engine.
* Few dead links, that I removed.

I'm going to attach output.txt that is produced after running linkcheck with this patch applied, it is about three time smaller than the original one and has this types of issues:

* Dead links in licenses
* Internal redirects to versioned text
* Many python.org links in whatsnew/ that I don't know what to do about
* Spurious bad links

----------
assignee: docs at python
components: Documentation
files: linkcheck.diff
keywords: needs review, patch
messages: 256728
nosy: SilentGhost, docs at python, r.david.murray, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Fixing links in documentation
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41361/linkcheck.diff

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

From report at bugs.python.org  Sat Dec 19 08:10:03 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 19 Dec 2015 13:10:03 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1450530603.52.0.411636086866.issue25910@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41362/output.txt

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

From report at bugs.python.org  Sat Dec 19 09:06:30 2015
From: report at bugs.python.org (Julien)
Date: Sat, 19 Dec 2015 14:06:30 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1450533989.93.0.242485345436.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

For emacs users, this `query-replace-regex` comes handy to add trans tags around strings, if one want to apply them to another file / version:

>\([^>^J]*[a-zA-z][^>^J]*\)< -> >{% trans %}\1{% endtrans %}

Note that ^J is obtained typing C-q C-j.

----------

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

From report at bugs.python.org  Sat Dec 19 17:35:08 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Sat, 19 Dec 2015 22:35:08 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1450564507.98.0.627399179587.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Ah, I see. The setup/teardown stuff runs for each test.

So this is what I did:
* Added a method to add a "bad" source file to the source directory. It gets cleaned up with the existing teardown method.
* Used test_importlib to temporarily mutate sys.path as you recommended.

I think this is much closer to what we want. Let me know what you think.

By the way, are there any docs on test_importlib? I couldn't find any.

----------
Added file: http://bugs.python.org/file41364/compileall.patch

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

From report at bugs.python.org  Sat Dec 19 17:39:00 2015
From: report at bugs.python.org (Antony Lee)
Date: Sat, 19 Dec 2015 22:39:00 +0000
Subject: [docs] [issue25912] Use __spec__.__name__ instead of __name__ in
 the docs where appropriate
Message-ID: <1450564740.33.0.258115296695.issue25912@psf.upfronthosting.co.za>


New submission from Antony Lee:

There are a couple of places in the docs where it would be appropriate to replace __name__ by __spec__.__name__ in order to support the case where the module is executed as the __main__ module:

- logging.getLogger should certainly use __spec__.__name__ so that the logger hierarchy be respected (otherwise, when running "python -mpkg.subpkg", the logger of pkg.subpkg is named "__main__" and thus not a child of the "pkg" logger).

- examples for argparse.ArgumentParser (e.g. in the docs for venv) should use __spec__.__name__ instead of __name__ for the "prog=" argument.

(not guaranteed to be exhaustive)

----------
assignee: docs at python
components: Documentation
messages: 256743
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Use __spec__.__name__ instead of __name__ in the docs where appropriate
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Dec 20 05:31:11 2015
From: report at bugs.python.org (Iber Parodi Siri)
Date: Sun, 20 Dec 2015 10:31:11 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
Message-ID: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>


New submission from Iber Parodi Siri:

The documentation of readframes (wave module) states that readframes returns a string of bytes, just like python 2.7, but that's not the case

in python 3.4 readframes returns byte type objects

----------
assignee: docs at python
components: Documentation
messages: 256759
nosy: Iber Parodi Siri, docs at python
priority: normal
severity: normal
status: open
title: wave module readframes now returns bytes not str
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec 20 05:43:57 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Dec 2015 10:43:57 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1450608237.09.0.344847433112.issue25916@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch.

----------
keywords: +needs review, patch
nosy: +SilentGhost
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41368/issue25916.diff

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

From report at bugs.python.org  Sun Dec 20 06:17:27 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Dec 2015 11:17:27 +0000
Subject: [docs] [issue25917] Fixing howto links in docs
Message-ID: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za>


New submission from SilentGhost:

This patch changes links from wiki to howto part of docs.

----------
assignee: docs at python
components: Documentation
files: howto.diff
keywords: needs review, patch
messages: 256761
nosy: SilentGhost, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Fixing howto links in docs
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41369/howto.diff

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

From report at bugs.python.org  Sun Dec 20 06:30:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2015 11:30:33 +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: <1450611033.42.0.966190761481.issue25701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In 2.7 all is the same except that there is the sq_ass_slice slot and the PySequence_SetSlice() function.

----------
Added file: http://bugs.python.org/file41370/setattr-2.7.patch

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

From report at bugs.python.org  Sun Dec 20 10:12:56 2015
From: report at bugs.python.org (Sonali Gupta)
Date: Sun, 20 Dec 2015 15:12:56 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1450624376.49.0.30163159425.issue25909@psf.upfronthosting.co.za>


Sonali Gupta added the comment:

The documentation now says that On success, return a list, a tuple or a dictionary view for PyMapping_Items, PyMapping_Values and PyMapping_Keys.

----------
keywords: +patch
nosy: +mine0901
Added file: http://bugs.python.org/file41372/bug.patch

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

From report at bugs.python.org  Sun Dec 20 10:57:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2015 15:57:54 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1450627074.67.0.11339844629.issue25909@psf.upfronthosting.co.za>


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


----------
nosy: +martin.panter, r.david.murray

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

From report at bugs.python.org  Sun Dec 20 11:03:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2015 16:03:26 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1450627406.0.0.603406701976.issue25909@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> This is equivalent to the Python expression ``list(o.keys())``.

This sentence is not correct.

And comments in Include/abstract.h are not absolutely correct too.

----------

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

From report at bugs.python.org  Sun Dec 20 11:33:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2015 16:33:21 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1450629201.08.0.745530193598.issue25916@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

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

From report at bugs.python.org  Sun Dec 20 11:33:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2015 16:33:45 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1450629225.2.0.00943653228053.issue25916@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 20 11:35:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2015 16:35:53 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1450629352.95.0.10046377394.issue25916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not the only place where "string of bytes" or "byte string" is used as a synonym to "bytes object".

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

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

From report at bugs.python.org  Sun Dec 20 11:38:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Dec 2015 16:38:06 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1450629486.8.0.0287356438449.issue25916@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, and I think it would be good to consistently use "bytes object" or similar wording, to avoid confusion.  But not high enough priority to do a hunt-and-fix (unless someone really feels like doing that).  I've got a patch pending for fixing it in the base64 module, as part of making other fixes to that doc, for example.

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

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

From report at bugs.python.org  Sun Dec 20 11:44:42 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Dec 2015 16:44:42 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1450629882.3.0.927753560643.issue25916@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch replacing exact match 'string of bytes' with :class:`bytes` where appropriate. No match was found in base64.

----------
Added file: http://bugs.python.org/file41375/issue25916_2.diff

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

From report at bugs.python.org  Sun Dec 20 12:23:06 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 20 Dec 2015 17:23:06 +0000
Subject: [docs] [issue25912] Use __spec__.__name__ instead of __name__ in
 the docs where appropriate
In-Reply-To: <1450564740.33.0.258115296695.issue25912@psf.upfronthosting.co.za>
Message-ID: <1450632186.14.0.0554648104142.issue25912@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
stage:  -> test needed
type:  -> enhancement
versions:  -Python 3.5

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

From report at bugs.python.org  Sun Dec 20 12:24:31 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 20 Dec 2015 17:24:31 +0000
Subject: [docs] [issue25912] Use __spec__.__name__ instead of __name__ in
 the docs where appropriate
In-Reply-To: <1450564740.33.0.258115296695.issue25912@psf.upfronthosting.co.za>
Message-ID: <1450632271.29.0.729967417823.issue25912@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Trick with all of these suggestions is going to be thinking through compatibility issues from the change (which also means it can only apply to the default branch).

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sun Dec 20 12:33:52 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 20 Dec 2015 17:33:52 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1450632832.73.0.627848824227.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The patch LGTM, Nicholas! I'll commit it when I have a chance.

As for docs on test_importlib, nothing in the tests directory is documented to prevent people from depending on it since all the code in that directory is explicitly meant for testing Python and not general use.

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

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

From report at bugs.python.org  Sun Dec 20 12:56:00 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 20 Dec 2015 17:56:00 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1450634160.06.0.357493103596.issue25768@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

Alright, sounds good to me. Thank you for guiding me through the process!

----------

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

From report at bugs.python.org  Sun Dec 20 13:54:35 2015
From: report at bugs.python.org (Sonali Gupta)
Date: Sun, 20 Dec 2015 18:54:35 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1450637675.83.0.27573071896.issue25909@psf.upfronthosting.co.za>


Sonali Gupta added the comment:

Should the sentence be removed completely?
> This is equivalent to the Python expression ``list(o.keys())``.

comments in Include/abstract.h are not absolutely correct too so should dictionary view be included in the return of PyMapping_Values, PyMapping_Keys and PyMapping_Items ??

----------

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

From report at bugs.python.org  Sun Dec 20 21:56:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 21 Dec 2015 02:56:47 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450666607.08.0.44980352367.issue1753718@psf.upfronthosting.co.za>


Martin Panter added the comment:

I understood ?bytes-like? to mean what is now defined in the glossary: what is accepted by the C-level y* format for the PyArg parsing functions. I tend to agree with <https://bugs.python.org/issue23756#msg248265> that it may not have been the best term to choose when you really mean ?C-contiguous buffer?.

I am understanding that you take ?bytes-like? to be a more specific thing. Perhaps we could instead have two distinct terms, say ?C-contiguous buffer?, which is what FileIO.write() and PyArg supports, and ?byte sequence?, perhaps implementing an API common to bytes() and memoryview(), which is easier to work with using native Python.

In general, I think ctypes and array.array produce my stricter kind of C-contiguous buffers. But since Issue 15944 native Python code can access these buffers by casting to a second memoryview:

>>> c = ctypes.c_char(b"A")
>>> with memoryview(c) as array_view, array_view.cast("B") as byte_view:
...     print(repr(byte_view[0]))
... 
65

Nick?s commit d90f25e1a705 mentions multi-dimensional input for the ?modern? interface. That is not the problem. In <https://bugs.python.org/issue17839#msg198843> he decided to be less permissive for the ?legacy? interface, which seems unnecessary to me.

Anyway, this is all rather off-topic. Apart from the bytes-like errors, the rest of the current patch is good. Even if you committed with those four errors, I can live with that. I think there are similar problems elsewhere in the documentation, HTTPConnection.request() over TLS for instance.

----------

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

From report at bugs.python.org  Mon Dec 21 01:19:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Dec 2015 06:19:48 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450678788.64.0.816104584289.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

The term "bytes-like object" is specifically designed for those situations where python used to say "X does not support the buffer interface" if passed something else.  Which is the case here...now it says "a bytes-like object is required".  I'm not sure if we fixed that everywhere, but I think we did.  It is certainly true in the cases you cite, except that it turns out that ignorechars accepts an ASCII string.

So, if there is any sort of remaining problem, it is a separate issue: my edits match the current error message behavior.  I'll fix ignorechars and commit.

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

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

From gaston.giordana at gmail.com  Sun Dec 20 01:48:43 2015
From: gaston.giordana at gmail.com (Gaston A. Giordana)
Date: Sun, 20 Dec 2015 07:48:43 +0100
Subject: [docs] problem with epub
Message-ID: <064b01d13af2$78173ae0$6845b0a0$@gmail.com>

Dear all,

 

I'm using the Windows version. I encountering problems to import the epub
file into my reader library. In fact, the reader does not recognise the
format. I do not know if the problem comes from the documentation or my
reader that does not support some formats. Which epub reader would you
recommend to use?

 

Thanks in advance.

 

Best regards,

 

Gaston Giordana   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151220/57d49db5/attachment.html>

From jonasthiem at googlemail.com  Sun Dec 20 16:22:40 2015
From: jonasthiem at googlemail.com (Jonas Thiem)
Date: Sun, 20 Dec 2015 22:22:40 +0100
Subject: [docs] http.server.HTTPServer lacks member documentation
Message-ID: <CAD7Z2hp0zN4b3K=awx+Kbzcg2iGr0yCbm+MKeBuvyWCT6vr+aA@mail.gmail.com>

http.server.HTTPServer appears to lack member documentation, most
notably the function "serve_forever" and the proper shutdown functions
to stop serving and close all open sockets (which I recall exist, but
which aren't documented in the class description although they should
be).

URL of the expected place of such documentation:
https://docs.python.org/3/library/http.server.html#http.server.HTTPServer

As you can see, the class HTTPServer is there but the members are
strangely left out - I suggest this should be fixed

From jamshed.vesuna at gmail.com  Mon Dec 21 18:16:51 2015
From: jamshed.vesuna at gmail.com (Jamshed Vesuna)
Date: Mon, 21 Dec 2015 15:16:51 -0800
Subject: [docs] bdb.set_trace() context size
Message-ID: <CAHdYTv+DN5BRc8dxRcbJTP4npiRNjow1PhpvFAwPE49Ty5P-yw@mail.gmail.com>

Hi,

Not quite sure where to submit this: I have a feature request for
bdb.set_trace() to have the option of setting the context value (default is
3 lines), such that a user can call bdb.set_trace(context=10) to display 10
lines of context instead of constantly typing "l" or "list" for more
context. Currently working on this with ipython:
https://github.com/ipython/ipython/issues/9087#issuecomment-166428841

Thank you,
Jamshed Vesuna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151221/dd080d8b/attachment.html>

From report at bugs.python.org  Tue Dec 22 20:05:07 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 23 Dec 2015 01:05:07 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <1450832707.08.0.883107575477.issue25930@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think it's reasonable to say the documentation could be misconstrued -- as Anthony has shown -- and so a patch changing the os.remove docs to say "This function is semantically identical to os.unlink()" would be acceptable.

----------
assignee:  -> docs at python
components: +Documentation -Argument Clinic, Library (Lib)
nosy: +brett.cannon, docs at python
resolution: not a bug -> 
status: closed -> open
title: os.unlink != os.remove in python3.5 -> Document that os.remove is semantically identical to os.unlink

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

From report at bugs.python.org  Tue Dec 22 20:12:18 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Dec 2015 01:12:18 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1450514077.42.0.877797437741.issue15068@psf.upfronthosting.co.za>
Message-ID: <1450833134.2893250.474527233.32FFBF84@webmail.messagingengine.com>


Benjamin Peterson added the comment:

That individually is probably okay. It's more a question of whether the
entire change is appropriate for 2.7.

Note PendingDeprecationWarning is fairly useless, since it's rarely
enabled.

On Sat, Dec 19, 2015, at 00:34, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Benjamin, is it good to add PendingDeprecationWarning in 2.7?
> 
> ----------
> nosy: +benjamin.peterson
> versions:  -Python 3.4
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15068>
> _______________________________________

----------

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

From report at bugs.python.org  Wed Dec 23 05:32:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Dec 2015 10:32:38 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1450866758.5.0.174933312202.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> It's more a question of whether the entire change is appropriate for 2.7.

What is your answer? To me there is a bug and we can fix it.

----------

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

From report at bugs.python.org  Wed Dec 23 06:23:08 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Wed, 23 Dec 2015 11:23:08 +0000
Subject: [docs] [issue23556] Scope for raise without argument is different
 in Python 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1450869788.32.0.511613989396.issue23556@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

In pyflakes we've looked at some of the strange scenarios where a raise without argument is 'legal'.  A patch to report errors for some of these was rejected because they are legal. See https://github.com/pyflakes/pyflakes/pull/57  The worst example of 'legal' is an exception in one module can be re-raised by another module.

----------
nosy: +jayvdb

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

From report at bugs.python.org  Wed Dec 23 06:38:58 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Wed, 23 Dec 2015 11:38:58 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1450870738.79.0.481645332213.issue25381@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +jayvdb

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

From machinewu at 163.com  Wed Dec 23 02:58:28 2015
From: machinewu at 163.com (machinewu)
Date: Wed, 23 Dec 2015 15:58:28 +0800 (CST)
Subject: [docs] There is a little UI bug need to fix in docs.python.org
Message-ID: <5034231c.11f3.151cdd8af7a.Coremail.machinewu@163.com>

 Quick Search input box is too longcauseblocking thecontent of the article. It occurred at firefox v40.0, but chrome is work well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151223/894e24f0/attachment-0001.html>

From report at bugs.python.org  Wed Dec 23 10:07:52 2015
From: report at bugs.python.org (Anish Shah)
Date: Wed, 23 Dec 2015 15:07:52 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450883272.51.0.292189734487.issue12484@psf.upfronthosting.co.za>


Anish Shah added the comment:

Can anyone review the patch?

----------

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

From report at bugs.python.org  Wed Dec 23 17:23:44 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 23 Dec 2015 22:23:44 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450909424.06.0.987780315618.issue12484@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The patch looks good to me.

_PyImport_FixupExtension does not exist in Python 3, but it's still documented in Doc/c-api/import.rst. We need to remove it, too.

(Or we could document _PyImport_FixupExtensionObject since there are already documented internal functions in that file.)

----------
nosy: +berker.peksag, brett.cannon
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Dec 23 21:20:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Dec 2015 02:20:23 +0000
Subject: [docs] [issue20782] base64 module docs do not use the terms 'bytes'
 and 'string' consistently.
In-Reply-To: <1393427308.42.0.0461164572304.issue20782@psf.upfronthosting.co.za>
Message-ID: <20151224022020.9638.45778@psf.io>


Roundup Robot added the comment:

New changeset 105bf5dd93b8 by R David Murray in branch '3.5':
#1753718: clarify RFC compliance and bytes/string argument types.
https://hg.python.org/cpython/rev/105bf5dd93b8

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

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

From report at bugs.python.org  Wed Dec 23 21:20:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Dec 2015 02:20:24 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <20151224022020.9638.77442@psf.io>


Roundup Robot added the comment:

New changeset 105bf5dd93b8 by R David Murray in branch '3.5':
#1753718: clarify RFC compliance and bytes/string argument types.
https://hg.python.org/cpython/rev/105bf5dd93b8

New changeset 92760d2edc9e by R David Murray in branch 'default':
Merge: #1753718: clarify RFC compliance and bytes/string argument types.
https://hg.python.org/cpython/rev/92760d2edc9e

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

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

From report at bugs.python.org  Wed Dec 23 21:21:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Dec 2015 02:21:54 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450923714.59.0.806419161589.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks everyone.

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

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

From report at bugs.python.org  Wed Dec 23 21:23:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Dec 2015 02:23:01 +0000
Subject: [docs] [issue20782] base64 module docs do not use the terms 'bytes'
 and 'string' consistently.
In-Reply-To: <1393427308.42.0.0461164572304.issue20782@psf.upfronthosting.co.za>
Message-ID: <1450923781.9.0.530020732951.issue20782@psf.upfronthosting.co.za>


R. David Murray added the comment:

Everything here should be covered by the fix committed for #1753718.  If I missed anything let me know :)

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

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

From report at bugs.python.org  Thu Dec 24 01:25:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Dec 2015 06:25:26 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450938326.06.0.211116575112.issue1753718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

While we are here, may be update docstrings too?

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

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

From wjong at alten.nl  Thu Dec 24 06:10:01 2015
From: wjong at alten.nl (Willem de Jong)
Date: Thu, 24 Dec 2015 12:10:01 +0100
Subject: [docs] bug in documentation:
 https://docs.python.org/3.5/extending/newtypes.html
Message-ID: <3682185074-8816@mail.alten.nl>


 Hi,

I found a bug in the documentation of python 3.5.
https://docs.python.org/3.5/extending/newtypes.html
In the example in paragraph 
2.1.2. Providing finer control over data attributes
function: Noddy_init(Noddy *self, PyObject *args, PyObject *kwds) 

contains two issues:


1) The PyArg_ParseTupleAndKeywords containst a wrong format specifier : "|SSi" should be? "|ssi"
the captial S would expect an byte, while lowercase 's' represents a string.

2)
When calling the Name function, it will crash, because I think the ParseTupleAndKeywords function in the init will store a string in first.

Best regards,

Willem de Jong.
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151224/94dd62a7/attachment-0001.html>

From report at bugs.python.org  Thu Dec 24 08:15:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Dec 2015 13:15:59 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1450962959.84.0.563360907397.issue25909@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, the documentation and comments (and all other mentions if exist) should be corrected.

We can also consider the option to change current behavior, since it is already differ from 2.x, but this is other issue.

----------

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

From report at bugs.python.org  Thu Dec 24 10:10:35 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Dec 2015 15:10:35 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1450969835.72.0.360424012068.issue1753718@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would be a good idea, yes.  I thought Martin was doing that as part of issue 22088, but now that I look at the patch I see he didn't.  Martin, do you want to add it to that patch, or should I reopen this?

----------

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

From report at bugs.python.org  Thu Dec 24 11:05:27 2015
From: report at bugs.python.org (Anish Shah)
Date: Thu, 24 Dec 2015 16:05:27 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450973127.38.0.897098705441.issue12484@psf.upfronthosting.co.za>


Anish Shah added the comment:

It should be done in a separate issue, right?
Or should I include it in this patch?

----------

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

From report at bugs.python.org  Thu Dec 24 12:33:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 24 Dec 2015 17:33:35 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450978415.25.0.790697439582.issue12484@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Please do not document _PyImport_FixupExtensionObject(); documenting the internal functions was a mistake.

As for whether _PyImport_FixupExtension() should be in this issue or another one, it doesn't matter, Anish; basically whatever is easiest for you if you want to do the work.

----------

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

From report at bugs.python.org  Thu Dec 24 13:29:02 2015
From: report at bugs.python.org (Anish Shah)
Date: Thu, 24 Dec 2015 18:29:02 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450981742.12.0.412622811315.issue12484@psf.upfronthosting.co.za>


Anish Shah added the comment:

@brett.cannon Thanks! I have updated the patch. I removed "_PyImport_FixupExtension" from docs.

----------
Added file: http://bugs.python.org/file41404/issue12484.patch

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

From report at bugs.python.org  Thu Dec 24 13:33:01 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 24 Dec 2015 18:33:01 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1450981981.01.0.994780488501.issue12484@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

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

From hokaidons at gmail.com  Fri Dec 25 02:55:41 2015
From: hokaidons at gmail.com (Adnan Hodzic)
Date: Fri, 25 Dec 2015 08:55:41 +0100
Subject: [docs] os module docs ambiguity
Message-ID: <CABKD-rJZjBWnm4-A8dj5d3Rjutu10NbMZzjzNnHosZiGjx4u9A@mail.gmail.com>

Hi,
Just wanted to pinpoint ambiguity I've noticed in *os* module documentation:
os.rename(*src*, *dst*)

Rename the file or directory *src* to *dst*. If *dst* is a directory,
OSError
<https://docs.python.org/2.6/library/exceptions.html#exceptions.OSError>
will be raised.
I believe that OSError is being raised in case of existing destination
directory, so I presume the correct second sentence would be:
os.rename(*src*, *dst*)

Rename the file or directory *src* to *dst*. If *dst* is *existing*
directory, OSError
<https://docs.python.org/2.6/library/exceptions.html#exceptions.OSError>
will be raised.
Sorry if I misunderstud something, since English is not my native tongue,
although I'm getting along :)
Best regards,
Adnan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151225/f20f40b8/attachment.html>

From report at bugs.python.org  Fri Dec 25 10:50:42 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Dec 2015 15:50:42 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <1451058642.33.0.826191997949.issue25930@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Sat Dec 26 23:40:49 2015
From: report at bugs.python.org (Swati Jaiswal)
Date: Sun, 27 Dec 2015 04:40:49 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <1451191249.13.0.508491885967.issue25930@psf.upfronthosting.co.za>


Swati Jaiswal added the comment:

Please check this. Fixed according to previous comment.

----------
keywords: +patch
nosy: +curioswati
Added file: http://bugs.python.org/file41428/iss_25930.patch

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

From techtonik at gmail.com  Sun Dec 27 06:14:55 2015
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 27 Dec 2015 14:14:55 +0300
Subject: [docs] optparse 'help' action is not documented
Message-ID: <CAPkN8xL866WqBtFce+T8YzUo-ro1=jS5p01LDdKr4yM=2S4UrQ@mail.gmail.com>

Hi,

Documentation misses 'help' action for optparse, which is used
in `pip` and I suppose in other projects:
https://github.com/pypa/pip/blob/develop/pip/cmdoptions.py#L65

It will be more convenient for reference if instead of textual
description, the docs contained this table:

https://hg.python.org/cpython/file/2.7/Lib/optparse.py#l481

    # The set of actions allowed by option parsers.  Explicitly listed
    # here so the constructor can validate its arguments.
    ACTIONS = ("store",
               "store_const",
               "store_true",
               "store_false",
               "append",
               "append_const",
               "count",
               "callback",
               "help",
               "version")

-- 
anatoly t.

From report at bugs.python.org  Sun Dec 27 11:09:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2015 16:09:59 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <1451232599.43.0.772011663306.issue25959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Arguments for PhotoImage.zoom() are zoom factors, not the dimension of the result. In you case you are trying to create an image with size 54000x29964 pixels. This is over 1.6 gigapixels.

Here is pure Tcl equivalent of Python example. It should reproduce the crash.

There is a documentation bug in Tkinter. PhotoImage.zoom() docstring is not clear. This can and should be fixed.

There is a bug in Tk. It shouldn't crash processing image even if the result has incredible size. But we can't do anything with this bug besides reporting to mainstream.

Requalified this issue as easy documentation issue.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
stage:  -> needs patch
type: crash -> enhancement
versions: +Python 3.5, Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file41433/test_issue25959.tcl

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

From report at bugs.python.org  Sun Dec 27 11:35:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2015 16:35:19 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <1451234119.43.0.436929687011.issue25959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opened Tk ticket: http://core.tcl.tk/tk/info/607ffb053c783490 .

----------

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

From report at bugs.python.org  Sun Dec 27 11:49:34 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 27 Dec 2015 16:49:34 +0000
Subject: [docs] [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1451234974.51.0.326384868392.issue12174@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

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

From report at bugs.python.org  Sun Dec 27 13:59:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Dec 2015 18:59:34 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <1451242774.74.0.218404156296.issue25930@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Sun Dec 27 15:09:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Dec 2015 20:09:19 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
In-Reply-To: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>
Message-ID: <20151227200916.21378.98646@psf.io>


Roundup Robot added the comment:

New changeset 5114871a3ac6 by Brett Cannon in branch '3.5':
Issue #25874: Clarify platform support in the "Using Python on Windows" doc.
https://hg.python.org/cpython/rev/5114871a3ac6

New changeset c6bd004671a7 by Brett Cannon in branch 'default':
Merge for issue #25874
https://hg.python.org/cpython/rev/c6bd004671a7

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

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

From report at bugs.python.org  Sun Dec 27 15:09:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Dec 2015 20:09:55 +0000
Subject: [docs] [issue25874] Add notice that XP is not supported on Python
 3.5+
In-Reply-To: <1450207475.07.0.153862605779.issue25874@psf.upfronthosting.co.za>
Message-ID: <1451246995.29.0.601759102047.issue25874@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The "Using Python on Windows" doc has been updated. Thanks, Chris (who got added to ACKS)!

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

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

From report at bugs.python.org  Sun Dec 27 15:24:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Dec 2015 20:24:45 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <20151227202441.70423.65216@psf.io>


Roundup Robot added the comment:

New changeset 003f1f60a09c by Brett Cannon in branch '3.5':
Issue #12484: Remove a mention of Py_InitModule() and _PyImport_FixupExtension().
https://hg.python.org/cpython/rev/003f1f60a09c

New changeset f4aee46c79ca by Brett Cannon in branch 'default':
Merge for issue #12484
https://hg.python.org/cpython/rev/f4aee46c79ca

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

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

From report at bugs.python.org  Sun Dec 27 15:25:46 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Dec 2015 20:25:46 +0000
Subject: [docs] [issue12484] The Py_InitModule functions no longer exist,
 but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1451247946.18.0.170607023504.issue12484@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks, Alejandro, for the report and Anish for the patch (who I added to Misc/ACKS)!

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

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

From report at bugs.python.org  Sun Dec 27 15:56:48 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Sun, 27 Dec 2015 20:56:48 +0000
Subject: [docs] [issue25917] Fixing howto links in docs
In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za>
Message-ID: <1451249808.51.0.226268910941.issue25917@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Applied the patch to default branch and built the docs. 
The updated links work and I can't see any major problems in the immediate vicinity of the changes. 

This is a bit offtopic and unrelated to SilentGhost's change, but I noticed that some of the docpages fixed in this patch use both 'builtin' and 'built-in' and we should probably pick one and stick to it.

----------
nosy: +Winterflower

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

From report at bugs.python.org  Sun Dec 27 16:17:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Dec 2015 21:17:12 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <20151227211709.8265.91275@psf.io>


Roundup Robot added the comment:

New changeset 71f071f2e074 by Brett Cannon in branch 'default':
Issue #25768: Make compileall functions return booleans and document
https://hg.python.org/cpython/rev/71f071f2e074

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

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

From report at bugs.python.org  Sun Dec 27 16:18:49 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Dec 2015 21:18:49 +0000
Subject: [docs] [issue25768] compileall functions do not document or test
 return values
In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za>
Message-ID: <1451251129.67.0.829436440042.issue25768@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Nicholas! I have added you to Misc/ACKS.

I did tweak the patch, though, to have the functions return booleans instead of 1 or 0 and thus tweaked the docs to be less specific about the return type as well as the tests only doing assertTrue and assertFalse instead of directly comparing against 1 or 0 (which would have still worked, but I prefer the weaker definition in case the return value changes in the future).

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

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

From report at bugs.python.org  Mon Dec 28 13:40:32 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Mon, 28 Dec 2015 18:40:32 +0000
Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1451328031.86.0.722774636714.issue5501@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Patch review:

3.X patch:
Applied to docs locally in the default branch(3.6). Docs build passes, doc layout has not been broken. 

Applied to branch 3.5. Docs build passes, doc layout has not been broken.

2.X patch:
Applied to docs locally in the 2.7 branch. Docs build passes, doc layout has not been broken. 


Comments on the contents of the patch:

if the module is being run normally by the Python interpreter on Windows (the program has not been frozen)

For a newbie Python user it might not be entirely clear what 'run normally by the Python interpreter' means. Perhaps it would be nice to add a clarifying clause 

if the module is being run normally by the Python interpreter ( for example, by running python <filename.py> from the command prompt) on Windows (the program has not been frozen)

or something similar.

----------

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

From report at bugs.python.org  Mon Dec 28 14:52:09 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Mon, 28 Dec 2015 19:52:09 +0000
Subject: [docs] [issue16731] xxlimited/xxmodule docstrings ambiguous
In-Reply-To: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za>
Message-ID: <1451332329.42.0.347287723961.issue16731@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Hi Daniel, 
just about to review this patch and noticed that the typo in xxlimited.c docstring is still there. Do you mind if I tweak your patch to fix this?

----------
nosy: +Winterflower

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

From report at bugs.python.org  Mon Dec 28 20:28:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Dec 2015 01:28:27 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <20151229012823.126299.3856@psf.io>


Roundup Robot added the comment:

New changeset 81c7b26f5b4e by Brett Cannon in branch 'default':
Issue #25930: Document that os.unlink and os.remove are *semantically* identical.
https://hg.python.org/cpython/rev/81c7b26f5b4e

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

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

From report at bugs.python.org  Mon Dec 28 20:31:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Dec 2015 01:31:04 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <20151229013101.21223.87068@psf.io>


Roundup Robot added the comment:

New changeset 9f13322eba8e by Brett Cannon in branch '3.5':
Backport of fix for issue #25930
https://hg.python.org/cpython/rev/9f13322eba8e

New changeset e082519bc2c8 by Brett Cannon in branch 'default':
Merge for backport  of fix for issue #25930
https://hg.python.org/cpython/rev/e082519bc2c8

----------

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

From report at bugs.python.org  Mon Dec 28 20:31:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Dec 2015 01:31:55 +0000
Subject: [docs] [issue25930] Document that os.remove is semantically
 identical to os.unlink
In-Reply-To: <1450825845.31.0.1486283683.issue25930@psf.upfronthosting.co.za>
Message-ID: <1451352715.75.0.0801592958104.issue25930@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I tweaked Swati's patch as there was another spot where the "identical" line was used. Thanks to everyone who helped out with this!

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

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

From r.hoeben at antoniusziekenhuis.nl  Tue Dec 29 06:22:56 2015
From: r.hoeben at antoniusziekenhuis.nl (Hoeben, R. (KFI))
Date: Tue, 29 Dec 2015 11:22:56 +0000
Subject: [docs] bug in built-in sum function
Message-ID: <24EB136E3604804C940EAECDBDE149296CFA309E@sv0008.amg.local>

Hi!

Sorry, a bit short on time so I decided to e-mail you the bug I came across.

The built-in sum function is not correctly summing all columns in my array. I noticed by coincidence and verified this in excel.
My matrix is 64x64.
(I am using spyder 2.3.0, and python 2.7.6 32bits on Windows)

sum(summedim)
Out[37]:
array([  148,   123,   130,   207,   293,   290,   401,   638,   928,
        1221,  1597,  2162,  3030,  4331,  6271,  8892, 11805, 14248,
       15602, 16510, 18550, 22730, 27386, 29778, 29970, 32941, 43589,
       59399,  6365,  9188,  5404,  1503,   785,  3809,  6611,  5109,
       62835, 50904, 39940, 33964, 32919, 34305, 35697, 35820, 32936,
       26407, 17595,  9770,  5008,  2895,  1872,  1142,   628,   476,
         541,   627,   763,   908,   862,   518,   150,     6,     0,     0], dtype=uint16)

sum(sum(summedim))
Out[38]: 821432

np.sum(summedim)
Out[39]: 1345720

The last output is correct, the marked outputs are incorrect. I don't know why the function does not work properly for just a few columns.
Though this is consistently the case in all 64x64 array's I was analysing

I am glad I noticed and now started using the np.sum function, but it might aid other users if this bug is fixed.

Happy holidays!
Kind regards,
Renske





[cid:image002.jpg at 01D14233.A5913FA0]

ir. Renske Hoeben

Klinisch Fysicus in opleiding

Afd. Klinische Fysica en Instrumentatie
Postbus 2500
3430 EM Nieuwegein
M   06  5274 1217
T    030  609 3070 (secretariaat)
E    r.hoeben at antoniusziekenhuis.nl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151229/3a62abc4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3044 bytes
Desc: image002.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20151229/3a62abc4/attachment-0001.jpg>

From report at bugs.python.org  Tue Dec 29 18:10:40 2015
From: report at bugs.python.org (John Walker)
Date: Tue, 29 Dec 2015 23:10:40 +0000
Subject: [docs] [issue25977] Typo fixes in Lib/tokenize.py
Message-ID: <1451430640.35.0.717826644288.issue25977@psf.upfronthosting.co.za>


New submission from John Walker:

Minor fixes to comments and a docstring in Lib/tokenize.py I found while looking for more important bugs.

afer -> after
alternately -> alternatively
intput -> input
argment -> argument

----------
assignee: docs at python
components: Documentation
files: tokenize-fixes.patch
keywords: patch
messages: 257217
nosy: docs at python, johnwalker
priority: normal
severity: normal
status: open
title: Typo fixes in Lib/tokenize.py
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41449/tokenize-fixes.patch

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

From report at bugs.python.org  Tue Dec 29 18:31:24 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 29 Dec 2015 23:31:24 +0000
Subject: [docs] [issue25977] Typo fixes in Lib/tokenize.py
In-Reply-To: <1451430640.35.0.717826644288.issue25977@psf.upfronthosting.co.za>
Message-ID: <1451431884.28.0.336026962764.issue25977@psf.upfronthosting.co.za>


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


----------
nosy: +meador.inge

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

From report at bugs.python.org  Tue Dec 29 18:42:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Dec 2015 23:42:50 +0000
Subject: [docs] [issue25977] Typo fixes in Lib/tokenize.py
In-Reply-To: <1451430640.35.0.717826644288.issue25977@psf.upfronthosting.co.za>
Message-ID: <20151229234246.105572.36111@psf.io>


Roundup Robot added the comment:

New changeset 9057e3857119 by Berker Peksag in branch '3.5':
Issue #25977: Fix typos in Lib/tokenize.py
https://hg.python.org/cpython/rev/9057e3857119

New changeset 5b43d7984a63 by Berker Peksag in branch 'default':
Issue #25977: Fix typos in Lib/tokenize.py
https://hg.python.org/cpython/rev/5b43d7984a63

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

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

From report at bugs.python.org  Tue Dec 29 18:44:11 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 29 Dec 2015 23:44:11 +0000
Subject: [docs] [issue25977] Typo fixes in Lib/tokenize.py
In-Reply-To: <1451430640.35.0.717826644288.issue25977@psf.upfronthosting.co.za>
Message-ID: <1451432651.65.0.158071991509.issue25977@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, John.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec 29 19:16:15 2015
From: report at bugs.python.org (John Walker)
Date: Wed, 30 Dec 2015 00:16:15 +0000
Subject: [docs] [issue25977] Typo fixes in Lib/tokenize.py
In-Reply-To: <1451430640.35.0.717826644288.issue25977@psf.upfronthosting.co.za>
Message-ID: <1451434575.08.0.334891231253.issue25977@psf.upfronthosting.co.za>


John Walker added the comment:

You're welcome, have a happy new year. :)

----------

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

From report at bugs.python.org  Wed Dec 30 00:55:41 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Dec 2015 05:55:41 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
 default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1451454941.55.0.559329921481.issue23738@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

One thought that occurred to me is that we could make the * and / in the signature links that point to a relevant section of the documentation.
I believe this is doable with Sphinx, even though I'm not sure how complex it is and if it's worth it.  If we do this, people will be able to find out easily what they mean (especially considering that it's hard to search for them).

----------

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

From techtonik at gmail.com  Wed Dec 30 01:59:57 2015
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 30 Dec 2015 09:59:57 +0300
Subject: [docs] typo
Message-ID: <CAPkN8x+r72iOz-WB_ooJcY=opv+AS2e6yGeCGJwezCRfSpGEag@mail.gmail.com>

https://docs.python.org/2/library/ctypes.html#loading-shared-libraries

- There are several ways to loaded shared libraries into the Python process.
+ There are several ways to load shared libraries into the Python process.

-- 
anatoly t.

From report at bugs.python.org  Wed Dec 30 05:26:07 2015
From: report at bugs.python.org (Daniel Shahaf)
Date: Wed, 30 Dec 2015 10:26:07 +0000
Subject: [docs] [issue16731] xxlimited/xxmodule docstrings ambiguous
In-Reply-To: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za>
Message-ID: <1451471167.38.0.732310973941.issue16731@psf.upfronthosting.co.za>


Daniel Shahaf added the comment:

I don't mind at all.  Go ahead :)

----------

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

From report at bugs.python.org  Wed Dec 30 15:52:18 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 30 Dec 2015 20:52:18 +0000
Subject: [docs] [issue25813] co_flags section of inspect module docs out of
 date
In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za>
Message-ID: <1451508738.19.0.103973943244.issue25813@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Anybody?

----------

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

From report at bugs.python.org  Thu Dec 31 05:29:19 2015
From: report at bugs.python.org (Upendra Kumar)
Date: Thu, 31 Dec 2015 10:29:19 +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: <1451557759.61.0.987049378984.issue18911@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

I am trying to resolve a issue for the first time. Can anybody please tell me or elaborate what is "module level function" specifically in this context.

----------
nosy: +upendra-k14

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

From report at bugs.python.org  Thu Dec 31 09:58:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 31 Dec 2015 14:58:02 +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: <1451573882.73.0.231600368989.issue18911@psf.upfronthosting.co.za>


R. David Murray added the comment:

It means a function defined in the module namespace, as opposed to as a method on a class, so that 'from xml.dom.minidom import <somefunction>' will get you that function.

This issue should be for documentation of the problem, since we won't add the function to 2.7.  A new issue should be opened for the enhancement request of adding a module level convenience function for writing a dom out to a binary file.

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

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

From report at bugs.python.org  Thu Dec 31 21:00:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Jan 2016 02:00:47 +0000
Subject: [docs] [issue25916] wave module readframes now returns bytes not str
In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za>
Message-ID: <1451613647.87.0.508229989138.issue25916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Two of the changes don?t seem right to me; see the review. In the other two cases, IMO ?string of bytes? is a reasonable description of :class:`bytes`, but being explicit is better.

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

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

From report at bugs.python.org  Thu Dec 31 22:24:18 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Jan 2016 03:24:18 +0000
Subject: [docs] [issue17006] Add advice on best practices for hashing secrets
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1451618657.96.0.304750754668.issue17006@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> People are going to skip warning boxes if they occur too often.

I'm not sure I agree.  This would be true if they were abused for trivial things ("Warnings: using .pop() on a empty list will return an IndexError!"), but I don't think they are.

I think warnings are ignored only by people that are already familiar with the module and its limitation/issues, and that know what they are doing.  If the warning is not evident, people are going to miss it [0].

If warnings are used correctly, people will spot them easily and read them (or ignore them if they already know what they are warning against).

[0]: I know I missed it in e.g. https://api.jquery.com/die/ -- the function is deprecated, but (currently) this is only written in the top right corner and in small in the category at the top -- two places that are easily overlooked.  https://api.jquery.com/toggle-event/ on the other hand has a clearly visible yellow box at the top that immediately says that the method is deprecated.

----------

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

From report at bugs.python.org  Thu Dec 31 22:54:43 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Jan 2016 03:54:43 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1451620483.22.0.779561494508.issue25461@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec 31 23:12:53 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Jan 2016 04:12:53 +0000
Subject: [docs] [issue25409] fnmatch.fnmatch normalizes slashes/backslashes
 on Windows
In-Reply-To: <1444889091.12.0.272630391848.issue25409@psf.upfronthosting.co.za>
Message-ID: <1451621573.72.0.638533041148.issue25409@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, Windows
keywords: +easy
nosy: +docs at python

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

From report at bugs.python.org  Thu Dec 31 23:47:09 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Jan 2016 04:47:09 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1451623629.65.0.112593258431.issue13305@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See msg146972 -- AFAIU the padding of %Y is inconsistent for years <1000 (e.g. 0042 vs 42), and this is not documented in the note (2) of https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior
Also, using %4Y seems to consistently produce zero-padded values across different platforms.

----------
keywords: +easy

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

From vadmium+py at gmail.com  Thu Dec 31 20:51:25 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Fri, 01 Jan 2016 01:51:25 -0000
Subject: [docs] wave module readframes now returns bytes not str (issue
 25916)
Message-ID: <20160101015125.1398.25674@psf.upfronthosting.co.za>


https://bugs.python.org/review/25916/diff/16210/Doc/howto/unicode.rst
File Doc/howto/unicode.rst (right):

https://bugs.python.org/review/25916/diff/16210/Doc/howto/unicode.rst#newcode195
Doc/howto/unicode.rst:195: 2. A Unicode string is turned into a
:class:`bytes` object containing no embedded zero
I think this is talking about the UTF-8 encoding in general; linking to
the Python bytes() object is probably not right. IMO ?string of bytes?
was a reasonable description, e.g. U+00A9 is encoded as a string of two
bytes 0xC2 0xA9.

https://bugs.python.org/review/25916/diff/16210/Doc/library/logging.config.rst
File Doc/library/logging.config.rst (right):

https://bugs.python.org/review/25916/diff/16210/Doc/library/logging.config.rst#newcode148
Doc/library/logging.config.rst:148: send it to the socket as a
:class:`bytes` object preceded by a four-byte length
Again, I am not familiar with the API, but I think this is talking about
a socket-level protocol, and linking the bytes() class seems out of
place. I thought ?string of bytes? was fine.

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

From zhuquanming at me.com  Wed Dec 30 23:46:58 2015
From: zhuquanming at me.com (Quanming ZHU)
Date: Thu, 31 Dec 2015 12:46:58 +0800
Subject: [docs] Python-3.5.1-docs epub Cann't open in iBooks
Message-ID: <3199389C-48BB-46F9-92CD-EAABDFE01A14@me.com>

Dear Madam/Sir,
	I can not open the https://docs.python.org/3/archives/python-3.5.1-docs.epub <https://docs.python.org/3/archives/python-3.5.1-docs.epub> in iBooks( Version: 1.4(1099)) on My Macbook Pro with OSX(Version 10.11.2).
	I have try to download epub file twice, same problem shown.

	Please see the attached picture for the details.
	Can you help me

ZHU Quanming
zhuquanming at me.com <mailto:zhuquanming at me.com>

2015-12-31 12:44

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151231/6b3adc10/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Trouble.png
Type: image/png
Size: 49148 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20151231/6b3adc10/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSX Version.png
Type: image/png
Size: 238969 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20151231/6b3adc10/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iBooks Version.png
Type: image/png
Size: 76041 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20151231/6b3adc10/attachment-0005.png>