From report at bugs.python.org  Thu Dec  1 04:28:49 2016
From: report at bugs.python.org (Julien Palard)
Date: Thu, 01 Dec 2016 09:28:49 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1480584529.39.0.0628025544175.issue26483@psf.upfronthosting.co.za>


Julien Palard added the comment:

?digits which do not form decimal radix forms?

> ?forming a form? seems a long way of saying very little. The difference seems a bit vague

> I gather that digits not in the Unicode ?decimal digit? category are often (always?) still decimal digits

I expected them not to, but they often are representative of a base 10 value:

>>> import sys
>>> import unicodedata
>>> chars = ''.join(map(chr, range(sys.maxunicode+1)))
>>> decimals = ''.join(filter(str.isdecimal, chars))
>>> digits = ''.join(filter(str.isdigit, chars))
>>> non_decimal_digits = set(digits) - set(decimals)
>>> from collections import Counter
>>> Counter([unicodedata.digit(char) for char in non_decimal_digits])
Counter({1: 15, 2: 14, 3: 14, 4: 14, 5: 13, 6: 13, 7: 13, 8: 13, 9: 13, 0: 6})

But, note that there's one more in the range [1,4], it's the [Kharosthi](https://en.wikipedia.org/wiki/Kharosthi) numbers, they do not use base 10 but a notation reminiscent of Roman numerals.

So here, clearly, all digits are not an notation for a base 10 value.
 
> but primarily used for a symbolic or typographical meaning more than in a plain number, e.g. superscripts, subscripts and other fonts, added circles and other decorations.

Which also can't be used to form a base 10 number.

So here is another proposition for isdecimal, probably more human friendly:

    Return true if all characters in the string are decimal
    characters and there is at least one character, false
    otherwise. Decimal characters are those that can be used to form
    numbers in base 10, e.g. U+0660, ARABIC-INDIC DIGIT
    ZERO. Formally a decimal character is a character in the Unicode
    General Category "Nd".

And here is another proposition for isdigit, probably friendlier too:

    Return true if all characters in the string are digits and there is at least one
    character, false otherwise.  Digits include decimal characters and digits that need
    special handling, such as the compatibility superscript digits.
    This covers digits which cannot be used to form numbers in base 10, like the Kharosthi numbers.
    Formally, a digit is a character that has the property value
    Numeric_Type=Digit or Numeric_Type=Decimal.

----------

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

From report at bugs.python.org  Thu Dec  1 07:11:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 12:11:20 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1480594279.99.0.0109355344676.issue28755@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> (Ned asked for only release-critical changes to go into 3.6 at the moment.)

Except the documentation changes.

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

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

From report at bugs.python.org  Thu Dec  1 07:22:49 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Thu, 01 Dec 2016 12:22:49 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480594969.57.0.912906072492.issue26363@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

Hi Julien,

You are fully right that it is the builtin module dictionnary which is inserted in eval or exec context.

However, if a "__builtins__" entry is passed to eval or exec, this builtin module dictionnary is modified hence the following work: 

>>> d={"tata":"tata"}
>>> print(eval("tata",{'__builtins__':d}))
tata

----------

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

From report at bugs.python.org  Thu Dec  1 08:31:53 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=)
Date: Thu, 01 Dec 2016 13:31:53 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480599113.14.0.864216214642.issue28733@psf.upfronthosting.co.za>


Micha? Bultrowicz added the comment:

One more update - I had the problem, because I was using monkeypatch.setattr() from Pytest, and assumed that it will work the same as patch(). This assumption turned out to be wrong.

----------

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

From report at bugs.python.org  Thu Dec  1 09:05:35 2016
From: report at bugs.python.org (Francesco Grondona)
Date: Thu, 01 Dec 2016 14:05:35 +0000
Subject: [docs] [issue28851] namedtuples field_names sequence preferred
Message-ID: <1480601135.13.0.00871251418973.issue28851@psf.upfronthosting.co.za>


New submission from Francesco Grondona:

A change by mhettinger in the doc of Python 2 years ago implicitely stated a sequence of strings as preferred way to provide 'field_names' to a namedtuple:

https://github.com/python/cpython/commit/7be6326e09f2062315f995a18ab54baedfd0c0ff

Same change should be integrated in Python 3, I see no reason to prefer the single string version.

----------
assignee: docs at python
components: Documentation
messages: 282177
nosy: docs at python, peentoon
priority: normal
severity: normal
status: open
title: namedtuples field_names sequence preferred
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec  1 09:13:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 14:13:31 +0000
Subject: [docs] [issue28851] namedtuples field_names sequence preferred
In-Reply-To: <1480601135.13.0.00871251418973.issue28851@psf.upfronthosting.co.za>
Message-ID: <1480601611.1.0.774969064509.issue28851@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  1 11:34:42 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Dec 2016 16:34:42 +0000
Subject: [docs] [issue28851] namedtuples field_names sequence preferred
In-Reply-To: <1480601135.13.0.00871251418973.issue28851@psf.upfronthosting.co.za>
Message-ID: <1480610082.23.0.498975028945.issue28851@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the reminder.  I'll make the doc updates after 3.6 is released (we're trying to not make any changes at all right now).

----------
resolution:  -> later
versions:  -Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Dec  1 11:54:37 2016
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 01 Dec 2016 16:54:37 +0000
Subject: [docs] [issue28853] locals() and free variables
Message-ID: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The locals() documentation [1] says that "Free variables are returned by locals() when it is called in function blocks". A free variable inside a function has a global scope, and in fact it is not returned by locals()::

>>> x = 33
>>> def foo():
...     print(x)
...     print(locals())
... 
>>> foo()
33
{}

Maybe "function blocks" here means "closure"? Does the doc mean this?

>>> def foo():
...     x = 33
...     def moo():
...         print(x)
...         print(locals())
...     return moo
... 
>>> moo = foo()
>>> moo()
33
{'x': 33}

In that case, I think it is better to write "closures" instead of 
"function blocks".


[1] https://docs.python.org/3/library/functions.html#locals

----------
assignee: docs at python
components: Documentation
messages: 282200
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: locals() and free variables
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec  1 16:17:10 2016
From: report at bugs.python.org (Julien Palard)
Date: Thu, 01 Dec 2016 21:17:10 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480627030.03.0.0756236860852.issue26363@psf.upfronthosting.co.za>


Julien Palard added the comment:

So, is there still an inconsistency in the documentation?

----------

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

From report at bugs.python.org  Thu Dec  1 16:52:27 2016
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 01 Dec 2016 21:52:27 +0000
Subject: [docs] [issue27779] Sync-up docstrings in C version of the the
 decimal module
In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>
Message-ID: <1480629147.12.0.37949529545.issue27779@psf.upfronthosting.co.za>


Lisa Roach added the comment:

This (should) be the patch with the python docstrings copied over to the C version.

----------
Added file: http://bugs.python.org/file45728/docstrings.patch

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

From report at bugs.python.org  Thu Dec  1 17:48:23 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Thu, 01 Dec 2016 22:48:23 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480632503.39.0.616485056751.issue26363@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

not an inconsisties but in the eval documentaion nothing specify that the builtins propagate between levels updates

----------

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

From report at bugs.python.org  Fri Dec  2 06:32:02 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 02 Dec 2016 11:32:02 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480678322.22.0.562226953352.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

In addition, also if here "function blocks" means nested function, the sentence "Free variables are returned by locals() when it is called in function blocks" I think is wrong. It is true only in case of free variables belonging to the local enclosing scope. For instance, in the following case ``x`` is free in ``moo()``, but it is not in ``locals()``::

>>> x = 10
>>> def foo():
...     def moo():
...         print(x)
...         print(locals())
...     return moo
... 
>>> moo = foo()
>>> moo()
10
{}

I attach a patch with a new description and an example.

PS. Is the rst rendered by Sphinx? In that case, why we are not using the doctest Sphinx extension to test the code examples?

----------
keywords: +patch
Added file: http://bugs.python.org/file45732/locals_func.patch

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

From lisaroach14 at gmail.com  Thu Dec  1 16:44:42 2016
From: lisaroach14 at gmail.com (lisaroach14 at gmail.com)
Date: Thu, 01 Dec 2016 21:44:42 -0000
Subject: [docs] Sync-up docstrings in C version of the the decimal
 module (issue 27779)
Message-ID: <20161201214442.29580.99535@psf.upfronthosting.co.za>

Thanks Stefan! I added a couple of notes to your comments, I'll upload
the new draft in a moment.


https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h
File Modules/_decimal/docstrings.h (left):

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#oldcode34
Modules/_decimal/docstrings.h:34: Return a context manager that will set
the default context to a copy of ctx\n\
On 2016/10/23 21:39:46, skrah wrote:
> This is actually important in the age of asyncio. It returns *and
sets* the
> thread's default context.
> 
> I prefer the existing wording here.

Done.

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#oldcode109
Modules/_decimal/docstrings.h:109: the same numeric value but different
representations compare unequal\n\
On 2016/10/23 21:39:46, skrah wrote:
> I'd leave this in.  I tried to give examples only when something
unexpected
> happens.  This is one of the cases.

Done.

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h
File Modules/_decimal/docstrings.h (right):

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#newcode244
Modules/_decimal/docstrings.h:244: Represents the number as a triple
tuple, to show the internals exactly as\n\
On 2016/10/23 21:39:46, skrah wrote:
> This is outdated for the Python version and wrong for the C version.

For python 3.7 it looks correct to me?

>>> Decimal(10).as_tuple()
DecimalTuple(sign=0, digits=(1, 0), exponent=0)

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#newcode351
Modules/_decimal/docstrings.h:351: Compares two operands using their
abstract representation rather than\n\
On 2016/10/23 21:39:46, skrah wrote:
> Everyone has a preferred form. I think Guido prefers the imperative
"Compare"
> (it may be in a PEP somewhere).

Done.

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#newcode405
Modules/_decimal/docstrings.h:405: Returns a copy of the operand with
the sign set to 0. This operation is unaffected by\n\
On 2016/10/23 21:59:26, skrah wrote:
> I think "sign set to zero" is a bit confusing for the C version.
"absolute
> value" sounds fine to me.

Done.

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#newcode405
Modules/_decimal/docstrings.h:405: Returns a copy of the operand with
the sign set to 0. This operation is unaffected by\n\
On 2016/10/23 21:59:26, skrah wrote:
> I think "sign set to zero" is a bit confusing for the C version.
"absolute
> value" sounds fine to me.

Done.

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#newcode432
Modules/_decimal/docstrings.h:432: Copies the second operand's sign to
the first one.\n\
On 2016/10/23 21:39:46, skrah wrote:
> That sounds as if it is a destructive update.

Done.

https://bugs.python.org/review/27779/diff/18450/Modules/_decimal/docstrings.h#newcode739
Modules/_decimal/docstrings.h:739: value of that digit and without
limiting the resulting exponent).\n\
On 2016/10/23 21:39:46, skrah wrote:
> Personally, I have a hard time understanding this explanation.

I agree this is confusing. It is taken directly from the specification,
I worry that clarifying the wording could misrepresent the definition,
but the C docstring is a lot clearer. I'm not sure which would be better
to include.

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

From report at bugs.python.org  Fri Dec  2 09:21:40 2016
From: report at bugs.python.org (Julien Palard)
Date: Fri, 02 Dec 2016 14:21:40 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480688500.79.0.818214035028.issue28853@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi, thanks for reporting,

Variables are defined in python docs? by:

> If a name is bound in a block, it is a local variable of that block, unless declared as nonlocal or global. If a name is bound at the module level, it is a global variable. (The variables of the module code block are local and global.) If a variable is used in a code block but not defined there, it is a free variable.

According to this definition, global variables used in a code block are free variable, is this intentional? I think so, but can't be sure, maybe someone is seeing this as "globals are NOT free variables", in this case, this definition should probably be enhanced.

If I'm right, maybe we should just change "Free variables are returned"? to "Non-global free variables are returned"??

----------
nosy: +mdk

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

From report at bugs.python.org  Fri Dec  2 09:58:04 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 02 Dec 2016 14:58:04 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480690684.15.0.0711340398368.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Yes, it is the same. "Free variables belonging to the enclosing local namespaces" are "non-global free variables". In order for the reader to better contextualize the sentence, I think it is worth keeping the code example in the patch.

----------

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

From report at bugs.python.org  Fri Dec  2 10:17:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Dec 2016 15:17:07 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480691827.15.0.579466383562.issue28853@psf.upfronthosting.co.za>


R. David Murray added the comment:

To answer the parenthetical question (I haven't looked at the doc issue itself), we don't doctest the examples because most of them were written before sphinx grew a doctest extension, so a lot of them don't pass for reasons that have nothing to do with code validity.  Issues and patches for making the doctests pass are welcome, and we have applied a number of them.  There is a lot of work to do before we could add running doctest to our doc buildbot, though.

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

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

From report at bugs.python.org  Fri Dec  2 12:48:42 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 02 Dec 2016 17:48:42 +0000
Subject: [docs] [issue28794] inspect.isasyncgen and
 inspect.isasyncgenfunction aren't documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1480700922.01.0.908727379735.issue28794@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Can anyone review this please? :)

Thanks.

----------

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

From report at bugs.python.org  Fri Dec  2 15:19:55 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 02 Dec 2016 20:19:55 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480709995.95.0.234089529598.issue28853@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

FWIW the definition of free variables can be found in the Language Reference at section 4.2.1. "Binding of names" [1].
The list of the free variables of a user defined function can be accessed through the __closure__ function attribute, a tuple. The function attributes are listed in the Language Reference
at section 3.2. "The standard type hierarchy" [2]. In the example given at msg282236, the value of x would be printed by the statement:
    print(moo.__closure__[0].cell_contents)

[1]https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
[2] https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy

----------
nosy: +xdegaye

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

From report at bugs.python.org  Fri Dec  2 16:23:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 21:23:29 +0000
Subject: [docs] [issue19795] Formatting of True/False/None in docs
In-Reply-To: <1385457525.93.0.980812903017.issue19795@psf.upfronthosting.co.za>
Message-ID: <1480713809.47.0.474215135691.issue19795@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  2 16:34:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 21:34:54 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
 module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <20161202213451.28343.69107.7BB5A7AF@psf.io>


Roundup Robot added the comment:

New changeset 5b40d81e8883 by Serhiy Storchaka in branch '2.7':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/5b40d81e8883

New changeset d64e37b9204e by Serhiy Storchaka in branch '3.5':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/d64e37b9204e

New changeset 62c9a89a2103 by Serhiy Storchaka in branch '3.6':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/62c9a89a2103

New changeset c642c597d05c by Serhiy Storchaka in branch 'default':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/c642c597d05c

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

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

From report at bugs.python.org  Fri Dec  2 17:28:32 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 02 Dec 2016 22:28:32 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
Message-ID: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>


New submission from Marco Buttu:

With Python 3.7.0a0  and sphinx-build 1.4.9, this was the result before applying the patch:

Doctest summary
===============
   80 tests
    8 failures in tests
    0 failures in setup code
    0 failures in cleanup code
build finished with problems, 139 warnings.

After applaying the patch there are 0 failures in 84 tests. All the doctests also pass with Python 3.6 and 3.5. I skipped three tests (doctest: +SKIP) because their output is random (iterating over dictionary keys).

----------
assignee: docs at python
components: Documentation
files: configparser.patch
keywords: patch
messages: 282258
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Fixed all the doctest failures in Doc/library/configparser.rst
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45733/configparser.patch

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

From report at bugs.python.org  Fri Dec  2 20:21:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 01:21:49 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480728109.12.0.845406162886.issue28853@psf.upfronthosting.co.za>


Martin Panter added the comment:

Marco, your patch removes the description for class blocks. Is that your intent, or just an accident? See r53954.

My understanding is ?function block? is there to distinguish these three modes:

def foo():
    # Function block
    print(locals())

class Bar:
    # Class block
    print(locals())

# Module level
print(locals())

There are patches proposed at Issue 17546 which also address this reference to ?free variables?. Perhaps you could provide feedback on them?

Also see Issue 26683 and Issue 12165, about what free variables, locals, nonlocals, non-globals, etc can mean to different people.

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

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

From report at bugs.python.org  Fri Dec  2 20:44:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 01:44:38 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480729478.8.0.0978405032408.issue28853@psf.upfronthosting.co.za>


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


----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Dec  2 21:32:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 02:32:54 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1480732374.83.0.427453121989.issue22057@psf.upfronthosting.co.za>


Martin Panter added the comment:

?the current mapping of '__builtins__' is copied into *globals* ?

That sounds like we insert each individual builtin name, i.e. globals.update(builtins_mapping). But my understanding is that it is the __builtins__ global variable that is affected:

globals["__builtins__"] = builtins_mapping

What about borrowing the wording from exec():

If the *globals* dictionary is present and lacks ?__builtins__?, a reference to the current mapping of ?__builtins__? is inserted under that key . . .

See also Issue 26363, which also covers this problem.

----------
nosy: +martin.panter
stage: needs patch -> patch review
versions: +Python 3.6, Python 3.7 -Python 3.4

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

From vadmium+py at gmail.com  Fri Dec  2 21:38:20 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sat, 03 Dec 2016 02:38:20 -0000
Subject: [docs] __builtins__ propagation is misleading described in exec and
 eval documentation (issue 26363)
Message-ID: <20161203023820.20730.21996@psf.upfronthosting.co.za>


https://bugs.python.org/review/26363/diff/19291/Doc/library/functions.rst
File Doc/library/functions.rst (right):

https://bugs.python.org/review/26363/diff/19291/Doc/library/functions.rst#newcode399
Doc/library/functions.rst:399: present and  does not contain a value for
the key '__builtins__',
What was wrong with the original? Your new wording raising questions
about whether you can have a key without a value, is None considered a
value, etc.

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

From report at bugs.python.org  Fri Dec  2 22:06:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 03:06:47 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480734407.95.0.552462409411.issue26363@psf.upfronthosting.co.za>


Martin Panter added the comment:

Xavier, you are welcome to propose your own version of the text, or build on Julien?s. See also Issue 22057, about copying all globals vs builtins.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Dec  2 23:44:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 04:44:05 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
 dict get updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1480740245.55.0.648855494693.issue17546@psf.upfronthosting.co.za>


Martin Panter added the comment:

Some minor tweaks to my earlier patch:
* list comprehension ? comprehension
* time it is called ? time of the call

----------
versions: +Python 3.6, Python 3.7 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file45735/locals_doc.04.patch

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

From report at bugs.python.org  Sat Dec  3 07:25:03 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 12:25:03 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480767903.47.0.496704743578.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Martin, I removed the class blocks by accident. In any case, I reject the patch by myself, because to me the definition of "free variable" is not clear. 
The documentation [1] says: "If a variable is used in a code block but not defined there, it is a free variable." According to this description,  it seems to me that ``x`` is free both in ``foo()`` and in ``moo()``:


>>> def foo():
...     print(x)
...     def moo():
...         print(x)
...     return moo


But actually for the code object it is not:


>>> foo.__code__.co_freevars
()
>>> moo.__code__.co_freevars
('x',)


Thank you for your feedback, I will continue the discussion in issue 26683.

[1] https://docs.python.org/3/reference/executionmodel.html#naming-and-binding

----------

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

From report at bugs.python.org  Sat Dec  3 07:37:58 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 12:37:58 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480768678.31.0.859966638335.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Sorry, in the last example, for the code object ``x`` is not free both in ``foo()`` and ``moo()``, but this does not affect the conclusion.

----------

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

From report at bugs.python.org  Sat Dec  3 08:56:18 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 13:56:18 +0000
Subject: [docs] [issue26683] Questionable terminology for describing what
 locals() does
In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>
Message-ID: <1480773378.94.0.43794987954.issue26683@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The documentation [1] says: "If a variable is used in a code block but not defined there, it is a free variable." According to this description,  it seems to me that the variable ``x`` is free in ``foo()``::

  >>> def foo():
  ...     print(x)

But actually for the code object it is not::

  >>> foo.__code__.co_freevars
  ()

The meaning of free variable used for the code object is consistent with the ``locals()`` documentation [2]: "Free variables are returned by locals() when it is called in function blocks". In fact, in the following code ``x` is not a free variable for ``locals()``::

  >>> def foo():
  ...     print(x)
  ...     print(locals())
  ... 
  >>> x = 3
  >>> foo()
  3
  {}

So, I thing there is an inconsistency between the definition of "free variable" given in [1] and the meaning of "free variable" both in the code object and in the ``locals()`` documentation [2]. 
But if we change the definition of "free variable" according to the meaning of both the code object and ``locals()``, I am afraid we go in the wrong direction, because I suspect for most people the proper definition of free variable is the one given in [1]. Also for Wikipedia [3]: "In computer programming, the term free variable refers to variables used in a function that are neither local variables nor parameters of that function.".

Instead, if we keep or remove the definition of "free variable" given in [1], I agree with Terry to change the ``locals()`` documentation, writing that "``locals()`` includes also the locals of the surrounding function contexts, even though they are called 'nonlocal' within the nested function.". Maybe it is also worth adding a shell example, to better clarify. 

So, at the end, to me the ideal solution would be to keep in [1] the current definition of "free variable", to change the ``locals()`` documentation according to Terry suggestion, and to change the behavior of ``code.co_freevars`` (maybe not only this) in order to fit the definition.


[1] https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
[2] https://docs.python.org/3/library/functions.html#locals
[3] https://en.wikipedia.org/wiki/Free_variables_and_bound_variables

----------
nosy: +marco.buttu

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

From report at bugs.python.org  Sat Dec  3 10:44:06 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 03 Dec 2016 15:44:06 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480779846.36.0.287929362624.issue28853@psf.upfronthosting.co.za>


Julien Palard added the comment:

Should this issue be closed so?

----------

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

From report at bugs.python.org  Sat Dec  3 13:07:06 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 18:07:06 +0000
Subject: [docs] [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480788426.65.0.132501178398.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I close it because the meaning of "free variable" is not clear. We are discussing about it in issue 26683.

----------
resolution:  -> postponed
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 13:58:02 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Dec 2016 18:58:02 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480791482.38.0.903057324116.issue28860@psf.upfronthosting.co.za>


Brett Cannon added the comment:

For the iteration of dictionary keys, can you pass the keys through sorted() to have a deterministic order?

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

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

From report at bugs.python.org  Sat Dec  3 14:40:44 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 19:40:44 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480794044.7.0.994536178086.issue28860@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I usually keep the code examples focused, because I think extra code added just in order to have more tests can get the example less clear. But of course, there is an important downside :/ So, if your policy and goal is to have a better coverage of the code examples, here is another patch that uses sorted().

Thank you very much for your time :-)

----------
Added file: http://bugs.python.org/file45741/configparser2nd.patch

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

From report at bugs.python.org  Sat Dec  3 16:48:05 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 21:48:05 +0000
Subject: [docs] [issue28863] Doc/includes/*.py files and doctests
Message-ID: <1480801685.13.0.102040139052.issue28863@psf.upfronthosting.co.za>


New submission from Marco Buttu:

In the Doc/includes directory, some of the *.py file names have a dash character. For instance: Doc/includes/tzinfo-examples.py. I am trying to make all of the code examples pass the doctests, and I usually need to import from these files some code. Importing from these modules also allow us to test them, and I think that is important because their code is included in the documentation.

There are two problems:

1) I can not directly import them, because of the - character, so I have to use __import__('file-name') and write other ugly tricks. I can import them in the setuptests, so the reader will not see these imports, but it is still ugly, and in addition the code examples will be not complete, and the reader will not be able to try the code

2) the dash in the file names is un-pythonic. As the PEP 0008 says, the preferred way is to use underscores: "Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability."

In conclusion, I propose to change the Doc/includes/*.py file names, replacing the dash character with an underscore. If you agree, I will do it step by step: I will change each file name only when I will work with the related documentation and code examples. 

PS. To include these files in the code examples, I also need to add the Doc/includes directory to the sys.path (in conf.py).

----------
assignee: docs at python
components: Documentation
messages: 282307
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Doc/includes/*.py files and doctests
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sat Dec  3 18:26:19 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 23:26:19 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480807579.44.0.667772954081.issue28860@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Marco, thank you for adding more energy to improving the docs. #27200 is the master issue for fixing failing doc doctests.  The goal is to be able to have a buildbot run 'make doctest' or the Windows equivalent and expect success.

For this issue, I mildly agree with Brett.  Adding sorted is something a user might do.  But I am curious what policy Zack followed for the other 9 patches.

----------
nosy: +terry.reedy, zach.ware

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

From report at bugs.python.org  Sat Dec  3 18:27:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 23:27:48 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480807668.32.0.902443042494.issue28860@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For some reason, not obvious to me, these patches cannot be reviewed on Rietveld.

----------

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

From report at bugs.python.org  Sun Dec  4 00:30:32 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 04 Dec 2016 05:30:32 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480829432.41.0.321999910155.issue28860@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Indeed, thank you Marco for continuing this work!

The patches that I committed [1] were mostly done by Jelle Zijlstra.  There were not many tests that had dict ordering issues; but it looks like we used sorted() rather than list() in a few places.  I think using sorted() here is fine as well (though for the third one, I'd recommend turning the list comprehension into a generator expression argument to sorted, rather than sticking sorted() in the middle of the listcomp).

As far as why these patches are not compatible with Rietveld, they appear to have been generated by `diff` between two discrete files rather than by `hg diff` or `git diff`, and Reitveld can't find the files as named to be able to apply the patch.


[1] Viewable in aggregate here: https://hg.python.org/cpython/rev/769355e031:d0302d8ecbc1

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

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

From report at bugs.python.org  Sun Dec  4 04:23:17 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 04 Dec 2016 09:23:17 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480843397.91.0.356463782433.issue28860@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Here is a 3rd patch. I used a generator expression argument to ``sorted()``, as recommend by Zachary. Thank you very much for all your suggestions

----------
Added file: http://bugs.python.org/file45745/configparser3rd.patch

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

From report at bugs.python.org  Sun Dec  4 05:07:52 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 04 Dec 2016 10:07:52 +0000
Subject: [docs] [issue28863] Doc/includes/*.py files and doctests
In-Reply-To: <1480801685.13.0.102040139052.issue28863@psf.upfronthosting.co.za>
Message-ID: <1480846072.92.0.0386562199821.issue28863@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Here is the patch for the Sphinx conf.py file.

----------
keywords: +patch
Added file: http://bugs.python.org/file45746/conf.py.patch

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

From aayushsanjeet at gmail.com  Sat Dec  3 04:26:44 2016
From: aayushsanjeet at gmail.com (Aayush Aishwani)
Date: Sat, 3 Dec 2016 14:56:44 +0530
Subject: [docs] Python Documentation
Message-ID: <CAL+BAYAf0frGsbjjSiBk=ppSpUiY0wJvnE_B_xZ-tezG9-oRjQ@mail.gmail.com>

Hi Sir/Mam,
I want to learn Python as i have started my carrier with python programm .
Since 6 month i am working in python but i want to build my knowledge up to
advance level in python .
for that what is good material for learning python. i want python
ocumentation is it enough for learning python.
Thanks & regards
Aayush Aishwani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161203/7aa9c69a/attachment.html>

From z23color at 163.com  Sun Dec  4 03:47:10 2016
From: z23color at 163.com (Volunteer)
Date: Sun, 4 Dec 2016 16:47:10 +0800 (CST)
Subject: [docs] is (big-endian) ?
Message-ID: <48b4f130.204a7f.158c903f80b.Coremail.z23color@163.com>

https://docs.python.org/3/library/struct.html


7.1.2.1. Byte Order, Size, and Alignment

Native byte order is big-endian or little-endian, depending on the host system. For example, Intel x86 and AMD64 (x86-64) are little-endian; Motorola 68000 and PowerPC G5 are big-endian; ARM and Intel Itanium feature switchable endianness (bi-endian). Use sys.byteorder to check the endianness of your system.




endianness (bi-endian) error?

is (big-endian) ?


.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161204/5c41324a/attachment.html>

From report at bugs.python.org  Sun Dec  4 15:58:50 2016
From: report at bugs.python.org (rm)
Date: Sun, 04 Dec 2016 20:58:50 +0000
Subject: [docs] [issue28868] Python advertising BeOpen.com domain
Message-ID: <1480885130.58.0.883426761296.issue28868@psf.upfronthosting.co.za>


New submission from rm:

There is BeOpen attribution in __builtins__() call, that may confuse users and generate some traffic to unrelated domain.

For example:

>>> import smtplib
>>> smtplib.__builtins__
<...>
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.
<...>

but beopen.com resolves to domain hosting stub page. May be this string should be changed to just BeOpen, or removed altogether.

----------
assignee: docs at python
components: Documentation
messages: 282361
nosy: cvs-src, docs at python
priority: normal
severity: normal
status: open
title: Python advertising BeOpen.com domain
versions: Python 3.5

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

From report at bugs.python.org  Sun Dec  4 16:03:08 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 04 Dec 2016 21:03:08 +0000
Subject: [docs] [issue28868] Python advertising BeOpen.com domain
In-Reply-To: <1480885130.58.0.883426761296.issue28868@psf.upfronthosting.co.za>
Message-ID: <1480885387.94.0.489001743425.issue28868@psf.upfronthosting.co.za>


SilentGhost added the comment:

It's part of the copyright notice, just removing it is probably not an option.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Dec  4 16:10:38 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 04 Dec 2016 21:10:38 +0000
Subject: [docs] [issue28868] Python advertising BeOpen.com domain
In-Reply-To: <1480885130.58.0.883426761296.issue28868@psf.upfronthosting.co.za>
Message-ID: <1480885838.4.0.379854659953.issue28868@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Part of the copyright notice, as SilentGhost mentioned. This can't be removed.

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

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

From report at bugs.python.org  Mon Dec  5 02:05:09 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:05:09 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1480921509.23.0.10060841009.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've switched to using Vinay Sajip's "sarge" for my own subprocess invocation needs, which uses a similar all-in-one "run" API (albeit quite a different approach to capturing output).

Accordingly, I don't think there's anything useful to be done specifically in the context of this issue - any energy that might be spent here would likely be spent more constructively on things like making the pipe encoding easier to configure, or reducing the risk of deadlocks due to OS-level buffer size limits.

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

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

From berker.peksag at gmail.com  Mon Dec  5 02:54:54 2016
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 5 Dec 2016 10:54:54 +0300
Subject: [docs] is (big-endian) ?
In-Reply-To: <48b4f130.204a7f.158c903f80b.Coremail.z23color@163.com>
References: <48b4f130.204a7f.158c903f80b.Coremail.z23color@163.com>
Message-ID: <CAF4280+5zRn_PrLU0NAWiYPtS0CaaqEiwcOYnDhe_V2QoatoAQ@mail.gmail.com>

On Sun, Dec 4, 2016 at 11:47 AM, Volunteer <z23color at 163.com> wrote:
> https://docs.python.org/3/library/struct.html
>
> 7.1.2.1. Byte Order, Size, and Alignment
>
> Native byte order is big-endian or little-endian, depending on the host
> system. For example, Intel x86 and AMD64 (x86-64) are little-endian;
> Motorola 68000 and PowerPC G5 are big-endian; ARM and Intel Itanium feature
> switchable endianness (bi-endian). Use sys.byteorder to check the endianness
> of your system.
>
>
> endianness (bi-endian) error?
>
> is (big-endian) ?

Hi Volunteer,

bi-endian is not a typo. Quoting from https://en.wikipedia.org/wiki/Endianness

> There are also some bi-endian processors that operate in either little-endian or big-endian mode.

--Berker

From berker.peksag at gmail.com  Mon Dec  5 06:27:28 2016
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Mon, 05 Dec 2016 11:27:28 -0000
Subject: [docs] Fixed all the doctest failures in
 Doc/library/configparser.rst (issue 28860)
Message-ID: <20161205112728.9794.94075@psf.upfronthosting.co.za>


http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst
File Doc/library/configparser.rst (left):

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#oldcode73
Doc/library/configparser.rst:73: >>> import configparser
Can this be removed now? (since we've already import it in testsetup?)

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#oldcode576
Doc/library/configparser.rst:576: >>> from configparser import
ConfigParser, ExtendedInterpolation
Perhaps we can change this example to use configparser.foo format and
remove this line too?

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst
File Doc/library/configparser.rst (right):

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#newcode476
Doc/library/configparser.rst:476: >>> sorted(parser.sections())
I'd skip this one like you did in your first patch.

As a reader, I find using sorted() here less readable and more
confusing.

+1 for using sorted() in the iteration examples (but I'd skip them too
since they may have already tested in Lib/test/test_configparser.py)

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

From anufant at gmail.com  Mon Dec  5 05:34:24 2016
From: anufant at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQntC90YPRhNGA0LjQtdCy?=)
Date: Mon, 5 Dec 2016 13:34:24 +0300
Subject: [docs] Python.org tutorial multiple-inheritance chapter bug
Message-ID: <CAAVuVHK4X_brzEP4dCSc9K+uD6aSqdca2ZLVxct3-Mxm-Sx5FA@mail.gmail.com>

https://docs.python.org/3.6/tutorial/classes.html#multiple-inheritance

Hello.
There is a phrase about searching in base classes in text on link above:

Thus, if an attribute is not found in DerivedClassName, it is searched for
in Base1, then (recursively) in the base classes of Base1, and if it was
not found there, it was searched for in Base2, and so on.

I think it's a bug in a documentation and newer version of Python search
methods in other way, using c3-linearization method.



-- 
Onufriev Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161205/7d5d8246/attachment-0001.html>

From djrmich at gmail.com  Mon Dec  5 05:06:48 2016
From: djrmich at gmail.com (Dave R)
Date: Mon, 5 Dec 2016 05:06:48 -0500
Subject: [docs] Just open a py file I have saved
Message-ID: <CA+Y1qhCcQ2D0VnWnsArrP-W9BH9uGZe_C59L1CjzYNRQ884kgg@mail.gmail.com>

I am using windows ten.  I invoke python by putting myself in the
Python35-32 folder and running python,exe.

Why cant I just open and save valid py files ?
I can click on a py file that is valid python commands and it runs,
But how can I open and save such files from within the interpreter ?

Thank you.

Dave Richter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161205/0bd5b493/attachment.html>

From marco.buttu at gmail.com  Mon Dec  5 07:20:11 2016
From: marco.buttu at gmail.com (marco.buttu at gmail.com)
Date: Mon, 05 Dec 2016 12:20:11 -0000
Subject: [docs] Fixed all the doctest failures in
 Doc/library/configparser.rst (issue 28860)
Message-ID: <20161205122011.9794.49188@psf.upfronthosting.co.za>

Reviewers: berkerpeksag,


http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst
File Doc/library/configparser.rst (left):

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#oldcode73
Doc/library/configparser.rst:73: >>> import configparser
On 2016/12/05 12:27:28, berkerpeksag wrote:
> Can this be removed now? (since we've already import it in testsetup?)

I think it is really important to keep it at the beginning, because the
code we show to the reader has to be working code. The user has to
import configparser in the shell before executing manually the example.
The import in the testsetup has just the purpose to avoid the same
import in all the examples, when they belong to the same session.

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst
File Doc/library/configparser.rst (right):

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#newcode476
Doc/library/configparser.rst:476: >>> sorted(parser.sections())
On 2016/12/05 12:27:28, berkerpeksag wrote:
> I'd skip this one like you did in your first patch.
> 
> As a reader, I find using sorted() here less readable and more
confusing.
> 
> +1 for using sorted() in the iteration examples (but I'd skip them too
since
> they may have already tested in Lib/test/test_configparser.py)


I agree with you, it is less readable and more confusing. Sometimes we
need a treadoff, and when the API is enough stable that the test result,
in all likelihood, will not change in future Python versions, we can
take the risk to skip the test.



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

Affected files:
  Doc/library/configparser.rst


diff -r 16350c1f81a1 Doc/library/configparser.rst
--- a/Doc/library/configparser.rst	Sun Dec 04 10:22:36 2016 +0200
+++ b/Doc/library/configparser.rst	Sun Dec 04 10:12:10 2016 +0100
@@ -68,6 +68,10 @@
 :mod:`configparser` classes can read and write such files.  Let's start by
 creating the above configuration file programmatically.
 
+.. testsetup::
+
+   import configparser
+
 .. doctest::
 
    >>> import configparser
@@ -116,13 +120,13 @@
    'no'
    >>> topsecret['Port']
    '50022'
-   >>> for key in config['bitbucket.org']: print(key)
-   ...
+   >>> for key in sorted(config['bitbucket.org']): 
+   ...     print(key)
+   compression
+   compressionlevel
+   forwardx11
+   serveraliveinterval
    user
-   compressionlevel
-   serveraliveinterval
-   compression
-   forwardx11
    >>> config['bitbucket.org']['ForwardX11']
    'yes'
 
@@ -469,10 +473,10 @@
      ...                                'bar': 'y',
      ...                                'baz': 'z'}
      ... })
-     >>> parser.sections()
-     ['section3', 'section2', 'section1']
-     >>> [option for option in parser['section3']]
-     ['baz', 'foo', 'bar']
+     >>> sorted(parser.sections())
+     ['section1', 'section2', 'section3']
+     >>> sorted(option for option in parser['section3'])
+     ['bar', 'baz', 'foo']
 
   In these operations you need to use an ordered dictionary as well:
 
@@ -514,8 +518,6 @@
 
   .. doctest::
 
-     >>> import configparser
-
      >>> sample_config = """
      ... [mysqld]
      ...   user = mysql
@@ -571,7 +573,9 @@
   values with characters used as comment prefixes.  When in doubt, avoid
   setting *inline_comment_prefixes*.  In any circumstances, the only way of
   storing comment prefix characters at the beginning of a line in multiline
-  values is to interpolate the prefix, for example::
+  values is to interpolate the prefix, for example:
+
+  .. doctest::
 
     >>> from configparser import ConfigParser, ExtendedInterpolation
     >>> parser = ConfigParser(interpolation=ExtendedInterpolation())
@@ -597,11 +601,11 @@
     ...   line #3
     ... """)
     >>> print(parser['hashes']['shebang'])
-
+    <BLANKLINE>
     #!/usr/bin/env python
     # -*- coding: utf-8 -*-
     >>> print(parser['hashes']['extensions'])
-
+    <BLANKLINE>
     enabled_extension
     another_extension
     yet_another_extension
@@ -755,6 +759,7 @@
 
   .. doctest::
 
+     >>> import re
      >>> config = """
      ... [Section 1]
      ... option = value
@@ -762,11 +767,11 @@
      ... [  Section 2  ]
      ... another = val
      ... """
-     >>> typical = ConfigParser()
+     >>> typical = configparser.ConfigParser()
      >>> typical.read_string(config)
      >>> typical.sections()
      ['Section 1', '  Section 2  ']
-     >>> custom = ConfigParser()
+     >>> custom = configparser.ConfigParser()
      >>> custom.SECTCRE = re.compile(r"\[ *(?P<header>[^]]+?) *\]")
      >>> custom.read_string(config)
      >>> custom.sections()



From berker.peksag at gmail.com  Mon Dec  5 07:29:56 2016
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Mon, 05 Dec 2016 12:29:56 -0000
Subject: [docs] Fixed all the doctest failures in
 Doc/library/configparser.rst (issue 28860)
Message-ID: <20161205122956.1460.29070@psf.upfronthosting.co.za>


http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst
File Doc/library/configparser.rst (left):

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#oldcode73
Doc/library/configparser.rst:73: >>> import configparser
On 2016/12/05 13:20:11, marco.buttu wrote:
> On 2016/12/05 12:27:28, berkerpeksag wrote:
> > Can this be removed now? (since we've already import it in
testsetup?)
> 
> I think it is really important to keep it at the beginning, because
the code we
> show to the reader has to be working code. The user has to import
configparser
> in the shell before executing manually the example. The import in the
testsetup
> has just the purpose to avoid the same import in all the examples,
when they
> belong to the same session.

Yes, that's a good point. I didn't notice it was the first example of
the documentation.

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

From report at bugs.python.org  Mon Dec  5 09:03:48 2016
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Mon, 05 Dec 2016 14:03:48 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1480946628.56.0.587780857837.issue28845@psf.upfronthosting.co.za>


Eric N. Vander Weele added the comment:

I have been able to test the example without a segmentation fault.

$ python3.5
Python 3.5.2 (default, Nov 17 2016, 10:45:58) [C] on aix7
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
>>> from curses import panel
>>> def mkpanel(scr):
...         win = curses.newwin(8,8,1,1)
...         pan = panel.new_panel(win)
...
>>> curses.wrapper(mkpanel)
>>>

----------

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

From marco.buttu at gmail.com  Mon Dec  5 11:30:41 2016
From: marco.buttu at gmail.com (marco.buttu at gmail.com)
Date: Mon, 05 Dec 2016 16:30:41 -0000
Subject: [docs] Fixed all the doctest failures in
 Doc/library/configparser.rst (issue 28860)
Message-ID: <20161205163041.1460.25758@psf.upfronthosting.co.za>


http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst
File Doc/library/configparser.rst (left):

http://bugs.python.org/review/28860/diff/19350/Doc/library/configparser.rst#oldcode73
Doc/library/configparser.rst:73: >>> import configparser
On 2016/12/05 13:29:56, berkerpeksag wrote:
> On 2016/12/05 13:20:11, marco.buttu wrote:
> > On 2016/12/05 12:27:28, berkerpeksag wrote:
> > > Can this be removed now? (since we've already import it in
testsetup?)
> > 
> > I think it is really important to keep it at the beginning, because
the code
> we
> > show to the reader has to be working code. The user has to import
configparser
> > in the shell before executing manually the example. The import in
the
> testsetup
> > has just the purpose to avoid the same import in all the examples,
when they
> > belong to the same session.
> 
> Yes, that's a good point. I didn't notice it was the first example of
the
> documentation.

In any case, the testsetup is not required (we can remove it), because
all the doctests are executed in the same session, and configparser is
imported from the beginning. So, in a final patch, I will remove it

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

From report at bugs.python.org  Mon Dec  5 15:16:44 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:16:44 +0000
Subject: [docs] [issue28089] Document TCP_NODELAY by default
Message-ID: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>


New submission from Ned Deily:

This is marked as a release blocker but, since it's just a doc change, I'm not going to hold 3.6.0 for it.  It would be nice to get it in, though.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Mon Dec  5 16:55:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 21:55:51 +0000
Subject: [docs] [issue28089] Document TCP_NODELAY by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480974951.89.0.198884029442.issue28089@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yury: I don't understand your issue, can you please elaborate? Do you mean that the default value of the TCP_NODELAY changed in Python 3.6? Otherwise, why do you consider it as a release blocker?

The Python 3.6 release must be blocked by a TCP flag? Really?

----------

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

From report at bugs.python.org  Mon Dec  5 17:12:16 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 05 Dec 2016 22:12:16 +0000
Subject: [docs] [issue28089] Document TCP_NODELAY by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480975936.6.0.590434095171.issue28089@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

The change is that TCP_NODELAY option is set by default in 3.6. It was not the case in 3.5.

----------

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

From report at bugs.python.org  Mon Dec  5 17:14:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:14:11 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480976051.82.0.271795571607.issue28089@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Document TCP_NODELAY by default -> asyncio: Document that TCP_NODELAY is now used by default

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

From report at bugs.python.org  Mon Dec  5 17:15:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:15:03 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480976103.37.0.0627929166702.issue28089@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The change is that TCP_NODELAY option is set by default in 3.6. It was not the case in 3.5.

Ah, it's a change in _asyncio_, ok. I missed that from the issue title, so I changed the title.

----------

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

From report at bugs.python.org  Mon Dec  5 17:15:42 2016
From: report at bugs.python.org (wim glenn)
Date: Mon, 05 Dec 2016 22:15:42 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1480976142.81.0.0184813085102.issue28617@psf.upfronthosting.co.za>


wim glenn added the comment:

1 month later.. is newpatch.diff OK to merge or any further improvements needed?  thanks

----------

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

From report at bugs.python.org  Mon Dec  5 22:27:33 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 06 Dec 2016 03:27:33 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480994853.76.0.0624811211883.issue28089@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

I added the following to Doc/library/asyncio-protocol.rst

.. versionchanged:: 3.6.0
   The socket option TCP_NODELAY is now set by default.

Let me know if this patch works.

----------
keywords: +patch
Added file: http://bugs.python.org/file45770/issue28089.patch

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

From report at bugs.python.org  Mon Dec  5 22:44:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 06 Dec 2016 03:44:12 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480995852.4.0.720852442612.issue28089@psf.upfronthosting.co.za>


Berker Peksag added the comment:

+.. versionchanged:: 3.6.0

3.6.0 -> 3.6

+   The socket option TCP_NODELAY is now set by default.

TCP_NODELAY -> ``TCP_NODELAY``

----------
nosy: +berker.peksag
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Dec  5 22:49:45 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 06 Dec 2016 03:49:45 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480996185.72.0.618529436384.issue28089@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Berker :)
Updated.

----------
Added file: http://bugs.python.org/file45772/issue28089v2.patch

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

From report at bugs.python.org  Tue Dec  6 05:00:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 10:00:40 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161206100036.22212.71133.EEC004E9@psf.io>


Roundup Robot added the comment:

New changeset 726308cfe3b5 by Victor Stinner in branch '3.6':
catch_warnings() calls showwarning() if overriden
https://hg.python.org/cpython/rev/726308cfe3b5

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

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

From report at bugs.python.org  Tue Dec  6 05:03:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 10:03:16 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161206100311.28672.92369.C9F94270@psf.io>


Roundup Robot added the comment:

New changeset 150d36dbe3ba by Victor Stinner in branch '3.6':
warnings: Fix the issue number
https://hg.python.org/cpython/rev/150d36dbe3ba

----------

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

From julien+python at palard.fr  Mon Dec  5 15:22:48 2016
From: julien+python at palard.fr (julien+python at palard.fr)
Date: Mon, 05 Dec 2016 20:22:48 -0000
Subject: [docs] hex() documentation: mention "%x" % int (issue 26506)
Message-ID: <20161205202248.9794.38550@psf.upfronthosting.co.za>

I'm not fan of "If prefix "0b" is desired or not", I'm not a native
english but I think it should be changed.


http://bugs.python.org/review/26506/diff/16805/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/26506/diff/16805/Doc/library/functions.rst#newcode92
Doc/library/functions.rst:92: If prefix "0b" is desired or not, you can
use either of the following ways. See
I'm not a big fan of "is desired or not", why not avoiding it with
something like:

"When more flexibility is needed, :func:`format` can also format
hexadecimal strings:"

(If so, please change it on the three different places for consistency).

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

From mark at markjharris.net  Mon Dec  5 21:03:23 2016
From: mark at markjharris.net (Mark)
Date: Mon, 5 Dec 2016 18:03:23 -0800
Subject: [docs] confusing docs for plistlib - how to use 'dump()'
Message-ID: <6C90C46F-4F96-4F4F-8785-2C0A80E30CFF@markjharris.net>

Hi there - 

This regards the page for plistlib:

https://docs.python.org/dev/library/plistlib.html#plistlib.dumps <https://docs.python.org/dev/library/plistlib.html#plistlib.dumps>

I ran in to this problem described here:

http://technology.siprep.org/how-to-read-from-and-write-to-plist-files-using-python/ <http://technology.siprep.org/how-to-read-from-and-write-to-plist-files-using-python/>

It?s just not clear in the docs how to use ?dump? - and the only way I could get a plist to be created is to use the deprecated plistlib.writePlist function.

Does it have to be imported from some other module?

Mark


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

From z23color at 163.com  Tue Dec  6 07:51:48 2016
From: z23color at 163.com (Volunteer)
Date: Tue, 6 Dec 2016 20:51:48 +0800 (CST)
Subject: [docs] is (big-endian) ?
In-Reply-To: <CAF4280+5zRn_PrLU0NAWiYPtS0CaaqEiwcOYnDhe_V2QoatoAQ@mail.gmail.com>
References: <48b4f130.204a7f.158c903f80b.Coremail.z23color@163.com>
 <CAF4280+5zRn_PrLU0NAWiYPtS0CaaqEiwcOYnDhe_V2QoatoAQ@mail.gmail.com>
Message-ID: <15c0bf92.57a0.158d430aa2a.Coremail.z23color@163.com>

Thank you! explain .
? 2016-12-05 15:54:54?"Berker Peksa?" <berker.peksag at gmail.com> ???
On Sun, Dec 4, 2016 at 11:47 AM, Volunteer <z23color at 163.com> wrote:
> https://docs.python.org/3/library/struct.html
>
> 7.1.2.1. Byte Order, Size, and Alignment
>
> Native byte order is big-endian or little-endian, depending on the host
> system. For example, Intel x86 and AMD64 (x86-64) are little-endian;
> Motorola 68000 and PowerPC G5 are big-endian; ARM and Intel Itanium feature
> switchable endianness (bi-endian). Use sys.byteorder to check the endianness
> of your system.
>
>
> endianness (bi-endian) error?
>
> is (big-endian) ?

Hi Volunteer,

bi-endian is not a typo. Quoting from https://en.wikipedia.org/wiki/Endianness

> There are also some bi-endian processors that operate in either little-endian or big-endian mode.

--Berker

From mariatta.wijaya at gmail.com  Tue Dec  6 12:19:00 2016
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 6 Dec 2016 09:19:00 -0800
Subject: [docs] confusing docs for plistlib - how to use 'dump()'
In-Reply-To: <6C90C46F-4F96-4F4F-8785-2C0A80E30CFF@markjharris.net>
References: <6C90C46F-4F96-4F4F-8785-2C0A80E30CFF@markjharris.net>
Message-ID: <CAGbohnbgnNOGUc=k+z4x6Y=gTHF3gJ_iSKS2mbAT2=g26dkFLw@mail.gmail.com>

Hi,

It is stated in the docs that fp parameter in plistlib.dump is a writable
binary file object, which can be created by calling open() .
file object and how to create it are described here:
https://docs.python.org/3/glossary.html#term-file-object

Perhaps an improvement to the docs is to provide such link?

Here's an example demonstrating how to use plistlib.dump:

import plistlib
p = {"name": "James Bond",
      "code": 0.07}
plistlib.dump(p, open("./output.xml", "wb+"))

HTH


On Dec 6, 2016 5:49 AM, "Mark" <mark at markjharris.net> wrote:

> Hi there -
>
> This regards the page for plistlib:
>
> https://docs.python.org/dev/library/plistlib.html#plistlib.dumps
>
> I ran in to this problem described here:
>
> http://technology.siprep.org/how-to-read-from-and-write-to-p
> list-files-using-python/
>
> It?s just not clear in the docs how to use ?dump? - and the only way I
> could get a plist to be created is to use the deprecated
> plistlib.writePlist function.
>
> Does it have to be imported from some other module?
>
> Mark
>
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161206/760389f8/attachment.html>

From report at bugs.python.org  Tue Dec  6 15:27:33 2016
From: report at bugs.python.org (Julien Castiaux)
Date: Tue, 06 Dec 2016 20:27:33 +0000
Subject: [docs] [issue28890] logging.handlers: Document that QueueListener
 is a daemon thread
Message-ID: <1481056053.24.0.349342141642.issue28890@psf.upfronthosting.co.za>


Changes by Julien Castiaux <julien.castiaux at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: Julien Castiaux, docs at python
priority: normal
severity: normal
status: open
title: logging.handlers: Document that QueueListener is a daemon thread
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  6 17:30:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 22:30:30 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1481063430.11.0.778632843333.issue28450@psf.upfronthosting.co.za>


Ned Deily added the comment:

Note that 1b162d6e3d01 in Issue27030 (for 3.6.0rc1) has changed the behavior for re.sub replacement templates to produce a deprecation warning in 3.6 while still being treated as an error in 3.7.

----------

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

From report at bugs.python.org  Tue Dec  6 18:31:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 23:31:12 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1481067072.56.0.469508227299.issue28810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because nobody proposed a patch, here is my attempt. Following patch documents opcodes CALL_FUNCTION, CALL_FUNCTION_KW and CALL_FUNCTION_EX.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45780/docs-call-function-opcodes.patch

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

From report at bugs.python.org  Tue Dec  6 19:52:50 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2016 00:52:50 +0000
Subject: [docs] [issue28886] Move deprecated abc module decorators to
 separate section in docs
In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za>
Message-ID: <1481071970.09.0.357741057037.issue28886@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, these are in the "Don't use them in new code, but we have absolutely no plans to actually remove them" documentation-only category of deprecation warning.

However, I'm converting this to a documentation enhancement request, as the documentation could make that status clearer by moving them to a separate "Legacy builtin decorator subclasses" section at the end of https://docs.python.org/3/library/abc.html

Then that section can *start* with the information on simply applying the builtin decorators on top of the abc.abstractproperty() decorator, before moving on to document the available subclasses.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> needs patch
title: Deprecated abstract base class (abc) decorators do not raise DeprecationWarning -> Move deprecated abc module decorators to separate section in docs
type: behavior -> enhancement

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

From report at bugs.python.org  Wed Dec  7 00:36:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 05:36:04 +0000
Subject: [docs] [issue28886] Move deprecated abc module decorators to
 separate section in docs
In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za>
Message-ID: <1481088964.09.0.262449143032.issue28886@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  7 09:49:13 2016
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 07 Dec 2016 14:49:13 +0000
Subject: [docs] [issue28895] Two suggestions for windows.html
Message-ID: <1481122153.16.0.608374359054.issue28895@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

This document is v. useful for Windows Python users:
https://docs.python.org/dev/using/windows.html

However, I think it could be improved as follows:

(1) Explain which Python installer to get (since there are so many)! Even a "get the Windows x86 executable installer if you just want it now!". Alternatively, the https://www.python.org/downloads/windows/ page could begine with a brief explanation of the differences.

(2) Explain the trade-offs between Admin & User install & the effect this has on using pip (e.g., an Admin install may require pip to be used in an Admin console or to be used with the --user option).

----------
assignee: docs at python
components: Documentation
messages: 282625
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: Two suggestions for windows.html
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec  7 10:47:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 07 Dec 2016 15:47:41 +0000
Subject: [docs] [issue28895] Two suggestions for windows.html
In-Reply-To: <1481122153.16.0.608374359054.issue28895@psf.upfronthosting.co.za>
Message-ID: <1481125661.56.0.595094687551.issue28895@psf.upfronthosting.co.za>


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


----------
nosy: +steve.dower

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

From report at bugs.python.org  Wed Dec  7 11:57:00 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 07 Dec 2016 16:57:00 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1481129820.88.0.300959030192.issue28810@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  7 13:48:42 2016
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 07 Dec 2016 18:48:42 +0000
Subject: [docs] [issue28863] Doc/includes/*.py files and doctests
In-Reply-To: <1480801685.13.0.102040139052.issue28863@psf.upfronthosting.co.za>
Message-ID: <1481136522.44.0.617947468427.issue28863@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I attached a patch in issue 27200 that makes all doctests pass, so I close here.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 13:49:47 2016
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 07 Dec 2016 18:49:47 +0000
Subject: [docs] [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1481136587.38.0.431395384676.issue28860@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I attached a patch in issue 27200 that makes all doctests pass, so I close here.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 15:48:43 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 07 Dec 2016 20:48:43 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481143723.44.0.692604852833.issue26483@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


Added file: http://bugs.python.org/file45793/issue26483.diff

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

From report at bugs.python.org  Wed Dec  7 16:02:54 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 07 Dec 2016 21:02:54 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1481144574.93.0.619654463796.issue28755@psf.upfronthosting.co.za>


Julien Palard added the comment:

Just rebasing my patch on tip as it does no longer cleanly apply.

----------
Added file: http://bugs.python.org/file45795/issue28755-3.diff

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

From report at bugs.python.org  Wed Dec  7 19:20:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 00:20:17 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161208002014.117305.39468.FF6AD448@psf.io>


Roundup Robot added the comment:

New changeset d12bc674b74e by Yury Selivanov in branch '3.6':
Issue #28635: Drop the note that whatsnew is incomplete
https://hg.python.org/cpython/rev/d12bc674b74e

New changeset 1883072efc5f by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/1883072efc5f

----------

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

From report at bugs.python.org  Wed Dec  7 22:28:03 2016
From: report at bugs.python.org (Matthias v/d Meent)
Date: Thu, 08 Dec 2016 03:28:03 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
Message-ID: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>


New submission from Matthias v/d Meent:

The 'docs for other versions' links in the sidebar of docs.python.org do not link to 3.5 in both the 3.6 and 3.7 docs. As I didn't find any docs guidelines, I presume this is an error and should be fixed.

A link to the Python 3.6 docs should get added under all active documentations before or the moment python 3.6 is released (though I suspect this is automated).

----------
assignee: docs at python
components: Documentation
messages: 282684
nosy: Matthias v/d Meent, docs at python
priority: normal
severity: normal
status: open
title: update 'docs for other versions'
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec  7 22:31:00 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:31:00 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481167860.56.0.961881664872.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

Links to 3.5, 3.6, and dev (future 2.7) docs are available in the pulldown menu above the Download sidebar.  Does that work for you?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Dec  7 22:34:22 2016
From: report at bugs.python.org (Matthias v/d Meent)
Date: Thu, 08 Dec 2016 03:34:22 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168062.62.0.213098923215.issue28900@psf.upfronthosting.co.za>


Matthias v/d Meent added the comment:

Yes, they do work. It's just that the links to 3.5 are missing in the sidebar of 3.6 and 3.7. The docs are still reachable though.

----------

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

From report at bugs.python.org  Wed Dec  7 22:40:02 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:40:02 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168402.43.0.31793095516.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

OK, I see what needs to be changed.  Thanks for the reminder!

----------
assignee: docs at python -> ned.deily
priority: normal -> release blocker
stage:  -> needs patch

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

From report at bugs.python.org  Wed Dec  7 22:48:02 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 08 Dec 2016 03:48:02 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168882.29.0.620648761632.issue28900@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

If it's ok, I'd like to work on a patch for this :)

----------
nosy: +Mariatta

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

From report at bugs.python.org  Wed Dec  7 22:49:49 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:49:49 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168989.63.0.358128333305.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks but I'm almost done, Mariatta. The most important part is ensuring PEP 101 is correct.

----------

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

From report at bugs.python.org  Wed Dec  7 22:51:10 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 08 Dec 2016 03:51:10 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481169070.75.0.216869496225.issue28900@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

No prob. Thanks, Ned.

----------

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

From report at bugs.python.org  Wed Dec  7 23:38:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 04:38:59 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <20161208043856.117097.92370.FFA03462@psf.io>


Roundup Robot added the comment:

New changeset e414fb1640e0 by Ned Deily in branch '2.7':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/e414fb1640e0

New changeset d350fc4d78ff by Ned Deily in branch '3.5':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/d350fc4d78ff

New changeset 148c46d180b2 by Ned Deily in branch '3.6':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/148c46d180b2

New changeset f200ff0a0057 by Ned Deily in branch 'default':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/f200ff0a0057

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

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

From report at bugs.python.org  Wed Dec  7 23:43:48 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 04:43:48 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481172228.34.0.327065856037.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

With the above changes, the sidebar should get updated for the current 2.7, 3.5, 3.6, and 3.7 front pages within the next 24 hours.  I'm leaving this open as a "release blocker" as a reminder to go back and update them all again once 3.6.0 final happens.  I've also added a reminder to PEP 101 to do this.

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

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

From report at bugs.python.org  Thu Dec  8 00:36:04 2016
From: report at bugs.python.org (Matthias v/d Meent)
Date: Thu, 08 Dec 2016 05:36:04 +0000
Subject: [docs] [issue28901] Embedded Release interactive mode documentation
Message-ID: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>


New submission from Matthias v/d Meent:

The Windows Embedded release (at least the x86_64 version) does not include the usual helper functions (exit, help, ...) when run interactively (~ python.exe). This is not documented at the docs of Windows Embedded release, which might mean that this is a bug.

Documentation on Embedded release here (https://docs.python.org/3/using/windows.html#embedded-distribution)

missing in interactive mode of embedded release: (output of diff):
['copyright', 'credits', 'exit', 'help', 'license', 'quit']

Notice that 'help', a builtin function according to the docs [0], is missing in the Embedded release. Even when embedded, a builtin should be available IMO.


[0] https://docs.python.org/3.6/library/functions.html

This comparison was only between running the python executable in the [zip] and python installed from this [installer]. It is very well possible this is a long-standing issue since 3.5 (the first Embedded release), and this may occur on other architectures as well.

[zip] https://www.python.org/ftp/python/3.6.0/python-3.6.0rc1-embed-amd64.zip 
[installer] https://www.python.org/ftp/python/3.6.0/python-3.6.0rc1-amd64.exe

----------
assignee: docs at python
components: Documentation, Windows
messages: 282693
nosy: Matthias v/d Meent, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embedded Release interactive mode documentation
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec  8 05:45:30 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 10:45:30 +0000
Subject: [docs] [issue28331] "CPython implementation detail:" removed when
 content translated
In-Reply-To: <1475328552.4.0.631332821236.issue28331@psf.upfronthosting.co.za>
Message-ID: <1481193930.45.0.926973941313.issue28331@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +Julien.Palard, JulienPalard

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

From report at bugs.python.org  Thu Dec  8 10:29:20 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Dec 2016 15:29:20 +0000
Subject: [docs] [issue28901] Windows: document that site is not imported by
 default by embeddable distribution
In-Reply-To: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>
Message-ID: <1481210960.75.0.578161065158.issue28901@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Each of those items is added to builtins by site.py, which I believe is not imported by default by the embeddable distribution.  I didn't immediately find that fact mentioned in the docs, though.

Also note that the embeddable distribution isn't really meant for regular usage, it's meant for embedding :).  While this is definitely worth some clarification in the docs, it's not a high-priority issue.

+Ethan Smith from #28903.

----------
nosy: +Ethan Smith
stage:  -> needs patch
title: Embedded Release interactive mode documentation -> Windows: document that site is not imported by default by embeddable distribution

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

From report at bugs.python.org  Thu Dec  8 11:32:23 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Dec 2016 16:32:23 +0000
Subject: [docs] [issue28901] Windows: document that site is not imported by
 default by embeddable distribution
In-Reply-To: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>
Message-ID: <1481214743.45.0.629459348914.issue28901@psf.upfronthosting.co.za>


Steve Dower added the comment:

If you go to the 3.6 version of that doc page and also read the section on finding modules, you'll see that the presence of a "python._pth" file causes -S (skip importing site) to be implied unless the ._pth file includes "import site":

https://docs.python.org/3.6/using/windows.html#finding-modules

You'll then notice that the embeddable distro includes a ._pth file by default (though you don't have to distribute that with your app, just as you may want to omit the exe files). That could certainly be called out more clearly in the section on the embeddable distro, though so far it hasn't come up with anyone who's using it for its proper purpose (that I'm aware of).

----------

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

From report at bugs.python.org  Thu Dec  8 16:48:20 2016
From: report at bugs.python.org (Arne de Laat)
Date: Thu, 08 Dec 2016 21:48:20 +0000
Subject: [docs] [issue28911] Clarify the behaviour of assert_called_once_with
Message-ID: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>


New submission from Arne de Laat:

The name assert_called_once_with and the current method documentation can be interpreted to mean that it asserts that there is precisely one call matching the given signature, regardless of the total number of calls. However, the method first checks that there is precisely one call, and then checks if that call has a signature matching the provided signature.

Additionally, the assert_any_call method documentation references assert_called_once_with in a way that enforces the possible misinterpretation: "? assert_called_with and assert_called_once_with that only pass if the call is the most recent one". This may lead to the interpretation that there must be only one call with the given signature and  that it must be the most recent one, it must in fact be the only one.

In the mock examples documentation there is an important sentence that clarifies the actual functionality: "you can use the assert_called_once_with method that also asserts that the call_count is one".

The example provided in the method documentation also does not satisfactorily address the ambiguity, because it only calls the mock with one call signature. By changing the call signature of the second call (and in the assert) in the example the purpose of the method becomes clearer.

----------
assignee: docs at python
components: Documentation, Tests
files: assert_once_with_doc.patch
keywords: patch
messages: 282740
nosy: 153957, docs at python
priority: normal
severity: normal
status: open
title: Clarify the behaviour of assert_called_once_with
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45803/assert_once_with_doc.patch

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

From report at bugs.python.org  Thu Dec  8 19:44:23 2016
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 09 Dec 2016 00:44:23 +0000
Subject: [docs] [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1481244263.71.0.218536111482.issue26267@psf.upfronthosting.co.za>


Ammar Askar added the comment:

I've updated the patch to document the comparison operators in prose instead of with markup as requested.

----------
Added file: http://bugs.python.org/file45807/uuiddocs.diff5

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

From ammar at ammaraskar.com  Thu Dec  8 19:52:02 2016
From: ammar at ammaraskar.com (ammar at ammaraskar.com)
Date: Fri, 09 Dec 2016 00:52:02 -0000
Subject: [docs] UUID docs should say how to get "standard form" (issue
 26267)
Message-ID: <20161209005202.28350.87057@psf.upfronthosting.co.za>

On 2016/09/11 09:12:18, berkerpeksag wrote:
> https://bugs.python.org/review/26267/diff/18046/Doc/library/uuid.rst
> File Doc/library/uuid.rst (right):
> 
>
https://bugs.python.org/review/26267/diff/18046/Doc/library/uuid.rst#newcode56
> Doc/library/uuid.rst:56: .. describe:: uuid1 == uuid2
> On 2016/08/06 05:20:17, ammar2 wrote:
> > On 2016/08/03 10:09:25, berkerpeksag wrote:
> > > Same as above. See datetime or decimal documentations for an
example of how
> to
> > > document comparison operations.
> > 
> > So datetime takes the approach of documenting operators in a table
(presumably
> > because it has a lot of ops)
> > https://docs.python.org/3/library/datetime.html#datetime.date.day
> > 
> > decimal seems to do it in  this way
> >
https://docs.python.org/3/library/decimal.html#decimal.Decimal.compare
> > 
> > The style I used here is from
> > https://docs.python.org/3/library/stdtypes.html#set but now that I
look at it,
> > within the stdtypes there's also the datetime style operator
documentation for
> > numbers.
> >
>
https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex
> > 
> > Is there a preferred style for documenting operators? Which one
should I use
> > here?
> > 
> > (apparently I forgot to click the publish button on Rietveld, I
wrote this day
> > before yesterday)
> 
> Sorry, I wasn't very clear in my earlier message. I was referring to
the
> following paragraph in datetime documentation:
> 
>     Comparisons of timedelta objects are supported with the timedelta
object
> representing the smaller duration considered to be the smaller
timedelta. In
> order to stop mixed-type comparisons from falling back to the default
comparison
> by object address, when a timedelta object is compared to an object of
a
> different type, TypeError is raised unless the comparison is == or !=.
The
> latter cases return False or True, respectively.
> 
> https://docs.python.org/3/library/datetime.html#timedelta-objects
> 
> In other words, instead of using too much markup, it would be nice to
document
> that it supports comparison operators in prose.

I've updated it so the comparison operators are explain in prose but
there's still markup for the str() operator.

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

From report at bugs.python.org  Fri Dec  9 00:20:41 2016
From: report at bugs.python.org (woo yoo)
Date: Fri, 09 Dec 2016 05:20:41 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
Message-ID: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>


New submission from woo yoo:

Mismatch occurs within the "Notes" section,row 1.Here is the link:https://docs.python.org/3/library/stdtypes.html#old-string-formatting

The course of coding shows below:
>>>'%#07o' % 1223
Result value is '0o02307',which is not in line with the description.

Description is "The alternate form causes a leading zero ('0') to be inserted between left-hand padding and the formatting of the number if the leading character of the result is not already a zero."

----------
assignee: docs at python
components: Documentation
messages: 282762
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Not matched behavior of modulo operator % with the description of the documentation
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec  9 00:35:00 2016
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Fri, 09 Dec 2016 05:35:00 +0000
Subject: [docs] [issue28917] Docs: Add missing protocol to pickle
Message-ID: <1481261699.94.0.5034553243.issue28917@psf.upfronthosting.co.za>


New submission from Anand Reddy Pandikunta:

In Python 2.7, it is documented. It is missing in Python 3 documentation.

----------
assignee: docs at python
components: Documentation
files: docs_pickle_add_missing_protocol.patch
keywords: patch
messages: 282764
nosy: ChillarAnand, abz64, docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: Docs: Add missing protocol to pickle
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45810/docs_pickle_add_missing_protocol.patch

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

From report at bugs.python.org  Fri Dec  9 01:20:47 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 09 Dec 2016 06:20:47 +0000
Subject: [docs] [issue28917] Docs: Add missing protocol to pickle
In-Reply-To: <1481261699.94.0.5034553243.issue28917@psf.upfronthosting.co.za>
Message-ID: <1481264447.16.0.335069741086.issue28917@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi, isn't it documented here? 
https://docs.python.org/3.7/library/pickle.html#pickle.Pickler

"If a negative number is specified, HIGHEST_PROTOCOL is selected."

----------
nosy: +Mariatta

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

From report at bugs.python.org  Fri Dec  9 02:31:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Dec 2016 07:31:26 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481268686.11.0.227733454597.issue28916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like a leftover relic from Python 2. In Python 3, the prefix is ?0o?, not just ?0?. This matches to change in Python 2 to 3 octal literal syntax. And there is no special handling of zero in 3:

>>> "%#o" % 0
'0o0'

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Dec  9 03:08:21 2016
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Fri, 09 Dec 2016 08:08:21 +0000
Subject: [docs] [issue28917] Docs: Add missing protocol to pickle
In-Reply-To: <1481261699.94.0.5034553243.issue28917@psf.upfronthosting.co.za>
Message-ID: <1481270901.77.0.63179547424.issue28917@psf.upfronthosting.co.za>


Anand Reddy Pandikunta added the comment:

Yes, Thanks.

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

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

From report at bugs.python.org  Fri Dec  9 15:02:31 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Dec 2016 20:02:31 +0000
Subject: [docs] [issue28882] Slice confusing with negative stop and strides
 and the 0th element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481313751.87.0.375079393085.issue28882@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Steven, your initial 'sentence' is missing something needed to make it a proper English sentence, and I cannot exactly guess what you meant.  But your later confusion is clear enough.

This tracker is for patching the Python docs and CPython code.  I believe the entry for the slice function/class, https://docs.python.org/3/library/functions.html#slice, could be improved.

First the word 'slice' is linked to the Glossary entry for 'slice'.  However, the latter is about subsequences, not about slice objects. It should instead link to the entry that contains the method description as https://docs.python.org/3/reference/datamodel.html#slice.indices.  (This is the target for the Index entry 'indices (slice method)'.  The 'slick objects' label needs to be made a target.

Second, the description "representing the set of indices specified by range(start, stop, step)" is only true when start and stop are valid non-negative indexes when applied to a particular sequence.  It is never true for negative values and not true when greater to or equal to the length of a particular sequence.  As the slice.indices entry says, 'Missing or out-of-bounds indices are handled in a manner consistent with regular slices."

In the example above, the issue is the negative stop, not the negative step.  Steven's problem was expecting the description to be true (whether or not he read it.)  It is worth noting, nowever, that reversed() was added because people had trouble using negative steps.  The following is much clearer than the corrected code above that the object is to separately reverse two haves of a list.

>>> n = 8
>>> a = range(8)
>>> [list(reversed(a[:n//2])), list(reversed(a[n//2:]))]
[[3, 2, 1, 0], [7, 6, 5, 4]]

As the Library Function entry hints, slice() is mainly intended for use internally and by 3rd-party extensions.

The description is even more wrong because the three arguments/attributes 'can have any type' (from the Data model slice object entry) whereas range arguments must be int-like.  (Allowing non-int-like arguments is for external extension use.)  In particular, slice(None) == slice(None, None) == slice(None, None, None) 'represents' all the indices of a particular sequence, in normal order, whereas None is not a valid argument for range().

I am not sure what replacement to propose.  I'd like to see if there is any previous discussion on the tracker.

A third and minor issue is that 'Numerical Python' should? be updated to "Numpy'.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
stage:  -> needs patch
title: RFC: Slice confusing with negative strides and the 0th element. -> Slice confusing with negative stop and strides and the 0th element.
type: behavior -> 
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Dec  9 18:42:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Dec 2016 23:42:07 +0000
Subject: [docs] [issue28882] Slice confusing with negative stop and strides
 and the 0th element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481326927.1.0.72607031604.issue28882@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Steven?s main complaint is that it is hard to make a reversed slice extend to the start of the original sequence, unless you omit (or use None as) the endpoint:

>>> "01234567"[4:0:-1]  # Includes index [4], stops before reaching index [0]
'4321'
>>> "01234567"[3::-1]  # Includes index [3], stop omitted for start of string
'3210'
>>> "01234567"[3:None:-1]  # None means the same
'3210'
>>> "01234567"[3:-1:-1]  # Negative means len(...) - 1, i.e. index [7]
''

This is a consequence of (a) the stop parameter meaning ?stop _before_ reaching this index?, and (b) negative indexes are interpreted specially as being relative to the end.

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

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

From report at bugs.python.org  Fri Dec  9 19:22:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 00:22:00 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1481329320.13.0.883626118951.issue1446619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Fumihiro?s suggestion seems reasonable to me (assuming it still applies to the current text)

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

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

From report at bugs.python.org  Fri Dec  9 19:28:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 00:28:35 +0000
Subject: [docs] [issue28882] Slice confusing with negative stop and strides
 and the 0th element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481329715.19.0.574356793265.issue28882@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 11842 about the behaviour of slice.indices() in this situation, and Issue 1446619 about fixing the documentation for reverse slices regarding positive out-of-range indexes.

----------

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

From report at bugs.python.org  Fri Dec  9 19:58:56 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 00:58:56 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
Message-ID: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It would be great if we provided a link from a documentation page back to the source file that the page is produced from, e.g. have https://docs.python.org/3.6/library/abc.html provide a link to https://github.com/python/cpython/blob/3.6/Doc/library/abc.rst.

----------
assignee: docs at python
components: Documentation
messages: 282818
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide a link from documentation back to its source file
type: enhancement

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

From report at bugs.python.org  Fri Dec  9 20:39:30 2016
From: report at bugs.python.org (Douglas Greiman)
Date: Sat, 10 Dec 2016 01:39:30 +0000
Subject: [docs] [issue28424] pkgutil.get_data() doesn't work with namespace
 packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481333970.46.0.168848732271.issue28424@psf.upfronthosting.co.za>


Douglas Greiman added the comment:

Patch attached.  Feel free to wordsmith.

----------
keywords: +patch
Added file: http://bugs.python.org/file45825/issue28424.patch

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

From report at bugs.python.org  Fri Dec  9 22:12:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 03:12:34 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481339554.61.0.276115754648.issue28916@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation for %x etc also had the same problem, and it applies to Python 2 for %x. Here is a patch for Python 3. The behaviour is already tested, but there were some quirks due to porting from Py 2 tests, and duplicate tests which I removed.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file45826/py3-octal.patch

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

From report at bugs.python.org  Fri Dec  9 23:23:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 04:23:13 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <20161210042310.117653.35258.B9A73E66@psf.io>


Roundup Robot added the comment:

New changeset 7a93d1a0a1cf by Martin Panter in branch '3.5':
Issue 28753: Argument Clinic howto docfix, courtesy Julien Palard.
https://hg.python.org/cpython/rev/7a93d1a0a1cf

New changeset d0859a11322c by Martin Panter in branch '3.6':
Issues #28755, #28753: Merge Arg Clinic howto from 3.5
https://hg.python.org/cpython/rev/d0859a11322c

----------

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

From report at bugs.python.org  Fri Dec  9 23:23:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 04:23:13 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <20161210042310.117653.40345.720B0D17@psf.io>


Roundup Robot added the comment:

New changeset 3795ba7490b1 by Martin Panter in branch '3.5':
Issue #28755: Improve syntax highlighting in Arg Clinic howto
https://hg.python.org/cpython/rev/3795ba7490b1

New changeset d0859a11322c by Martin Panter in branch '3.6':
Issues #28755, #28753: Merge Arg Clinic howto from 3.5
https://hg.python.org/cpython/rev/d0859a11322c

New changeset 889cb7ebc38d by Martin Panter in branch 'default':
Issue #28755: Merge Arg Clinic howto from 3.6
https://hg.python.org/cpython/rev/889cb7ebc38d

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

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

From report at bugs.python.org  Fri Dec  9 23:45:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 04:45:55 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1481345155.01.0.0335279257985.issue1446619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch ruling out the len(s) corner case. I use a modified version of Fumihiro?s suggestion.

----------
versions: +Python 3.6, Python 3.7 -Python 3.4
Added file: http://bugs.python.org/file45827/extended_slicing_docs.v2.diff

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

From report at bugs.python.org  Sat Dec 10 00:04:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 05:04:48 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481346288.13.0.0999853922118.issue26483@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m okay with this version unless anyone has any more improvements.

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

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

From report at bugs.python.org  Sat Dec 10 00:10:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 05:10:53 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1481346653.94.0.549213118549.issue28755@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 10 00:40:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 05:40:05 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <20161210054002.125268.32914.7D1C0C9E@psf.io>


Roundup Robot added the comment:

New changeset 8e36c04d0e3e by Martin Panter in branch '3.5':
Issue #28820: Fix spelling of ?practice? as a noun
https://hg.python.org/cpython/rev/8e36c04d0e3e

New changeset e9b78a42e6c0 by Martin Panter in branch '3.6':
Issue #28820: Merge spelling fixes from 3.5
https://hg.python.org/cpython/rev/e9b78a42e6c0

New changeset d786c620838c by Martin Panter in branch 'default':
Issue #28820: Merge typo fixes from 3.6
https://hg.python.org/cpython/rev/d786c620838c

----------

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

From report at bugs.python.org  Sat Dec 10 01:02:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 06:02:49 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481349769.35.0.904405348905.issue28916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch for %x in Py 2.

----------
Added file: http://bugs.python.org/file45828/alt-zero.py2.patch

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

From report at bugs.python.org  Sat Dec 10 01:10:52 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 10 Dec 2016 06:10:52 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481350252.13.0.584482448009.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

On the left menu, there's already a Show Source link. 
Is the idea to replace that link to github.com/python/cpython/blob/.... ?

Or, are you thinking about adding a new link under the main heading, similar to 
**Source code:** :source:`Lib/abc.py` 
but for the docs, so maybe by creating a new role like:
**Docs Source code:** :docs_source:`Doc/library/abc.rst`

----------
nosy: +Mariatta

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

From report at bugs.python.org  Sat Dec 10 01:11:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 06:11:14 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <20161210061111.14329.10655.C831A32F@psf.io>


Roundup Robot added the comment:

New changeset 5d51ac0be72a by Martin Panter in branch '3.5':
Issue #28771: Update tp_get/setattr signature documentation
https://hg.python.org/cpython/rev/5d51ac0be72a

New changeset ee8c8b79d1d5 by Martin Panter in branch '3.6':
Issue #28771: Merge C API doc fix from 3.5
https://hg.python.org/cpython/rev/ee8c8b79d1d5

New changeset c4865975b804 by Martin Panter in branch 'default':
Issue #28771: Merge C API doc fix from 3.6
https://hg.python.org/cpython/rev/c4865975b804

----------

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

From report at bugs.python.org  Sat Dec 10 01:55:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 06:55:35 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <1481352935.02.0.743723943247.issue28771@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 10 01:55:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 06:55:54 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1481352954.65.0.393420808806.issue28820@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 10 02:33:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 07:33:35 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481355215.45.0.64184472084.issue28916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Both patches LGTM.

----------
assignee: docs at python -> martin.panter
nosy: +serhiy.storchaka
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Dec 10 02:50:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 07:50:11 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481356211.2.0.811733460366.issue26483@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> martin.panter

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

From report at bugs.python.org  Sat Dec 10 14:45:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:45:37 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481399137.45.0.293716630595.issue28929@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Either idea works, but I want a link that someone who finds a spelling mistake can easily follow and submit a PR to fix the issue.

----------

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

From report at bugs.python.org  Sat Dec 10 14:50:12 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 10 Dec 2016 19:50:12 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481399412.57.0.473489010591.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Brett :) I think it's easier to update the existing Source Link to github. I'll work on a patch for this.

----------

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

From report at bugs.python.org  Sat Dec 10 14:55:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:55:07 +0000
Subject: [docs] [issue28424] pkgutil.get_data() doesn't work with namespace
 packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481399707.61.0.0341207070514.issue28424@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch LGTM.

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

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

From report at bugs.python.org  Sat Dec 10 14:55:40 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:55:40 +0000
Subject: [docs] [issue28424] pkgutil.get_data() doesn't work with namespace
 packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481399740.44.0.676059845525.issue28424@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 10 17:15:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 22:15:31 +0000
Subject: [docs] [issue28424] pkgutil.get_data() doesn't work with namespace
 packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <20161210221528.12844.62614.5739412F@psf.io>


Roundup Robot added the comment:

New changeset 3484933ba904 by Brett Cannon in branch '3.5':
Issue #28424: Document pkgutil.get_data() doesn't work with namespace packages.
https://hg.python.org/cpython/rev/3484933ba904

New changeset c17d2a37d610 by Brett Cannon in branch '3.6':
Merge for issue #28424
https://hg.python.org/cpython/rev/c17d2a37d610

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

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

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

From report at bugs.python.org  Sat Dec 10 17:15:53 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 22:15:53 +0000
Subject: [docs] [issue28424] pkgutil.get_data() doesn't work with namespace
 packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481408153.3.0.796888885843.issue28424@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Douglas!

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

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

From report at bugs.python.org  Sat Dec 10 19:18:58 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 11 Dec 2016 00:18:58 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1481415538.63.0.359584336024.issue1446619@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Sat Dec 10 23:10:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 04:10:48 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <20161211041044.22840.3417.6FA473D7@psf.io>


Roundup Robot added the comment:

New changeset 35e66eb101da by Martin Panter in branch '3.5':
Issue #28916: Correct description of %o and %x alternative forms
https://hg.python.org/cpython/rev/35e66eb101da

New changeset bc7fc85beed1 by Martin Panter in branch '3.6':
Issues #28916, #26483: Merge stdtypes.rst from 3.5
https://hg.python.org/cpython/rev/bc7fc85beed1

New changeset b11850871300 by Martin Panter in branch 'default':
Issues #28916, #26483: Merge stdtypes.rst from 3.6
https://hg.python.org/cpython/rev/b11850871300

New changeset 8359ee62dde3 by Martin Panter in branch '2.7':
Issue #28916: No special case for leading zeros with %x alternative form
https://hg.python.org/cpython/rev/8359ee62dde3

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

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

From report at bugs.python.org  Sat Dec 10 23:10:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 04:10:48 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <20161211041044.22840.41666.35665839@psf.io>


Roundup Robot added the comment:

New changeset c15f122617d5 by Martin Panter in branch '3.5':
Issue #26483: Clarify str.isdecimal() and isdigit()
https://hg.python.org/cpython/rev/c15f122617d5

New changeset bc7fc85beed1 by Martin Panter in branch '3.6':
Issues #28916, #26483: Merge stdtypes.rst from 3.5
https://hg.python.org/cpython/rev/bc7fc85beed1

New changeset b11850871300 by Martin Panter in branch 'default':
Issues #28916, #26483: Merge stdtypes.rst from 3.6
https://hg.python.org/cpython/rev/b11850871300

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

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

From report at bugs.python.org  Sat Dec 10 23:44:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 04:44:35 +0000
Subject: [docs] [issue28916] Not matched behavior of modulo operator % with
 the description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481431475.69.0.725475490423.issue28916@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 10 23:45:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 04:45:00 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481431500.89.0.743077601537.issue26483@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 10 23:47:04 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 11 Dec 2016 04:47:04 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481431624.6.0.0135003496738.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi,
This patch updates the Show Source link on the left of Docs menu and point it to github.
I tested it locally, and works for versions >= 3.5 
Please let me know if you have any feedback about this.
Thanks :)

Not sure if the older docs versions should be updated too? In that case, I'll need to prepare different patches for 3.4, 3.3 and 2.7

----------
keywords: +patch
Added file: http://bugs.python.org/file45846/issue28929dev.patch

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

From report at bugs.python.org  Sun Dec 11 12:41:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 17:41:59 +0000
Subject: [docs] [issue28739] PEP 498: docstrings as f-strings
In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za>
Message-ID: <1481478119.41.0.0203773792844.issue28739@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
keywords:  -patch
nosy: +docs at python
stage: patch review -> needs patch

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

From report at bugs.python.org  Sun Dec 11 14:01:25 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Dec 2016 19:01:25 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481482885.09.0.710575093877.issue28929@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Mariatta! Once we have migrated to GitHub we can apply the patch (don't let me forget :) ).

Any version still under active maintenance should probably be updated, so that would probably mean 2.7 but not the other versions.

----------

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

From report at bugs.python.org  Sun Dec 11 14:26:14 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 19:26:14 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1481484374.63.0.764203610409.issue28753@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


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

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

From report at bugs.python.org  Sun Dec 11 15:16:23 2016
From: report at bugs.python.org (Greg Solomon)
Date: Sun, 11 Dec 2016 20:16:23 +0000
Subject: [docs] [issue28939] Groupby Is Roughly Equivalent To ...
Message-ID: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>


New submission from Greg Solomon:

https://docs.python.org/3/library/itertools.html#itertools.groupby

I found the "equivalent" code a bit hard to read. Is there any merit in changing it to something a bit like the following ?

Kind Rgds, Greg

class groupby:
    def __init__( self , iterable , key_function = ( lambda x: x ) ):
        self.iterable = iter( iterable )
        self.key_function = key_function
        self.FINISHED = object()
        try:
            self.next_value = next( self.iterable )
        except StopIteration: 
            self.next_value = self.FINISHED
    def __iter__( self ):
        return self
    def __next__( self ):
        if self.next_value == self.FINISHED:
            raise StopIteration
        self.group_key_value = self.key_function( self.next_value )
        return ( self.group_key_value , self._group() )
    def _group( self ):
        while self.next_value != self.FINISHED \
          and self.group_key_value == self.key_function( self.next_value ):
            yield self.next_value
            try:
                self.next_value = next( self.iterable )
            except StopIteration:
                self.next_value = self.FINISHED 
        return

----------
assignee: docs at python
components: Documentation
messages: 282943
nosy: docs at python, greg.solomon
priority: normal
severity: normal
status: open
title: Groupby Is Roughly Equivalent To ...
versions: Python 3.7

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

From report at bugs.python.org  Sun Dec 11 15:54:02 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 20:54:02 +0000
Subject: [docs] [issue28939] Groupby Is Roughly Equivalent To ...
In-Reply-To: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>
Message-ID: <1481489642.34.0.864343374701.issue28939@psf.upfronthosting.co.za>


Julien Palard added the comment:

I renamed your function groupby2 to compare it with itertools.groupby and tested but:

>>> print(list(groupby2(['A', 'B'])))

does not returns, looks like your implementation have a bug, so I tried:

>>> for k in groupby2(['A', 'B']):
...     print(k)

and I'm getting loads of:

('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)

You may also want to test your implementation against https://github.com/python/cpython/blob/master/Lib/test/test_itertools.py#L699

----------
nosy: +mdk

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

From report at bugs.python.org  Sun Dec 11 21:58:11 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 02:58:11 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481511491.57.0.385093873644.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Brett.

Here's the patch that will work for the 2.7 branch.

----------
Added file: http://bugs.python.org/file45854/issue28929-v27.patch

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

From report at bugs.python.org  Sun Dec 11 22:03:28 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 12 Dec 2016 03:03:28 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1481511808.88.0.11772307665.issue26546@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
dependencies: +"CPython implementation detail:" removed when content translated

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

From report at bugs.python.org  Sun Dec 11 22:36:59 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 03:36:59 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
Message-ID: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>


New submission from Mariatta Wijaya:

Some Python docs include a link to the Source Code, for example: https://docs.python.org/3.6/library/abc.html

Once the repo is moved to github, the link should probably be updated to point to github:
https://github.com/python/cpython/blob/master/Lib/abc.py

----------
assignee: docs at python
components: Documentation
messages: 282960
nosy: Mariatta, docs at python
priority: normal
severity: normal
status: open
title: Update the link to Source Code in Python Docs from hg to github
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Dec 11 22:39:08 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 03:39:08 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481513948.64.0.24384612469.issue28941@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

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

From report at bugs.python.org  Mon Dec 12 01:02:41 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2016 06:02:41 +0000
Subject: [docs] [issue28939] Groupby Is Roughly Equivalent To ...
In-Reply-To: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>
Message-ID: <1481522561.67.0.100636228346.issue28939@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Mon Dec 12 01:06:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2016 06:06:04 +0000
Subject: [docs] [issue25035] Getter/setter for argparse keys
In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za>
Message-ID: <1481522764.86.0.686483770629.issue25035@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +bethard, docs at python
versions: +Python 3.7 -Python 3.4

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

From report at bugs.python.org  Mon Dec 12 02:52:05 2016
From: report at bugs.python.org (Greg Solomon)
Date: Mon, 12 Dec 2016 07:52:05 +0000
Subject: [docs] [issue28939] Groupby Is Roughly Equivalent To ...
In-Reply-To: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>
Message-ID: <1481529125.54.0.68804116851.issue28939@psf.upfronthosting.co.za>


Greg Solomon added the comment:

Oh, I get it. There needs to be a next(self.it) loop in __next__ as well as in _grouper in case the user doesn't call _grouper.

My test was 
for ( k , g ) in groupby( L ):
    print ( k , len( list( g ) ) )
so I was executing _grouper on every row.

Thanks !!!

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

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

From report at bugs.python.org  Mon Dec 12 06:12:02 2016
From: report at bugs.python.org (Adam Gregory)
Date: Mon, 12 Dec 2016 11:12:02 +0000
Subject: [docs] [issue28942] await expressions in f-strings
Message-ID: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>


New submission from Adam Gregory:

Hi,

I've been playing with f-strings, which seem like a great addition to the language. I noticed in the definition of f_expression that it can include any or_expr. As far as I understand, this includes "await" expressions, so I tried using await inside an f-string in a coroutine with CPython 3.6.0b4. This produces a SyntaxError.

Should await be allowed in f-strings? I don't know if this is a bug or a documentation issue. Personally, I think it would be an occasionally useful feature - more so than yield, at least, which does work.

Ref: https://docs.python.org/3.6/reference/lexical_analysis.html#formatted-string-literals

----------
assignee: docs at python
components: Documentation, asyncio
messages: 282980
nosy: Adam Gregory, docs at python, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: await expressions in f-strings
versions: Python 3.6

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

From report at bugs.python.org  Mon Dec 12 06:20:30 2016
From: report at bugs.python.org (Adam Gregory)
Date: Mon, 12 Dec 2016 11:20:30 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1481541629.98.0.490829707912.issue28942@psf.upfronthosting.co.za>


Adam Gregory added the comment:

Replicated in CPython 3.6.0rc1

----------

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

From report at bugs.python.org  Mon Dec 12 06:42:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 11:42:04 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1481542924.02.0.218814637413.issue28942@psf.upfronthosting.co.za>


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


----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon Dec 12 07:10:28 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 12 Dec 2016 12:10:28 +0000
Subject: [docs] [issue28944] A lack of comma within EBNF rule of
 keywords_arguments
Message-ID: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>


New submission from woo yoo:

This is the documented rule, which lacks a comma within the last line.
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item | "**" expression)*
The correct form should be:
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item |",""**" expression)*

The original documentation is https://docs.python.org/3/reference/expressions.html#calls

----------
assignee: docs at python
components: Documentation
messages: 282987
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: A lack of comma within EBNF rule of keywords_arguments
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec 12 07:13:05 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 12 Dec 2016 12:13:05 +0000
Subject: [docs] [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481544785.86.0.252284253208.issue28944@psf.upfronthosting.co.za>


woo yoo added the comment:

There is no line 6 between line 7 and line 5.
Here is the original documentationhttps://docs.python.org/3/library/stdtypes.html#old-string-formatting

----------
title: A lack of comma within EBNF rule of keywords_arguments -> A lack of line 6

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

From report at bugs.python.org  Mon Dec 12 07:13:40 2016
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 12 Dec 2016 12:13:40 +0000
Subject: [docs] [issue26683] Questionable terminology for describing what
 locals() does
In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>
Message-ID: <1481544820.9.0.447638033341.issue26683@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Another point in the doc, where the meaning of "free variable" is inconsistent with the ``locals()`` and ``code.co_freevars`` meaning:

https://docs.python.org/3/reference/executionmodel.html#interaction-with-dynamic-features

----------

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

From report at bugs.python.org  Mon Dec 12 10:19:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 12 Dec 2016 15:19:54 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481542924.02.0.218814637413.issue28942@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLmeG_X18hyz=PH6iRXLy_JWZRA15MRNtEvDwpE1Gjbkg@mail.gmail.com>


Guido van Rossum added the comment:

I was going to say "no", but given that "yield" works, I think it is
reasonable to allow "await" as well. (And what about "yield from"?)

----------

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

From report at bugs.python.org  Mon Dec 12 10:51:56 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Dec 2016 15:51:56 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1481557916.39.0.499284976156.issue28942@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I was going to say "no", but given that "yield" works, I think it is
reasonable to allow "await" as well. (And what about "yield from"?)

Agree.

I suspect the reason is that async/await aren't proper keywords in 3.5/3.6, and the hacks we have in tokenizer to recognize them aren't working in f-strings.

I'll assign this issue to myself to make sure it's resolved in 3.7 once we make async/await keywords.

----------
assignee: docs at python -> yselivanov

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

From report at bugs.python.org  Mon Dec 12 13:57:28 2016
From: report at bugs.python.org (kevin)
Date: Mon, 12 Dec 2016 18:57:28 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
Message-ID: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>


New submission from kevin:

In the online documentation of module re 
  (https://docs.python.org/3.5/library/re.html) 
under 
  6.2.1. Regular Expression Syntax
for item
  (?aiLmsux)
we are promised "The flags are described in Module Contents"
but no description is found there.  In fact a number of other references are found to flags, but no description of the individual flags.  AFAICT the closest thing to a description is found at the original reference -- at least it gives a code and name for each one.

----------
assignee: docs at python
components: Documentation
messages: 283034
nosy: 4Dummies, docs at python
priority: normal
severity: normal
status: open
title: re.flags not documented in Module Contents as promised.
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec 12 13:59:27 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Dec 2016 18:59:27 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481569167.34.0.315902124315.issue28941@psf.upfronthosting.co.za>


Brett Cannon added the comment:

How is this different from issue #28929?

----------

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

From report at bugs.python.org  Mon Dec 12 14:03:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Dec 2016 19:03:22 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
In-Reply-To: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>
Message-ID: <1481569402.68.0.145626334512.issue28951@psf.upfronthosting.co.za>


R. David Murray added the comment:

When I follow the link to module contents, I find a list of the flags with their descriptions.  (re.A, re.I, etc, etc).  Perhaps you are confusing the letters used in the regular expression to represent the flags with the flags themselves?  I'm not sure how we could make that clearer.

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

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

From report at bugs.python.org  Mon Dec 12 14:04:22 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 19:04:22 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481569462.03.0.892797284656.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

There's source code of the documentation itself 
https://github.com/python/cpython/blob/master/Doc/library/abc.rst ) for 

and source code of abc.py 
https://github.com/python/cpython/blob/master/Lib/abc.py

Maybe I misunderstood, I figured issue #28929 is for fixing the docs url only.

----------

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

From report at bugs.python.org  Mon Dec 12 15:17:00 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 12 Dec 2016 20:17:00 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1481573820.52.0.0772875601704.issue28845@psf.upfronthosting.co.za>


Julien Palard added the comment:

LGTM but no AIX to test it.

----------

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

From report at bugs.python.org  Mon Dec 12 16:37:21 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Dec 2016 21:37:21 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1481578641.41.0.491252991759.issue28089@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yury, look good to you?

----------
stage: patch review -> commit review
versions: +Python 3.7

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

From report at bugs.python.org  Mon Dec 12 16:45:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2016 21:45:29 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161212214526.99657.39161.2BD0FA45@psf.io>


Roundup Robot added the comment:

New changeset 853e3f4d6cd9 by Yury Selivanov in branch '3.6':
Issue #28089: Document TCP_NODELAY in asyncio
https://hg.python.org/cpython/rev/853e3f4d6cd9

New changeset 0d209cc7ffdc by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28089)
https://hg.python.org/cpython/rev/0d209cc7ffdc

----------

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

From report at bugs.python.org  Mon Dec 12 16:46:32 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Dec 2016 21:46:32 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1481579192.53.0.309935515709.issue28089@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yury, look good to you?

Yes; committed the patch with a small addition.  Thanks, Mariatta!

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

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

From report at bugs.python.org  Mon Dec 12 20:03:37 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 13 Dec 2016 01:03:37 +0000
Subject: [docs] [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481591017.68.0.594481593523.issue28944@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

You're reusing the same issue for completely different things. Make a separate issue for separate docs issues.

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

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

From report at bugs.python.org  Mon Dec 12 21:22:46 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 13 Dec 2016 02:22:46 +0000
Subject: [docs] [issue28954] Incorrect EBNF rule of keywords_arguments
Message-ID: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>


New submission from woo yoo:

This is the documented rule, which lacks a comma within the last line.
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item | "**" expression)*
The correct form should be:
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item |",""**" expression)*

The original documentation is https://docs.python.org/3/reference/expressions.html#calls

----------
assignee: docs at python
components: Documentation
messages: 283067
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Incorrect EBNF rule of keywords_arguments
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec 12 23:09:31 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 13 Dec 2016 04:09:31 +0000
Subject: [docs] [issue28955] Not matched behavior of numeric comparison with
 the documentation
Message-ID: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>


New submission from woo yoo:

According to the documentation, which said "Additionally, comparing any number to a not-a-number value will return False. ",the comparison of `float('nan')!= 1`should yield False, while the result is True.

Small errors like this in documentation should be corrected?

The related link https://docs.python.org/3/reference/expressions.html#value-comparisons

----------
assignee: docs at python
components: Documentation
messages: 283069
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Not matched behavior of numeric comparison with the documentation
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec 12 23:13:08 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 13 Dec 2016 04:13:08 +0000
Subject: [docs] [issue28955] Not matched behavior of numeric comparison with
 the documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1481602388.0.0.456050183433.issue28955@psf.upfronthosting.co.za>


woo yoo added the comment:

Maybe the description should be changed into "all order comparisons of not-a-number and any number will return False"

----------

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

From report at bugs.python.org  Tue Dec 13 06:45:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Dec 2016 11:45:13 +0000
Subject: [docs] [issue28955] Not matched behavior of numeric comparison with
 the documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1481629513.84.0.298336057294.issue28955@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure, we like to make the docs more precise when it doesn't interfere with the presentation.  Perhaps something like:  "Additionally, ordering comparisions involving not-a-number values will always return False."

I wonder if we should also mention here that this follows the IEEE standard.

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

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

From report at bugs.python.org  Tue Dec 13 08:02:11 2016
From: report at bugs.python.org (Mateusz Loskot)
Date: Tue, 13 Dec 2016 13:02:11 +0000
Subject: [docs] [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1481634131.15.0.83402404538.issue14597@psf.upfronthosting.co.za>


Changes by Mateusz Loskot <mateusz at loskot.net>:


----------
nosy: +mloskot

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

From kritinsaraf at gmail.com  Sat Dec 10 10:02:52 2016
From: kritinsaraf at gmail.com (Kritin Saraf)
Date: Sat, 10 Dec 2016 15:02:52 +0000
Subject: [docs] Emergency - Help - Python File opening Blank
Message-ID: <CALZ4Z4gk-3=gOfBUKg2Od8xde60+FJGxUVuqnE1O6OpGLv0A1g@mail.gmail.com>

I was Writing a program in python 2.7.4 and had run the program and had
already saved it but when i restarted my computer the file is blank. the
file has been attached in the mail. I hope you could help me recover the
file.

Thank you,
A Young Programmer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161210/1a5fb120/attachment.html>
-------------- next part --------------


From report at bugs.python.org  Tue Dec 13 08:38:04 2016
From: report at bugs.python.org (Ryan)
Date: Tue, 13 Dec 2016 13:38:04 +0000
Subject: [docs] [issue28960] Small typo in Thread.join docs
Message-ID: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>


New submission from Ryan:

There is a '--' before a ',' that doesn't make sense here: https://docs.python.org/3/library/threading.html#threading.Thread.join

----------
assignee: docs at python
components: Documentation
files: fixdoc.patch
keywords: patch
messages: 283101
nosy: docs at python, rcorre
priority: normal
severity: normal
status: open
title: Small typo in Thread.join docs
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45875/fixdoc.patch

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

From report at bugs.python.org  Tue Dec 13 08:43:32 2016
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 13 Dec 2016 13:43:32 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1481636612.49.0.271361384141.issue28845@psf.upfronthosting.co.za>


David Edelsohn added the comment:

There is an AIX system in the Python buildbot farm. Why do you say no AIX to test?

----------

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

From report at bugs.python.org  Tue Dec 13 12:17:25 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 13 Dec 2016 17:17:25 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1481649445.84.0.380378122713.issue26546@psf.upfronthosting.co.za>


Julien Palard added the comment:

For the record, I opened a WIP pull request here: https://github.com/python/docsbuild-scripts/pull/8

Feedback is welcome.

----------

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

From report at bugs.python.org  Tue Dec 13 12:48:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Dec 2016 17:48:45 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481651325.28.0.645488834502.issue28941@psf.upfronthosting.co.za>


Brett Cannon added the comment:

No, I'm the one who misunderstood; I read the title of the issue too quickly after reading the doc source link issue and my brain didn't pick up on the "source code" part of the title. Sorry about that.

----------

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

From report at bugs.python.org  Tue Dec 13 14:24:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Dec 2016 19:24:27 +0000
Subject: [docs] [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1481657067.74.0.324554331486.issue28960@psf.upfronthosting.co.za>


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


----------
stage:  -> commit review
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Dec 13 15:17:17 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 13 Dec 2016 20:17:17 +0000
Subject: [docs] [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481660237.01.0.0815291157954.issue28944@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


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

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

From report at bugs.python.org  Wed Dec 14 06:09:40 2016
From: report at bugs.python.org (Evan)
Date: Wed, 14 Dec 2016 11:09:40 +0000
Subject: [docs] [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1481713780.71.0.773713727677.issue28960@psf.upfronthosting.co.za>


Evan added the comment:

I think the patch should remove the comma, not the double dash. This is a parenthetical remark and should end the same way it starts.

See https://www.grammarly.com/handbook/punctuation/dash/2/dash-parenthetical-information/

----------
nosy: +evan_

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

From abusmail619 at yahoo.co.uk  Wed Dec 14 06:48:16 2016
From: abusmail619 at yahoo.co.uk (Ismail Abubakar)
Date: Wed, 14 Dec 2016 11:48:16 +0000 (UTC)
Subject: [docs] python 3.5.2
References: <1880409004.4634136.1481716096491.ref@mail.yahoo.com>
Message-ID: <1880409004.4634136.1481716096491@mail.yahoo.com>

Good day sir/ma, please I need a beginner's ebook for python 3.5.2.I'll very much appreciate it if my response is granted ASAP. Thanks?

Sent from Yahoo Mail on Android
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161214/9d5627ac/attachment.html>

From clvanwall at gmail.com  Tue Dec 13 14:43:33 2016
From: clvanwall at gmail.com (clvanwall)
Date: Tue, 13 Dec 2016 13:43:33 -0600
Subject: [docs] Missing modules in PYTHON3
Message-ID: <ca76ld38ftids309yjgmo0mg.1481658213104@email.android.com>

Support for gnu dbm via dbm errors out because gdbm module not found. Likewise, support for ndbm is misssing because _dbm module is missing. Please see the dbm module for details. ?I am using Python 3 v 3.5.2 on windows 8.1
John Van Walleghen


Sent from my Galaxy Tab? A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161213/ac9dc8bd/attachment-0001.html>

From report at bugs.python.org  Wed Dec 14 08:00:03 2016
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 14 Dec 2016 13:00:03 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
Message-ID: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>


New submission from Miki Tebeka:

Several modules can be invoked with -m and are pretty handy (json.tool, zipfile, tarfile ...).

There should be a section in the documentation that groups all of these "python -m" tools together. Something like http://pythonwise.blogspot.nl/2015/01/python-m.html

----------
assignee: docs at python
components: Documentation
messages: 283190
nosy: docs at python, tebeka
priority: normal
severity: normal
status: open
title: Document all "python -m" utilities
type: enhancement

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

From report at bugs.python.org  Wed Dec 14 08:48:47 2016
From: report at bugs.python.org (Ryan)
Date: Wed, 14 Dec 2016 13:48:47 +0000
Subject: [docs] [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1481723327.7.0.140708899319.issue28960@psf.upfronthosting.co.za>


Ryan added the comment:

Removing the comma instead of the double-dash

----------
Added file: http://bugs.python.org/file45898/fixdoc2.patch

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

From report at bugs.python.org  Wed Dec 14 10:05:57 2016
From: report at bugs.python.org (Bernhard10)
Date: Wed, 14 Dec 2016 15:05:57 +0000
Subject: [docs] [issue28973] The fact that multiprocess.Queue uses
 serialization should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481727957.22.0.301936495254.issue28973@psf.upfronthosting.co.za>


Bernhard10 added the comment:

See http://stackoverflow.com/a/925241/5069869

Apparently multiprocessing.Queue uses pickle to serialize the objects in the queue, which explains the change of identity, but is absolutely unclear from the documentation.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: multiprocess.Queue changes objects identity -> The fact that multiprocess.Queue uses serialization should be documented.

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

From report at bugs.python.org  Wed Dec 14 10:12:31 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Dec 2016 15:12:31 +0000
Subject: [docs] [issue28973] The fact that multiprocess.Queue uses
 serialization should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481728351.33.0.596160927506.issue28973@psf.upfronthosting.co.za>


R. David Murray added the comment:

That fact that this is so is implicit in the name multi*process*ing and
the documented restrictions of the id function.  That is, it is the purpose of the module is to manage computation across multiple processes.  Since different processes have distinct memory spaces, you cannot depend on object identity between processes, by the definition of object identity (it is constant only for the lifetime of the object in memory, and the different processes have different memory spaces, therefore the object id may be different in the different processes).  By construction this applies also to any multiprocessing mechanism that is used to transmit objects, even if the transmission turns out to be to the same process in a particular case.  You can't *depend* on the id in that case, because the transmission mechanism must be free to change the object identity in order to work in the general case.

Should we document this explicitly?  Perhaps so.  Maybe in the multiprocessing introduction?

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

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

From report at bugs.python.org  Wed Dec 14 10:18:24 2016
From: report at bugs.python.org (Bernhard10)
Date: Wed, 14 Dec 2016 15:18:24 +0000
Subject: [docs] [issue28973] The fact that multiprocess.Queue uses
 serialization should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481728704.19.0.189753520296.issue28973@psf.upfronthosting.co.za>


Bernhard10 added the comment:

My first thought was that Queue was implemented using shared memory.
I guess from the fact that the "Shared memory" section is separate in the multiprocessing documentation I should have known better, though.

So I guess some clarification in the documentation would be helpful.

----------

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

From report at bugs.python.org  Wed Dec 14 10:37:10 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Dec 2016 15:37:10 +0000
Subject: [docs] [issue28973] The fact that multiprocess.Queue uses
 serialization should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481729829.88.0.0506878492473.issue28973@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, that's why I said "in the general case".  Making it clear in the overview seems reasonable to me.

----------

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

From report at bugs.python.org  Wed Dec 14 11:33:49 2016
From: report at bugs.python.org (Davin Potts)
Date: Wed, 14 Dec 2016 16:33:49 +0000
Subject: [docs] [issue28973] The fact that multiprocess.Queue uses
 serialization should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481733229.41.0.0510367613957.issue28973@psf.upfronthosting.co.za>


Davin Potts added the comment:

All communication between processes in multiprocessing has consistently used pickle to serialize the data being communicated (this includes what is described in the "Shared memory" section of the docs).  The documentation has not done a great job of making this clear, instead only describing the requirement that data be pickleable in select places.  For example, in the section on Queues:
    Note: When an object is put on a queue, the object is pickled and a
    background thread later flushes the pickled data to an underlying pipe.

Though it only applies to 3.6+, issue28053 still needs its own documentation improvement to make clear that the mechanism for communicating data defaults to serialization by pickle but that this can be replaced by alternatives.

I agree that the documentation around the use of pickle in multiprocessing deserves improvement.

----------
nosy: +davin
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec 14 21:37:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 02:37:57 +0000
Subject: [docs] [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <20161215023753.5114.22277.0FDFFEB5@psf.io>


Roundup Robot added the comment:

New changeset a89469328b78 by Berker Peksag in branch '3.5':
Issue #28944: Fix footnote numbering
https://hg.python.org/cpython/rev/a89469328b78

New changeset 502f5d53fb4a by Berker Peksag in branch '3.6':
Issue #28944: Merge from 3.5
https://hg.python.org/cpython/rev/502f5d53fb4a

New changeset 13b600dc4ee5 by Berker Peksag in branch 'default':
Issue #28944: Merge from 3.6
https://hg.python.org/cpython/rev/13b600dc4ee5

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

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

From report at bugs.python.org  Wed Dec 14 21:38:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Dec 2016 02:38:42 +0000
Subject: [docs] [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481769521.97.0.681095595246.issue28944@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, woo woo.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec 14 21:49:32 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Dec 2016 02:49:32 +0000
Subject: [docs] [issue28954] Incorrect EBNF rule of keywords_arguments
In-Reply-To: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>
Message-ID: <1481770172.76.0.360243270286.issue28954@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec 14 22:24:55 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 03:24:55 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
Message-ID: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>


New submission from woo yoo:

The paragraph that describes the precedence of semicolon encounters a minor error, which said :
"Also note that the semicolon binds tighter than the colon in this context, so that in the following example, either all or none of the print() calls are executed:
if x < y < z: print(x); print(y); print(z)" 
However,the series of print function calls could execute partly if the previous ones are legal.

----------
assignee: docs at python
components: Documentation
messages: 283232
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: incorrect description that dose not conform to the actual behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Dec 14 22:26:17 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 03:26:17 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481772377.01.0.547239394992.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

Forget to attach the link https://docs.python.org/3/reference/compound_stmts.html#compound-statements

----------

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

From report at bugs.python.org  Wed Dec 14 23:55:55 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:55:55 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777754.93.0.0800021825104.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Attached is the patch that will work for 3.6 and 3.7 branches.

The url will be changed from
https://hg.python.org/cpython/file/3.6/Lib/abc.py

into 
https://github.com/python/cpython/blob/3.6/Lib/abc.py for python version 3.6,
and 
https://github.com/python/cpython/blob/master/Lib/abc.py for python version 3.7

----------
keywords: +patch
Added file: http://bugs.python.org/file45904/issue28941.patch

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

From report at bugs.python.org  Wed Dec 14 23:57:22 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:57:22 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777842.39.0.875338602085.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Patch for 3.5 branch.

The url will change from
https://hg.python.org/cpython/file/3.5/Lib/abc.py

into
https://github.com/python/cpython/blob/3.5/Lib/abc.py

----------
Added file: http://bugs.python.org/file45905/issue28941v35.patch

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

From report at bugs.python.org  Wed Dec 14 23:58:16 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:58:16 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777896.82.0.219383807835.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Patch for 2.7 branch.

The url will change from
https://hg.python.org/cpython/file/2.7/Lib/abc.py

into
https://github.com/python/cpython/blob/2.7/Lib/abc.py

----------
Added file: http://bugs.python.org/file45906/issue28941v27.patch

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

From report at bugs.python.org  Wed Dec 14 23:59:38 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:59:38 +0000
Subject: [docs] [issue28941] Update the link to Source Code in Python Docs
 from hg to github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777978.74.0.0819177388511.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Please let me know if I'm doing this right :) Thanks.

----------

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

From report at bugs.python.org  Thu Dec 15 03:36:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 08:36:01 +0000
Subject: [docs] [issue28977] Document PyObject_CallFunction() special case
 more explicitly
Message-ID: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PyObject_CallFunction() function has a special case if the format string is "O". See my email thread on python-dev:
https://mail.python.org/pipermail/python-dev/2016-December/146919.html

Serhiy wrote: "It is documented for Py_BuildValue(), and the documentation of PyObject_CallFunction() refers to Py_BuildValue()." which is true, but I would prefer to be more explicit to avoid bad surprises (see issues #21209 and #28920).

Attached patch modifies PyObject_CallFunction() doc to mention the "O" format special case in the .rst doc and the .h comment.

The documentation of PyObject_CallMethod() and _PyObject_CallMethodId() should also be modified, but I would prefer to wait for a first review on the added text before modifying all functions.

I proposed to only modify Python 3.7 because Include/abstract.h was a in a bad shape: I rewrote this file to make it easier to maintain, but only in Python 3.7, see issue #28838.

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: call_doc.patch
keywords: patch
messages: 283256
nosy: docs at python, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document PyObject_CallFunction() special case more explicitly
versions: Python 3.7
Added file: http://bugs.python.org/file45908/call_doc.patch

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

From report at bugs.python.org  Thu Dec 15 04:41:29 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 09:41:29 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481794889.72.0.24160212185.issue28976@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Can you provide a code snippet that demonstrates the actual problem? As far as I can see this code behaves as documented

----------
nosy: +brendan-donegan

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

From report at bugs.python.org  Thu Dec 15 05:03:08 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 10:03:08 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481796188.95.0.691464598818.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

code :
>>> if 1<2<3:print(123);print(op);

Output:
123
Traceback (most recent call last):
.... 
NameError:...

----------

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

From report at bugs.python.org  Thu Dec 15 05:08:03 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 10:08:03 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481796483.22.0.275203667989.issue28976@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

How does that contradict the documentation? Both print statements were executed - the second one raised an exception because of 'op' not being defined.

----------

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

From report at bugs.python.org  Thu Dec 15 05:21:20 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 10:21:20 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481797280.02.0.894140192682.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

code :
>>> if 1<2<3:print(123);print(op);print(opi);

Output:
123
Traceback (most recent call last):
.... 
NameError:name 'op' is not defined

The third 'print' call hasn't been executed.

----------

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

From report at bugs.python.org  Thu Dec 15 06:07:28 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 11:07:28 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481800048.09.0.167492405171.issue28976@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Indeed, but that's merely because an exception has been raised. The example given doesn't include any statements that would raise an exception.

I'm not sure it's necessary to re-iterate well known Python behaviour in this section.

Anyway, that's my 2c

----------

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

From report at bugs.python.org  Thu Dec 15 06:17:59 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 11:17:59 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481800679.54.0.534873128382.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

Thanks for your attention.

----------

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

From report at bugs.python.org  Thu Dec 15 06:59:34 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 11:59:34 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
Message-ID: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>


New submission from woo yoo:

Quote the documentation as below:

> parameter_list ::=  (defparameter ",")*
                    | "*" [parameter] ("," defparameter)* ["," "**" parameter]
                    | "**" parameter
                    | defparameter [","] )

The last right parenthesis is redundant.And the second alternative form is not complete, it does not incorporate a case that only include starred parameter.

----------
assignee: docs at python
components: Documentation
messages: 283288
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: a redundant right  parentheses in the EBNF rules of parameter_list
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec 15 07:00:22 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 12:00:22 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481803222.22.0.740914435527.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Here is the link https://docs.python.org/3/reference/compound_stmts.html#function-definitions

----------

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

From report at bugs.python.org  Thu Dec 15 07:04:20 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 12:04:20 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481803460.22.0.368768506027.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Just the right parenthesis is redundant, ignore other words.

----------

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

From report at bugs.python.org  Thu Dec 15 07:52:26 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 12:52:26 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481806345.99.0.289474483462.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

And i find that the current rules of parameter_list includes a bare '*',which is illegal in practice.

----------

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

From report at bugs.python.org  Thu Dec 15 08:07:08 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 15 Dec 2016 13:07:08 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481807228.94.0.106709639053.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

See issue<9232> that changed the docs on function definitions. These changes aren't reflected in the 3.5 documentation though, you'll find them in the 3.6 docs.

The linked grammar is probably missing an opening parentheses from what I can tell, i.e change | to (:

    ( "*" [parameter] ("," defparameter)* ["," "**" parameter]

----------
nosy: +Jim Fasarakis-Hilliard

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

From osama.ess92 at gmail.com  Wed Dec 14 15:29:54 2016
From: osama.ess92 at gmail.com (Osama Essam)
Date: Wed, 14 Dec 2016 22:29:54 +0200
Subject: [docs] missed url before open
Message-ID: <CAAToqKCNzDdHRU9kDvP9yHT4UraM8isyqhB5=kLrctZ1HWQTMQ@mail.gmail.com>

Hello, i think there is url was missed before open at second code block in
https://docs.python.org/3.1/howto/urllib2.html#data

Very nice work, keep it up.

Regards, Osama.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161214/78184956/attachment-0001.html>

From report at bugs.python.org  Thu Dec 15 08:40:20 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 13:40:20 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481809220.57.0.490397704924.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

There is  a few difference between Python-3.5.2 and Python-3.6.2 concerning the EBNF rules even though the parenthesis bug is fixed.

----------

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

From report at bugs.python.org  Thu Dec 15 08:43:12 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 13:43:12 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481809392.24.0.817587503187.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Nor the rules in Python-3.6.0 excludes the bare '*' following no parameters.

----------

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

From report at bugs.python.org  Thu Dec 15 08:52:12 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 15 Dec 2016 13:52:12 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
Message-ID: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

Specifically, the entry reads:

"The dict type has been reimplemented to use a faster, more compact representation similar to the PyPy dict implementation."

Through, the text describing the new implementation doesn't mention anything on speed, it only mentions memory usage.

issue27350 and, specifically, msg275587 even report a slight regression ok key look-ups. Am I interpreting this differently? If not, is it a good idea to be stating it is faster?

----------
assignee: docs at python
components: Documentation
messages: 283304
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: What's New entry on compact dict mentions "faster" implementation
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec 15 09:14:04 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:14:04 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481811244.29.0.613876129402.issue28976@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/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:26:21 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 14:26:21 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481811981.39.0.0960338670563.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

Why the issue was closed?

----------

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

From report at bugs.python.org  Thu Dec 15 09:46:26 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 14:46:26 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481813186.54.0.552060450737.issue28976@psf.upfronthosting.co.za>


Changes by woo yoo <chaozhou1232 at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec 15 09:51:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:51:50 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481813510.54.0.0846691417011.issue28978@psf.upfronthosting.co.za>


R. David Murray added the comment:

What do you mean by "a bare * followed by no parameters"?  That is, what is the thing that is considered invalid that you are saying the BNF rules allow?  I'm looking for a code snipped that produces a syntax error.

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

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

From report at bugs.python.org  Thu Dec 15 09:57:05 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:57:05 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481813825.82.0.213388035801.issue28976@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because the documentation is correct.  There is no bug here.  As Brendan said, there is no need to repeat a fundamental (that statements can raise exceptions) in this context.  The point of the passage is that

  if x: a; b; c;

is equivalent to

  if x:
     a
     b
     c

not

  if x: a
  b
  c

And that is what it clearly says, in my opinion.  The language reference is a specification and not a tutorial, so more words here would not be a good idea.

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

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

From report at bugs.python.org  Thu Dec 15 09:59:32 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 14:59:32 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481813972.78.0.414631410366.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Code:
>>>def f(a, *):
>>>    print(a)
....
....?SyntaxError occurs here?

----------

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

From report at bugs.python.org  Thu Dec 15 10:03:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 15:03:47 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481814227.26.0.295291714923.issue28978@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  (", " defparameter)* should instead be "+", or whatever the BNF equivalent is.

----------

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

From report at bugs.python.org  Thu Dec 15 10:09:27 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:09:27 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481814567.55.0.702359611417.issue28979@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Agree. Patch provided.

----------
keywords: +patch
nosy: +brendan-donegan
Added file: http://bugs.python.org/file45919/whatsnew36.patch

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

From report at bugs.python.org  Thu Dec 15 10:10:28 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:10:28 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481814628.74.0.308811208976.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

According to the original description, "either all or none...",what does 'none' represent?

----------

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

From report at bugs.python.org  Thu Dec 15 10:13:27 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:13:27 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481814628.74.0.308811208976.issue28976@psf.upfronthosting.co.za>
Message-ID: <CAESAk0g=iH-HOpo3mDA_vaQVTTiXKR1rRde4YS+SDk0yNNvSbQ@mail.gmail.com>


Brendan Donegan added the comment:

None represents the case where the if statement is false

On Thu, 15 Dec 2016 at 20:40 woo yoo <report at bugs.python.org> wrote:

>
> woo yoo added the comment:
>
> According to the original description, "either all or none...",what does
> 'none' represent?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28976>
> _______________________________________
>

----------
nosy: +brendand

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

From report at bugs.python.org  Thu Dec 15 10:20:46 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:20:46 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481815246.6.0.993886730873.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

"either all or none of the print() calls are executed",I think the 'none' describes the number of the calls to be executed.

----------

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

From report at bugs.python.org  Thu Dec 15 10:22:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 15:22:27 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <20161215152223.3621.12193.29210640@psf.io>


Roundup Robot added the comment:

New changeset 181453f9a0c4 by Victor Stinner in branch '3.6':
Issue #28979: Fix What's New in Python 3.6, dict
https://hg.python.org/cpython/rev/181453f9a0c4

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

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

From report at bugs.python.org  Thu Dec 15 10:23:17 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:23:17 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481815246.6.0.993886730873.issue28976@psf.upfronthosting.co.za>
Message-ID: <CAESAk0gh01gPpcWEsfzJWbZ3+tteS2hHj067E48vj6M+LBt3=Q@mail.gmail.com>


Brendan Donegan added the comment:

I think the consensus is that the wording is correct. If you can come up
with text that is clearer, and still correct, please do submit a patch.

On Thu, 15 Dec 2016 at 20:50 woo yoo <report at bugs.python.org> wrote:

>
> woo yoo added the comment:
>
> "either all or none of the print() calls are executed",I think the 'none'
> describes the number of the calls to be executed.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28976>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Dec 15 10:23:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 15:23:26 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481815406.34.0.519837367998.issue28979@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Ned: Would you be ok to cherry-pick 181453f9a0c4 in Python 3.6.0?

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

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

From report at bugs.python.org  Thu Dec 15 10:23:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 15:23:46 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481815426.08.0.713689323214.issue28979@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +inada.naoki, ned.deily, serhiy.storchaka, yselivanov

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

From report at bugs.python.org  Thu Dec 15 10:35:54 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:35:54 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481816154.87.0.99733921822.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

In fact, I'm a newcomer to Python. When i have experimented with those description interactively using Python interpreter, i got confused.

I don't know how to submit a patch.If the description were changed by me,it would be?
>if x<y<z:print(x);print(y);print(z) 
>is equivalent to
>if x<y<z:
>    print(x)
>    print(y)
>    print(z)

----------

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

From report at bugs.python.org  Thu Dec 15 10:42:11 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 15:42:11 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481816531.85.0.213599139633.issue28976@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I said, the language reference is a specification, not a tutorual.  The text as written is clear technical English.  You are correct that 'none' refers to the number of statements executed, but 'none' are executed when the statement is false, and 'all' are executed when the statement is true.  The fact that execution of a suite may be interrupted by an exception is covered elsewhere in the language reference and it would not enhance the documentation to repeat it here.

If other core developers think putting in the example is appropriate I'm not going to object, but I don't think they will.

----------

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

From report at bugs.python.org  Thu Dec 15 10:52:18 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:52:18 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481817138.85.0.857163780569.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

I think i understand you now.My english needs to improve.Thanks for your patience.

----------

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

From report at bugs.python.org  Thu Dec 15 10:53:05 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:53:05 +0000
Subject: [docs] [issue28976] incorrect description that dose not conform to
 the actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481817185.38.0.0949129635897.issue28976@psf.upfronthosting.co.za>


Changes by woo yoo <chaozhou1232 at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec 15 10:54:42 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Dec 2016 15:54:42 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481817282.68.0.963273790434.issue28979@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
priority: normal -> release blocker

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

From report at bugs.python.org  Thu Dec 15 15:21:18 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 15 Dec 2016 20:21:18 +0000
Subject: [docs] [issue28794] inspect.isasyncgen and
 inspect.isasyncgenfunction aren't documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1481833278.74.0.6639145436.issue28794@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

LGTM. Thanks for the patch!

----------
nosy: +ebarry
stage:  -> commit review

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

From report at bugs.python.org  Thu Dec 15 17:58:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 22:58:02 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161215225759.33256.68055.648749C3@psf.io>


Roundup Robot added the comment:

New changeset 418ba3a0f090 by Yury Selivanov in branch '3.6':
Issue #28635: asyncio-related fixes and additions.
https://hg.python.org/cpython/rev/418ba3a0f090

New changeset 83eb8053a4e1 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/83eb8053a4e1

----------

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

From report at bugs.python.org  Thu Dec 15 20:22:14 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Fri, 16 Dec 2016 01:22:14 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481851334.59.0.316140574402.issue28972@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi,

I believe it's already done.  The only thing that people tends to forget is that doing python -m "module.script(.py)" is only doing the equivalent of "python module/script.py". 

I believe it's clear though ;
https://docs.python.org/3/using/cmdline.html#cmdoption-m

Any module that anyone has done can do it, so it would be up to the module developer to put it in the README/Description of the module to describe how to use it.  That's what I think

BTW, I'm just giving my opinion out of contributing.  Please don't see it as a denial as it's not the case.  Python strive to be clearer but has 20 years of existence.  Enhancing it is hard.

Regards,
Eric Lafontaine

----------
nosy: +Eric Lafontaine

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

From report at bugs.python.org  Thu Dec 15 20:36:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 16 Dec 2016 01:36:04 +0000
Subject: [docs] [issue28794] inspect.isasyncgen and
 inspect.isasyncgenfunction aren't documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1481852163.91.0.64118199906.issue28794@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, but these two functions have already been documented in 78c8f450b84c. Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: commit review -> resolved
status: open -> closed
type:  -> enhancement

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

From storchaka+cpython at gmail.com  Fri Dec 16 02:03:58 2016
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Fri, 16 Dec 2016 07:03:58 -0000
Subject: [docs] Document PyObject_CallFunction() special case more
 explicitly (issue 28977)
Message-ID: <20161216070358.28909.86105@psf.upfronthosting.co.za>


https://bugs.python.org/review/28977/diff/19473/Doc/c-api/object.rst
File Doc/c-api/object.rst (right):

https://bugs.python.org/review/28977/diff/19473/Doc/c-api/object.rst#newcode279
Doc/c-api/object.rst:279: there is a single argument.
PyObject_CallFunctionObjArgs looks better alternative to me. And
PyObject_CallObject is better alternative when you need to unpack a
tuple.

Since "O" is exceptional case and its behavior is likely unexpected, and
there are good alternatives, maybe format this note with "note" or
"warning" directives?

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

From report at bugs.python.org  Fri Dec 16 02:21:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 07:21:19 +0000
Subject: [docs] [issue28977] Document PyObject_CallFunction() special case
 more explicitly
In-Reply-To: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>
Message-ID: <1481872879.84.0.0114129819879.issue28977@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"O" is not the only special case. "S" and "N" unpack a tuple argument too. "O&" converter should return a tuple, otherwise it is an error. All other format codes are illegal for single argument.

I would just deprecate this feature (in PyObject_CallFunction, not in Py_BuildValue). The behavior of PyObject_CallFunction with a single argument can be made more consistent and useful.

----------

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

From report at bugs.python.org  Fri Dec 16 02:44:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:42 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.10709.8CCF2EF5@psf.io>


Roundup Robot added the comment:

New changeset 257a1c7f9507 by Ned Deily in branch '3.6':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/257a1c7f9507

----------

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

From report at bugs.python.org  Fri Dec 16 02:44:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:42 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.92423.827B54BE@psf.io>


Roundup Robot added the comment:

New changeset 911cc601089d by Victor Stinner in branch '3.6':
Issue #28979: Fix What's New in Python 3.6, dict
https://hg.python.org/cpython/rev/911cc601089d

----------

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

From report at bugs.python.org  Fri Dec 16 02:44:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:47 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.40322.A244661C@psf.io>


Roundup Robot added the comment:

New changeset dfd1019f75f9 by Yury Selivanov in branch '3.6':
Issue #28089: Document TCP_NODELAY in asyncio
https://hg.python.org/cpython/rev/dfd1019f75f9

----------

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

From report at bugs.python.org  Fri Dec 16 02:44:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:48 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.76082.664DBBA7@psf.io>


Roundup Robot added the comment:

New changeset cb4ad88fdc91 by Yury Selivanov in branch '3.6':
Issue #28635: Drop the note that whatsnew is incomplete
https://hg.python.org/cpython/rev/cb4ad88fdc91

New changeset c4d6ef15bb7c by Yury Selivanov in branch '3.6':
Issue #28635: asyncio-related fixes and additions.
https://hg.python.org/cpython/rev/c4d6ef15bb7c

----------

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

From report at bugs.python.org  Fri Dec 16 02:49:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:49:45 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1481874585.26.0.152437443016.issue28635@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0r2]

----------

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

From report at bugs.python.org  Fri Dec 16 02:54:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:54:15 +0000
Subject: [docs] [issue28089] asyncio: Document that TCP_NODELAY is now used
 by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1481874855.35.0.0572317002013.issue28089@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: deferred blocker -> 

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

From report at bugs.python.org  Fri Dec 16 02:55:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:55:29 +0000
Subject: [docs] [issue28979] What's New entry on compact dict mentions
 "faster" implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481874929.68.0.859926562896.issue28979@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec 16 03:01:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 08:01:46 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481875306.64.0.59772053673.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------

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

From report at bugs.python.org  Fri Dec 16 03:02:38 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 08:02:38 +0000
Subject: [docs] [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481875358.27.0.4341522501.issue28900@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


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

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

From report at bugs.python.org  Fri Dec 16 03:07:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 08:07:54 +0000
Subject: [docs] [issue28977] Document PyObject_CallFunction() special case
 more explicitly
In-Reply-To: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>
Message-ID: <1481875674.43.0.0310547265459.issue28977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "O" is not the only special case. "S" and "N" unpack a tuple argument too. "O&" converter should return a tuple, otherwise it is an error. All other format codes are illegal for single argument.

Oh, I didn't know. I should update my documentation.


Serhiy: I would just deprecate this feature (in PyObject_CallFunction, not in Py_BuildValue). The behavior of PyObject_CallFunction with a single argument can be made more consistent and useful.

PyObject_CallFunction(func, "O", arg) should call func(arg). I don't want the "O" format (and "S" and "N").

What do you mean exactly by deprecating the feature? Emit a warning if and only if te format string is "O" (or "S" or "N") and Py_BuildValue() returns a tuple?

I guess that PyObject_CallFunction(func, "(O)", arg) doesn't need to be modified, it already always call func(arg), even if arg is a tuple.

I am also tempted to fix PyObject_CallFunction() (and similar functions) rather than documenting the special case, but I dislike the idea of a deprecation.

Let's say that calling PyObject_CallFunction(func, "O", arg) where arg is a tuple would emit a DeprecationWarning and call func(*arg) in Python 3.7, but call func(arg) with no warning in Python 3.8. I dislike this path because developers would try to make the warning quiet in Python 3.7, for example use "(O)" format string, which is less obvious and looks like a hack to me.


More and more applications use Python bleeding edge (the development branch, default), and more and more developers quickly test their application on the new Python stable release. Maybe we can "simply" fix the behaviour of PyObject_CallFunction() with no transition period:

* Python 3.6: PyObject_CallFunction(func, "O", arg) calls func(arg), or func(*arg) if arg is a tuple
* Python 3.7: PyObject_CallFunction(func, "O", arg) always calls func(arg)

The special case was never documented. In my experience, almost no developer rely on this feature. Most developers don't expect the feature and so write code which doesn't work with tuple arguments.

----------

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

From report at bugs.python.org  Fri Dec 16 03:14:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 08:14:52 +0000
Subject: [docs] [issue28977] Document PyObject_CallFunction() special case
 more explicitly
In-Reply-To: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>
Message-ID: <1481876092.65.0.30455244179.issue28977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If the behaviour of PyObject_CallFunction(func, "O", arg) is changed, an application relying on the current behaviour would have to replace:

   res = PyObject_CallFunction(func, "O", arg);

with:

   /* code working on any Python version */
   if (PyTuple_Check(arg))
       res = PyObject_Call(func, arg, NULL);
   else
       res = PyObject_CallFunction(func, "O", arg);

----------

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

From report at bugs.python.org  Fri Dec 16 03:49:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 08:49:51 +0000
Subject: [docs] [issue28977] Document PyObject_CallFunction() special case
 more explicitly
In-Reply-To: <1481875674.43.0.0310547265459.issue28977@psf.upfronthosting.co.za>
Message-ID: <3340200.JrNllmOg0l@raxxla>


Serhiy Storchaka added the comment:

> All other format codes are illegal for single argument.

I was wrong. PyObject_CallFunction() handles correctly a single non-tuple 
argument. The problem is only with tuple result of Py_BuildValue().

> What do you mean exactly by deprecating the feature? Emit a warning if and
> only if te format string is "O" (or "S" or "N") and Py_BuildValue() returns
> a tuple?

Emit a FutureWarning if the format string contains the single format code and 
Py_BuildValue() returns a tuple. In 3.8 or 3.9 the behavior will be changed.

> I dislike this path
> because developers would try to make the warning quiet in Python 3.7, for
> example use "(O)" format string, which is less obvious and looks like a
> hack to me.

PyObject_CallFunctionObjArgs(func, arg, NULL) seems obvious and perhaps even 
more efficient in all versions.

> More and more applications use Python bleeding edge (the development branch,
> default), and more and more developers quickly test their application on
> the new Python stable release. Maybe we can "simply" fix the behaviour of
> PyObject_CallFunction() with no transition period:

Ask on Python-Dev. I afraid this is too dangerous. We should have at least one 
release with a FutureWarning.

> Most developers don't expect the feature and so write
> code which doesn't work with tuple arguments.

That is why we should add a FutureWarning. If the code doesn't fail by 
accident, but just works incorrectly, this can be unnoticed. FutureWarning 
could help to fix possible bugs in older Python versions.

----------

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

From report at bugs.python.org  Fri Dec 16 04:13:52 2016
From: report at bugs.python.org (Nick Evans)
Date: Fri, 16 Dec 2016 09:13:52 +0000
Subject: [docs] [issue28986] Docs should say set.update takes iterable
Message-ID: <1481879632.81.0.577859496056.issue28986@psf.upfronthosting.co.za>


New submission from Nick Evans:

The docs say that set.update takes *args:

  update(*others)

But actually set.update takes an optional iterable:

  update([iterable])

----------
assignee: docs at python
components: Documentation
messages: 283394
nosy: docs at python, nre3976
priority: normal
severity: normal
status: open
title: Docs should say set.update takes iterable
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 16 09:06:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Dec 2016 14:06:01 +0000
Subject: [docs] [issue28986] Docs should say set.update takes iterable
In-Reply-To: <1481879632.81.0.577859496056.issue28986@psf.upfronthosting.co.za>
Message-ID: <1481897161.3.0.1618513129.issue28986@psf.upfronthosting.co.za>


R. David Murray added the comment:

update([iterable]) is a specific case of update(*others).  udpate([1, 2], [3, 4]) is another specific case.

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

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

From report at bugs.python.org  Fri Dec 16 09:49:37 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 16 Dec 2016 14:49:37 +0000
Subject: [docs] [issue28987] Remove typo in whats new entry on Descriptor
 Protocol Enhancements
Message-ID: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

Attached patch removes small typo ('has') from text:

    extends the descriptor protocol has to include the new optional

----------
assignee: docs at python
components: Documentation
files: whatsnew_typo.patch
keywords: patch
messages: 283401
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: Remove typo in whats new entry on Descriptor Protocol Enhancements
versions: Python 3.6
Added file: http://bugs.python.org/file45924/whatsnew_typo.patch

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

From tibula at email.it  Fri Dec 16 13:29:57 2016
From: tibula at email.it (tibula at email.it)
Date: Fri, 16 Dec 2016 19:29:57 +0100
Subject: [docs] Release 3.5.2
Message-ID: <61df310aaa80928254501b5abb94b527@wm10.email.it>

&nbsp;


Vorrei sapere (per favore) dove posso trovare questga Release 3.5.2 in
lingua italiana


&nbsp;


Grazie 


Adrio Piga


&nbsp;


Python Tutorial


&nbsp;


&nbsp;


&nbsp;


Release 3.5.2


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


Guido van Rossum


&nbsp;


&nbsp;


&nbsp;


and the Python development team


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;


&nbsp;




 
 
 --
 ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli 
Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f
 
 Sponsor:
 Idee regalo classiche o alternative? Trova l'offerta migliore in un click
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13327&d=16-12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161216/fd5b08a5/attachment.html>

From report at bugs.python.org  Fri Dec 16 16:13:32 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Dec 2016 21:13:32 +0000
Subject: [docs] [issue28986] Docs should say set.update takes iterable
In-Reply-To: <1481879632.81.0.577859496056.issue28986@psf.upfronthosting.co.za>
Message-ID: <1481922812.94.0.326057984894.issue28986@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec 16 17:48:26 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 16 Dec 2016 22:48:26 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1481928506.12.0.586378437533.issue28816@psf.upfronthosting.co.za>


Decorater added the comment:

Well, Will there be any documentations for this before 3.6 final release or no because this would be nice to know for other people who would like to do something similar.

----------

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

From report at bugs.python.org  Fri Dec 16 18:35:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2016 23:35:29 +0000
Subject: [docs] [issue28929] Provide a link from documentation back to its
 source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481931329.9.0.689219481006.issue28929@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Nice idea.  I agree with an updated sidebar link, both aesthetically and as a practical matter for doc maintainers.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Dec 16 20:09:08 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Dec 2016 01:09:08 +0000
Subject: [docs] [issue28987] Remove typo in whats new entry on Descriptor
 Protocol Enhancements
In-Reply-To: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>
Message-ID: <1481936948.91.0.288255154288.issue28987@psf.upfronthosting.co.za>


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


----------
nosy: +Elvis.Pranskevichus, yselivanov

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

From report at bugs.python.org  Fri Dec 16 21:05:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Dec 2016 02:05:53 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481940353.22.0.811937999203.issue28972@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for Miki's idea.  It would be nice if there were a single page that collected together all the command-line tools (with examples).  It should include a 2to3 example as well.  Also, there should be some indication of which tools we guarantee to be available (2to3 json.tool) versus those that just happen to be exposed but are subject to change (possibly because they were just used for testing, or because they have a crummy API, or because Guido has said that we are in the library business, not the command-line tool business).

See also:  http://bugs.python.org/issue26488

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

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

From report at bugs.python.org  Fri Dec 16 22:08:24 2016
From: report at bugs.python.org (kevin)
Date: Sat, 17 Dec 2016 03:08:24 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
In-Reply-To: <1481569402.68.0.145626334512.issue28951@psf.upfronthosting.co.za>
Message-ID: <CAGVXcSbxSLJ5Kd2dtr-AH44agx8ouE+jJSmbgDkC=T14cJB_QA@mail.gmail.com>


kevin added the comment:

Ordinarily when I see a cross-reference like that "the flags are described
in foo" I expect foo to have a heading "FLAGS" so I can tell I'm looking at
what was promised.  Not knowing much about flags, it was not clear to me
that those scattered lines re.A through re.X were the promised
descriptions.  I didn't even notice them until now, partly because it's
made more confusing by all the stuff that's out of alphabetic order.  Or I
think it is -- it's hard to tell because of things like re.S and re.DOTALL
being together.  My current guess is that the uppercase things come before
lowercase, but those odd pairings are definitely messing with my mind.

All of which is just to say it probably makes perfect sense to someone
who's used to it, but it's hard on someone new to these docs, and I'm not
even new to Python, just to the re module.

On Mon, Dec 12, 2016 at 11:03 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> When I follow the link to module contents, I find a list of the flags with
> their descriptions.  (re.A, re.I, etc, etc).  Perhaps you are confusing the
> letters used in the regular expression to represent the flags with the
> flags themselves?  I'm not sure how we could make that clearer.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28951>
> _______________________________________
>

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

----------
Added file: http://bugs.python.org/file45934/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20161217/f7434179/attachment.gif>

From report at bugs.python.org  Sat Dec 17 02:52:12 2016
From: report at bugs.python.org (Miki Tebeka)
Date: Sat, 17 Dec 2016 07:52:12 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481961132.57.0.647089747379.issue28972@psf.upfronthosting.co.za>


Miki Tebeka added the comment:

Eric - sorry I wasn't clear. I'm not talking about the -m behavior in general but on the modules in the standard library that can be used with it. A lot of windows are happy to know about "python -m tarfile" to they can extract tar files without installing an extra tool and some Linux people are happy to know on "python -m zipfile" so they don't have to install the "zip" utility to extract/create zip archives. etc ...

----------

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

From report at bugs.python.org  Sat Dec 17 08:41:04 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 17 Dec 2016 13:41:04 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
Message-ID: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>


New submission from woo yoo:

Per the documentation,"The alternate form causes a leading octal specifier ('0o') to be inserted before the first digit", However the actual behavior didn't conform to the principle.

Code:
>>>b'%#07o' % 34

Output: b'0000o42'

----------
assignee: docs at python
components: Documentation
messages: 283485
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Not matched behavior within printf style bytes formatting
versions: Python 3.5

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

From report at bugs.python.org  Sat Dec 17 08:41:41 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 17 Dec 2016 13:41:41 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481982101.39.0.386426568393.issue29000@psf.upfronthosting.co.za>


woo yoo added the comment:

The link is https://docs.python.org/3.5/library/stdtypes.html#printf-style-bytes-formatting

----------

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

From report at bugs.python.org  Sat Dec 17 09:13:28 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 14:13:28 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
In-Reply-To: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>
Message-ID: <1481984008.62.0.0398042168525.issue28951@psf.upfronthosting.co.za>


R. David Murray added the comment:

Making a 'flags' subheading in module contents would be reasonable.  Alternatively we could just drop that parenthetical, since the descriptions for each flag are themselves cross-linked.

----------

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

From report at bugs.python.org  Sat Dec 17 09:29:46 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 14:29:46 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481984986.28.0.8449775426.issue29000@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documentation matches the behavior.  In this context "the first digit" is the 4.  The leading zeros are the pad fill.  Now, whether this is *useful* behavior or not is a separate question :)  And yes, the docs could be clarified on this point either way.

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

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

From report at bugs.python.org  Sat Dec 17 09:37:49 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 17 Dec 2016 14:37:49 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481985469.4.0.791325274007.issue29000@psf.upfronthosting.co.za>


woo yoo added the comment:

Make a slight change to my code, which becomes `b'%#07x' % 34`, the weird situation appears.

----------

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

From report at bugs.python.org  Sat Dec 17 10:18:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 15:18:22 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481987902.1.0.551264145122.issue29000@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not documentation issue, but a bug in formatting octals in bytes.

>>> '%#07x' % 123
'0x0007b'
>>> b'%#07x' % 123
b'0x0007b'
>>> '%#07o' % 123
'0o00173'
>>> b'%#07o' % 123
b'000o173'
     ^

----------
components: +Interpreter Core -Documentation
nosy: +ethan.furman, serhiy.storchaka
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Dec 17 10:25:56 2016
From: report at bugs.python.org (kevin)
Date: Sat, 17 Dec 2016 15:25:56 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
In-Reply-To: <1481984008.62.0.0398042168525.issue28951@psf.upfronthosting.co.za>
Message-ID: <CAGVXcSZ4SOPCtDrR7jWGDg-Q-A3njmZ862qoELYvtdq=xCNEZA@mail.gmail.com>


kevin added the comment:

Well, my original problem is that I wanted to find out what the flags did
and could not find any pointer in the table of contents.  I think they
deserve either really good cross-references, or a heading in the contents.
And a non-confusing alphabetized list, if they're going to be mixed in with
other module contents.

On Sat, Dec 17, 2016 at 6:13 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Making a 'flags' subheading in module contents would be reasonable.
> Alternatively we could just drop that parenthetical, since the descriptions
> for each flag are themselves cross-linked.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28951>
> _______________________________________
>

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

----------
Added file: http://bugs.python.org/file45940/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20161217/64c0b987/attachment.gif>

From report at bugs.python.org  Sat Dec 17 10:29:15 2016
From: report at bugs.python.org (kevin)
Date: Sat, 17 Dec 2016 15:29:15 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
In-Reply-To: <1481984008.62.0.0398042168525.issue28951@psf.upfronthosting.co.za>
Message-ID: <CAGVXcSYrabTXbVTPNCupWXH6+Xi2VaOTJ7nwvu0aVC0McF5RoA@mail.gmail.com>


kevin added the comment:

Oh, and on the alphabetized list, I suggest NOT listing synonyms together,
but just mark some as "synonym for X" and listing them all alphabetically
(according to "en" collation, not "C" so upper- and lower-case sort
together, not separately).

On Sat, Dec 17, 2016 at 6:13 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Making a 'flags' subheading in module contents would be reasonable.
> Alternatively we could just drop that parenthetical, since the descriptions
> for each flag are themselves cross-linked.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28951>
> _______________________________________
>

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

----------
Added file: http://bugs.python.org/file45941/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20161217/fd218635/attachment.gif>

From report at bugs.python.org  Sat Dec 17 11:26:25 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 17 Dec 2016 16:26:25 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481991985.84.0.715419674588.issue28972@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm neutral on this idea.  I would much rather focus on making sure that the various modules (such as pdb or tarfile) which have useful command-line functionality document that clearly and uniformly, but as part of each module's library docs.

I don't think that a list of all modules that have such behavior really belongs in the stdlib docs, but if someone wants to add it and keep it up to date I won't object.  Just understand that whatever is documented must preserve some sort of backwards compatibility.  And don't repeat the same information in two places.

Maybe the blog post that started this is actually enough?  Or if something more official is needed, perhaps a how-to document?

----------

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

From report at bugs.python.org  Sat Dec 17 11:27:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 16:27:23 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481992043.68.0.745969906681.issue29000@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes this inconsistency.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45943/bytes-format-oct-alt-zero.patch

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

From report at bugs.python.org  Sat Dec 17 13:06:35 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 18:06:35 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481997995.75.0.300778227315.issue29000@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, that makes sense.  Patch looks good to me.

----------

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

From report at bugs.python.org  Sat Dec 17 13:15:25 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 18:15:25 +0000
Subject: [docs] [issue28951] re.flags not documented in Module Contents as
 promised.
In-Reply-To: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>
Message-ID: <1481998525.46.0.531625757926.issue28951@psf.upfronthosting.co.za>


R. David Murray added the comment:

(Please delete the message you are replying to when responding to bug tracker emails.)

I think a section heading would be good (three subheads under module contents: functions, flags, and exceptions).  I'm less in favor of alphabetical entries for synonyms.  We'll see what others think.

----------

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

From report at bugs.python.org  Sat Dec 17 14:13:03 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Dec 2016 19:13:03 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1482001983.78.0.118207427756.issue28816@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The cutoff for 3.6.0 has passed, but documentation patches can still go in for 3.6.1 (and 3.5.3).

----------

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

From report at bugs.python.org  Sat Dec 17 15:16:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2016 20:16:48 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <20161217201645.31922.71238.2EB1645D@psf.io>


Roundup Robot added the comment:

New changeset 96d728c14267 by Serhiy Storchaka in branch '3.5':
Issue #29000: Fixed bytes formatting of octals with zero padding in alternate
https://hg.python.org/cpython/rev/96d728c14267

New changeset 29c9c414c310 by Serhiy Storchaka in branch '3.6':
Issue #29000: Fixed bytes formatting of octals with zero padding in alternate
https://hg.python.org/cpython/rev/29c9c414c310

New changeset 4e55e011dd80 by Serhiy Storchaka in branch 'default':
Issue #29000: Fixed bytes formatting of octals with zero padding in alternate
https://hg.python.org/cpython/rev/4e55e011dd80

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

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

From report at bugs.python.org  Sat Dec 17 15:18:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 20:18:12 +0000
Subject: [docs] [issue29000] Not matched behavior within printf style bytes
 formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1482005892.52.0.365645735998.issue29000@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks David.

----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Dec 17 18:53:44 2016
From: report at bugs.python.org (Alex Jurkiewicz)
Date: Sat, 17 Dec 2016 23:53:44 +0000
Subject: [docs] [issue29002] typing.AnyStr doc is unclear about python2
 unicode support
Message-ID: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>


New submission from Alex Jurkiewicz:

The typing.AnyStr documentation:

https://docs.python.org/3/library/typing.html#typing.AnyStr

It gives some examples using u-strings (u'foo') but doesn't make explicit some subtleties about behaviour with Python 2. Specifically, with Python 2 all the given examples work, and even this works:

concat("foo", u"bar")

Which seems contrary to the goal of AnyStr being "used for functions that may accept any kind of string without allowing different kinds of strings to mix".

I think the documentation should call out that for Python 2, AnyStr doesn't distinguish between str & unicode, and mention that in python 2, b'str' is equivalent to 'str' (I know this is mentioned elsewhere, but it seems useful to repeat it here).

----------
assignee: docs at python
components: Documentation
messages: 283524
nosy: aj, docs at python
priority: normal
severity: normal
status: open
title: typing.AnyStr doc is unclear about python2 unicode support
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Dec 17 20:11:03 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 01:11:03 +0000
Subject: [docs] [issue29002] typing.AnyStr doc is unclear about python2
 unicode support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1482023462.98.0.329820773574.issue29002@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

The ``typing`` module doesn't exist in Python 2.7. 

All code samples provided in the docs *work* since no type-checking is performed by Python. That is, no enforcing of the types provided is made, that's for 3rd party packages to supply.

----------
nosy: +Jim Fasarakis-Hilliard

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

From report at bugs.python.org  Sat Dec 17 20:33:52 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 01:33:52 +0000
Subject: [docs] [issue29002] typing.AnyStr doc is unclear about python2
 unicode support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1482024832.3.0.0920687006221.issue29002@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Unless of course you mean pip installing typing for Py2 and then using ``# type``  comments to provide the types. 

Even in that case, I don't really think the documentation for Python 3.5 should be mentioning types in 2.7, that'd get confusing.

----------

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

From report at bugs.python.org  Sun Dec 18 00:17:12 2016
From: report at bugs.python.org (Miki Tebeka)
Date: Sun, 18 Dec 2016 05:17:12 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1482038232.81.0.348857817685.issue28972@psf.upfronthosting.co.za>


Miki Tebeka added the comment:

Thanks Guido, however I think my blog is not the right place - it's dog ugly and read by about 7 people on a good day :) 

I think that adding this to the official docs will add to the "batteries included" motto. I'll try to find a time and come up with a patch to the docs, however if this goes through we should place a note somewhere in the development docs about updating this section as well if someone adds a __main__.py or main function.

----------

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

From report at bugs.python.org  Sun Dec 18 00:43:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2016 05:43:55 +0000
Subject: [docs] [issue28987] Remove typo in whats new entry on Descriptor
 Protocol Enhancements
In-Reply-To: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>
Message-ID: <20161218054352.11104.85476.A0BC4ECE@psf.io>


Roundup Robot added the comment:

New changeset a46a20a1f286 by Martin Panter in branch '3.6':
Issue #28987: Typos, grammar, spelling in documentation
https://hg.python.org/cpython/rev/a46a20a1f286

New changeset 28cf4ffcfbf3 by Martin Panter in branch 'default':
Issue #28987: Merge doc and comment fixes from 3.6
https://hg.python.org/cpython/rev/28cf4ffcfbf3

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

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

From report at bugs.python.org  Sun Dec 18 00:51:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 05:51:29 +0000
Subject: [docs] [issue28987] Remove typo in whats new entry on Descriptor
 Protocol Enhancements
In-Reply-To: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>
Message-ID: <1482040289.45.0.762871041844.issue28987@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Jim

----------
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.7

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

From report at bugs.python.org  Sun Dec 18 05:52:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 10:52:31 +0000
Subject: [docs] [issue29004] binascii.crc_hqx() implements CRC-CCITT
Message-ID: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>


New submission from Martin Panter:

If I had known this it would have saved me getting a separate implementation working.

>>> hex(binascii.crc_hqx(b"\x01", 0))
'0x1021'
https://files.stairways.com/other/binhex-40-specs-info.txt

Documenting this might helped many other people. Top Google hits seem oblivious to crc_hqx(), using other CRC implementations, and even other helper functions from the binascii module:

https://pypi.python.org/pypi/crc16
http://stackoverflow.com/questions/26204060/calculate-crc-ccitt-0xffff-for-hex-string

----------
assignee: docs at python
components: Documentation
files: crc-ccitt.patch
keywords: patch
messages: 283548
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: binascii.crc_hqx() implements CRC-CCITT
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45952/crc-ccitt.patch

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

From report at bugs.python.org  Sun Dec 18 06:13:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 11:13:12 +0000
Subject: [docs] [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482059592.43.0.445617832898.issue29004@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If document the polynomial for crc_hqx, maybe document it for crc32 and adler32?

Wouldn't be better to write the formula as *x*\ :sup:`16` + *x*\ :sup:`12 + *x*\ :sup:`5` + 1 ?

----------
nosy: +eric.smith, lemburg, mark.dickinson, serhiy.storchaka, stutzbach

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

From report at bugs.python.org  Sun Dec 18 06:47:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 11:47:52 +0000
Subject: [docs] [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482061672.93.0.199568145867.issue29004@psf.upfronthosting.co.za>


Martin Panter added the comment:

It seems I can write it without the escaped spaces. Is there a problem with this:

*x*:sup:`16` + *x*:sup:`12` + *x*:sup:`5` + 1

I?m happy to add the CRC-32 polynomial if you think it would be useful, although it is a lot longer (fifteen terms instead of four). And this CRC is already easily identified by the CRC-32 name. As well as the polynomial, there are other details that identify a CRC. The bits in CRC-32 are reversed and inverted compared to CRC-CCITT.

>>> hex(crc32(b"\x80", 0xFFFFFFFF) ^ 0xFFFFFFFF)
'0xedb88320'
# 0xEDB88320 is the reversed polynomial representation; the x^0 term corresponds to bit 31

Adler32 is not a CRC, and I don?t think there are multiple versions of the algorithm, so I don?t think it would need any special explanation.

----------

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

From report at bugs.python.org  Sun Dec 18 06:53:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 11:53:12 +0000
Subject: [docs] [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482061991.98.0.655491883555.issue29004@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Okay, then the patch LGTM. Use the form of the polynomial that you prefer.

----------

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

From report at bugs.python.org  Sun Dec 18 10:50:13 2016
From: report at bugs.python.org (woo yoo)
Date: Sun, 18 Dec 2016 15:50:13 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
Message-ID: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>


New submission from woo yoo:

"In general, calling a method with a list of n arguments is equivalent to calling the corresponding function with an argument list that is created by inserting the method?s object before the first argument."

Is  above description right?
The link is https://docs.python.org/3.5/tutorial/classes.html#method-objects

----------
assignee: docs at python
components: Documentation
messages: 283556
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Possibly incorrect description about method objects
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Dec 18 11:10:56 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 16:10:56 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482077456.79.0.331744070263.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Seems right to me, this is also stated clearly in the reference manual:

> When an instance method object is called, the underlying function (__func__) is called, inserting the class instance (__self__) in front of the argument list. For instance, when C is a class which contains a definition for a function f(), and x is an instance of C, calling x.f(1) is equivalent to calling C.f(x, 1).

What doesn't look right to you?

----------
nosy: +Jim Fasarakis-Hilliard

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

From report at bugs.python.org  Sun Dec 18 11:15:28 2016
From: report at bugs.python.org (woo yoo)
Date: Sun, 18 Dec 2016 16:15:28 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482077728.58.0.301063103024.issue29005@psf.upfronthosting.co.za>


woo yoo added the comment:

Maybe the last "method's" should be changed into "class instance"

----------

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

From report at bugs.python.org  Sun Dec 18 11:22:52 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 16:22:52 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482078172.44.0.703310412691.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I see. I'd agree that `instance object` is probably better here. Let's see what others think.

----------

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

From report at bugs.python.org  Sun Dec 18 11:25:55 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 16:25:55 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482078355.67.0.120394147896.issue29005@psf.upfronthosting.co.za>


R. David Murray added the comment:

Given the (clearer) explanation in the final paragraph of that section, I think the bare 'object' in the first couple paragraphs should be replaced by 'instance object'.  There are multiple objects involved, and that will disambiguate which one is being referred to for insertion as the first argument, and make the language of the section self-consistent.

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

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

From report at bugs.python.org  Sun Dec 18 12:10:12 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 17:10:12 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482081012.12.0.736980523559.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I've added a little patch that takes care of this. I didn't add "method's instance object" in the second substitution because it seems evident by the previous sentences.

----------
keywords: +patch
Added file: http://bugs.python.org/file45955/method_obj35.patch

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

From report at bugs.python.org  Sun Dec 18 14:31:32 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 19:31:32 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482089492.86.0.176610438261.issue29005@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it is better to say "the method's instance object", because in the final paragraph we discuss the fact that each method object has an associated instance object.  The instance object isn't magically acquired from elsewhere and added, it is added because it has been bound into the method object.

----------

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

From report at bugs.python.org  Sun Dec 18 14:49:26 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 19:49:26 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482090566.21.0.966092961613.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Agreed, attached amended patch

----------
Added file: http://bugs.python.org/file45957/method_obj35_2.patch

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

From report at bugs.python.org  Sun Dec 18 15:03:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2016 20:03:05 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <20161218200259.11104.13217.ECA131F0@psf.io>


Roundup Robot added the comment:

New changeset 6f89f5eb4422 by R David Murray in branch '3.5':
#29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/6f89f5eb4422

New changeset 7314e08dc907 by R David Murray in branch '3.6':
Merge: #29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/7314e08dc907

New changeset 3cc193be79ab by R David Murray in branch 'default':
Merge: #29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/3cc193be79ab

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

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

From report at bugs.python.org  Sun Dec 18 15:04:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 20:04:09 +0000
Subject: [docs] [issue29005] Possibly incorrect description about method
 objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482091449.41.0.933683720254.issue29005@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, woo and Jim.

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

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

From report at bugs.python.org  Sun Dec 18 23:30:59 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 04:30:59 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
Message-ID: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The sentence:

"Note that Py_EQ and Py_NE comparisons can cause a UnicodeWarning in case the conversion of the arguments to Unicode fails with a UnicodeDecodeError."

in the doc of PyUnicode_RichCompare is not true in 3.x. Proposed patch simply deletes it.

----------
assignee: docs at python
components: Documentation
files: doc-of-PyUnicode_RichCompare.patch
keywords: patch
messages: 283578
nosy: docs at python, haypo, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Outdated part in the doc of PyUnicode_RichCompare
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45960/doc-of-PyUnicode_RichCompare.patch

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

From report at bugs.python.org  Sun Dec 18 23:46:18 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 04:46:18 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482122778.61.0.0824941212553.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

The associated link is https://docs.python.org/3.6/tutorial/classes.html#inheritance

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Dec 19 00:43:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 05:43:13 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482126193.54.0.953651227033.issue29009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This sentence also is in the header.

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

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

From report at bugs.python.org  Mon Dec 19 01:08:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 06:08:56 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482127735.99.0.909701841181.issue29009@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> This sentence also is in the header.

Ohh, yes. Thanks Serhiy!

----------
Added file: http://bugs.python.org/file45961/doc-of-PyUnicode_RichCompare_v2.patch

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

From report at bugs.python.org  Mon Dec 19 01:10:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 06:10:37 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482127837.79.0.900977792673.issue29009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee: docs at python -> xiang.zhang
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Dec 19 03:00:07 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 19 Dec 2016 08:00:07 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
Message-ID: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

The following statement is in the Language Reference for Custom classes:

>  __bases__ is a tuple (possibly empty or a singleton) containing the base classes

AFAIK, ``object.__bases__`` is the only object for which ``__bases__`` is empty and it isn't a *custom* class. Attempts to create a class and assign __bases__ to an empty tuple is checked to enforce inheritance from ``object``. This *seems* to be something that slipped through when the docs were created for Python 3.0?

I'm curious to see if this can actually be empty, if not, attached patch removes ''empty'' from the sentence.

----------
assignee: docs at python
components: Documentation
files: fixbasesdoc.patch
keywords: patch
messages: 283595
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: __bases__ is a tuple (possibly empty or a singleton)
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45962/fixbasesdoc.patch

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

From report at bugs.python.org  Mon Dec 19 03:38:27 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Mon, 19 Dec 2016 08:38:27 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482136707.41.0.627798222674.issue29010@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Hi. Can you please provide a small code snippet illustrating where this diverges from the actual behaviour?

----------
nosy: +brendan-donegan

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

From report at bugs.python.org  Mon Dec 19 04:04:33 2016
From: report at bugs.python.org (Monte Davidoff)
Date: Mon, 19 Dec 2016 09:04:33 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
Message-ID: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>


New submission from Monte Davidoff:

The documentation for the zipfile module, https://docs.python.org/3.5/library/zipfile.html, contains inconsistent descriptions of the maximum size of a ZIP file when allowZip64 is False.

The second paragraph in the zipfile module documentation states:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that are more than 4 GiB in size)."

Later on, in the description of the zipfile.ZipFile class, it says:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GiB."

The two sizes (4 GiB and 2 GiB) should be the same. According to https://en.wikipedia.org/wiki/Zip_(file_format)#ZIP64, 4 GiB is the correct value.

There is a similar problem in the 2.7.13 documentation, https://docs.python.org/2.7/library/zipfile.html.

----------
assignee: docs at python
components: Documentation
messages: 283597
nosy: docs at python, mndavidoff
priority: normal
severity: normal
status: open
title: zipfile: inconsistent doc for ZIP64 file size
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec 19 05:08:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2016 10:08:12 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482142092.75.0.880056226693.issue29009@psf.upfronthosting.co.za>


STINNER Victor added the comment:

doc-of-PyUnicode_RichCompare_v2.patch LGTM.

----------

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

From report at bugs.python.org  Mon Dec 19 05:43:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 10:43:42 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <20161219104338.21591.24827.34D52F3B@psf.io>


Roundup Robot added the comment:

New changeset 8f5ed2a38f64 by Xiang Zhang in branch '3.5':
Issue #29009: Remove outdated doc of PyUnicode_RichCompare.
https://hg.python.org/cpython/rev/8f5ed2a38f64

New changeset da958d01755a by Xiang Zhang in branch '3.6':
Issue #29009: Merge 3.5.
https://hg.python.org/cpython/rev/da958d01755a

New changeset 9568343fde42 by Xiang Zhang in branch 'default':
Issue #29009: Merge 3.6.
https://hg.python.org/cpython/rev/9568343fde42

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

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

From report at bugs.python.org  Mon Dec 19 05:44:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 10:44:42 +0000
Subject: [docs] [issue29009] Outdated part in the doc of
 PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482144282.6.0.997217520457.issue29009@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


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

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

From report at bugs.python.org  Mon Dec 19 07:04:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 12:04:07 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <1482149047.59.0.546380079739.issue29012@psf.upfronthosting.co.za>


R. David Murray added the comment:

Most likely it just slipped through.  In 2.7 the section is just called 'classes', not 'custom classes', and covered both classic classes and the new style classes that are all that python3 has.

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

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

From report at bugs.python.org  Mon Dec 19 07:05:45 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 12:05:45 +0000
Subject: [docs] [issue28383] __hash__ documentation recommends naive XOR to
 combine but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <1482149145.44.0.158163680897.issue28383@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Mon Dec 19 07:10:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 12:10:39 +0000
Subject: [docs] [issue28383] __hash__ documentation recommends naive XOR to
 combine but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <20161219121036.23338.44186.49A0F422@psf.io>


Roundup Robot added the comment:

New changeset cb802a78ceea by Victor Stinner in branch '3.5':
doc: Suggest to hash(tuple of attr) rather than XOR
https://hg.python.org/cpython/rev/cb802a78ceea

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

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

From report at bugs.python.org  Mon Dec 19 07:16:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 12:16:21 +0000
Subject: [docs] [issue28383] __hash__ documentation recommends naive XOR to
 combine but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <20161219121618.95816.22239.DC0F1292@psf.io>


Roundup Robot added the comment:

New changeset fac2362f248c by Victor Stinner in branch '2.7':
doc: Suggest to hash(tuple of attr) rather than XOR
https://hg.python.org/cpython/rev/fac2362f248c

----------

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

From report at bugs.python.org  Mon Dec 19 07:17:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2016 12:17:11 +0000
Subject: [docs] [issue28383] __hash__ documentation recommends naive XOR to
 combine but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <1482149831.5.0.963449538471.issue28383@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I updated the doc of Python 2.7, 3.5, 3.6 and default (3.7).

Thanks for the suggestion Kevin, thanks for the review Naoki.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 19 08:15:34 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 13:15:34 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482153333.97.0.842302051411.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

Code:
>class A(object):
    pass

'object' is not in the same scope as 'A'

----------

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

From report at bugs.python.org  Mon Dec 19 08:20:45 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 13:20:45 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482153645.33.0.631505871518.issue29010@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is part of the global scope, which contains all other scopes.  (I'm not 100% sure I'm comfortable with that language, but it doesn't seem obviously wrong.)

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

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

From report at bugs.python.org  Mon Dec 19 09:00:50 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 14:00:50 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482156050.93.0.192500713985.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

The previous description about scope classify  it into 3 types explicitly, which means the scope containing the current module's global names is not same as the scope containing built-in names.

----------

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

From report at bugs.python.org  Mon Dec 19 14:03:48 2016
From: report at bugs.python.org (Ettore Atalan)
Date: Mon, 19 Dec 2016 19:03:48 +0000
Subject: [docs] [issue29017] Docs: PySide is provided by 'The Qt Company'
 and not by 'Nokia'
Message-ID: <1482174228.93.0.510062905066.issue29017@psf.upfronthosting.co.za>


New submission from Ettore Atalan:

Regarding
URL: http://docs.python.org/3/library/othergui.html
Section: PySide

PySide is provided by 'The Qt Company' and no longer by 'Nokia' like mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 283646
nosy: Ettore Atalan, docs at python
priority: normal
severity: normal
status: open
title: Docs: PySide is provided by 'The Qt Company' and not by 'Nokia'
versions: Python 3.7

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

From report at bugs.python.org  Mon Dec 19 16:19:44 2016
From: report at bugs.python.org (issuefinder)
Date: Mon, 19 Dec 2016 21:19:44 +0000
Subject: [docs] [issue29018] Misinformation when showing how slices work in
 The Tutorial
Message-ID: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>


New submission from issuefinder:

In this page:
https://docs.python.org/3/tutorial/introduction.html#strings

When showing how slices work:
+---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
-6  -5  -4  -3  -2  -1

The accurate matrix is:

+---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
 0  -6  -5  -4  -3  -2  -1

----------
assignee: docs at python
components: Documentation
messages: 283649
nosy: docs at python, issuefinder
priority: normal
severity: normal
status: open
title: Misinformation when showing how slices work in The Tutorial
versions: Python 3.7

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

From report at bugs.python.org  Mon Dec 19 16:55:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 21:55:01 +0000
Subject: [docs] [issue29018] Misinformation when showing how slices work in
 The Tutorial
In-Reply-To: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>
Message-ID: <1482184501.38.0.180652957352.issue29018@psf.upfronthosting.co.za>


R. David Murray added the comment:

If your version was correct, 'python'[-2:] would produce 'n', which is not what it produces.  Perhaps you being confused by the fact that the diagram is pointing the indexes *between* the characters?  That's the point of the mnemonic and I find it very useful to think of it that way, myself.

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

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

From report at bugs.python.org  Mon Dec 19 18:24:11 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Mon, 19 Dec 2016 23:24:11 +0000
Subject: [docs] [issue21150] Add quick links table to argparse docs
In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za>
Message-ID: <1482189851.75.0.675054426771.issue21150@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hello All,

I would like to help with this issue. I am a beginner. I am attaching a 'SampleOfSummaryTable.PNG' file which I think is one way of organizing summary table.

I think if we put quick links of function parameters in summary table then it will make existing parameter quick links above detailed summary of each parameter as redundant.

Please let me know if this is okay.

----------
nosy: +Gaurav Tatke
Added file: http://bugs.python.org/file45972/SampleOfSummaryTable.PNG

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

From report at bugs.python.org  Mon Dec 19 18:37:31 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 19 Dec 2016 23:37:31 +0000
Subject: [docs] [issue29018] Misinformation when showing how slices work in
 The Tutorial
In-Reply-To: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>
Message-ID: <1482190651.28.0.837724845307.issue29018@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

You haven't given any reason to explain why you think the existing docs are wrong, nor any reason why you think your version is better. Just stating that the docs give "misinformation" is not good enough.

By your matrix, 'Python'[0:-1] should take a slice starting from the left of 'P' and ending at the *right* of 'n', returning 'Python' unchanged. According to the original, documented matrix, 'Python'[0:-1] takes a slice starting at the left of 'P' and ending at the *left* of 'n', returning 'Pytho'. without the n, which is what actually does happen.

You should also consider the slice 'Python'[-6:-5] according to the documented matrix (returns 'P') and your matrix (returns 'y').

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec 19 22:48:15 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 20 Dec 2016 03:48:15 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482205695.46.0.515084664573.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

If i was wrong about this issue, please tell me.

----------

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

From report at bugs.python.org  Mon Dec 19 23:38:29 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 20 Dec 2016 04:38:29 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482205695.46.0.515084664573.issue29010@psf.upfronthosting.co.za>
Message-ID: <CAESAk0gCXmofCNYcSuwOLq_nk1A4QOc2c+02L5h_n_UO41BZ5g@mail.gmail.com>


Brendan Donegan added the comment:

IMO there's no actual bug in Python. Perhaps documentation can be clarified
in a short simple way. I would reiterate the point that restating facts of
the language all over the documentation is not a great idea, but maybe here
the benefits outweigh the drawbacks.

Anyway I think the bug is clear now (it's a docs issue if anything) so I'd
leave it open until someone offers a patch or a strong argument why it
shouldn't be clarified.

On Tue, 20 Dec 2016 at 09:18 woo yoo <report at bugs.python.org> wrote:

>
> woo yoo added the comment:
>
> If i was wrong about this issue, please tell me.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29010>
> _______________________________________
>

----------
nosy: +brendand

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

From report at bugs.python.org  Tue Dec 20 00:18:29 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 20 Dec 2016 05:18:29 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482211109.51.0.120707397408.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

I agree with you

----------

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

From report at bugs.python.org  Tue Dec 20 07:46:14 2016
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Tue, 20 Dec 2016 12:46:14 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
Message-ID: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>


New submission from Jakub Mateusz Kowalski:

In https://docs.python.org/2/library/random.html#random.seed I can find that "If a hashable object is given, deterministic results are only assured when PYTHONHASHSEED is disabled."

Both int and long are hashable. However, tests on the random module as well as C source code of random_seed (as indicated in http://stackoverflow.com/a/41228062/4879688) suggest that behaviour of the module is deterministic when seeded with an integer.

----------
assignee: docs at python
components: Documentation
messages: 283686
nosy: Jakub.Mateusz.Kowalski, docs at python
priority: normal
severity: normal
status: open
title: Results of random.seed() call with integer argument should be claimed deterministic.
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 20 07:46:36 2016
From: report at bugs.python.org (Alexander Taylor)
Date: Tue, 20 Dec 2016 12:46:36 +0000
Subject: [docs] [issue29024] Add Kivy entry to Graphic User Interface FAQ
Message-ID: <1482237996.79.0.832903364974.issue29024@psf.upfronthosting.co.za>


Changes by Alexander Taylor <alexanderjohntaylor at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: gui_faq_kivy.patch
keywords: patch
nosy: docs at python, inclement
priority: normal
severity: normal
status: open
title: Add Kivy entry to Graphic User Interface FAQ
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45975/gui_faq_kivy.patch

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

From report at bugs.python.org  Tue Dec 20 07:55:58 2016
From: report at bugs.python.org (Alexander Taylor)
Date: Tue, 20 Dec 2016 12:55:58 +0000
Subject: [docs] [issue29024] Add Kivy entry to Graphic User Interface FAQ
Message-ID: <1482238558.2.0.148868956879.issue29024@psf.upfronthosting.co.za>


Changes by Alexander Taylor <alexanderjohntaylor at gmail.com>:


----------
type: enhancement -> 

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

From report at bugs.python.org  Tue Dec 20 08:07:17 2016
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Tue, 20 Dec 2016 13:07:17 +0000
Subject: [docs] [issue29025] random.seed() relation to hash() function and
 its determinism is vague
Message-ID: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>


New submission from Jakub Mateusz Kowalski:

2.7 (https://docs.python.org/2/library/random.html#random.seed)
- warning about PYTHONHASHSEED (environmental variable) voiding determinism
- no warning on -R interpreter switch 
- relation to hash() function omitted

2.6 (https://docs.python.org/2.6/library/random.html#random.seed)
3.0 (https://docs.python.org/3.0/library/random.html#random.seed)
3.1 (https://docs.python.org/3.1/library/random.html#random.seed)
3.2 (https://docs.python.org/3.2/library/random.html#random.seed)
3.3 (https://docs.python.org/3.3/library/random.html#random.seed)
3.4 (https://docs.python.org/3.4/library/random.html#random.seed)
- no warning about PYTHONHASHSEED nor -R switch
- relation to hash() function acknowledged

3.5 (https://docs.python.org/3.5/library/random.html#random.seed)
3.6 (https://docs.python.org/3.6/library/random.html#random.seed)
3.7 (https://docs.python.org/3.7/library/random.html#random.seed)
- no warning about PYTHONHASHSEED nor -R switch
- relation to hash() function omitted

----------
assignee: docs at python
components: Documentation
messages: 283688
nosy: Jakub.Mateusz.Kowalski, docs at python
priority: normal
severity: normal
status: open
title: random.seed() relation to hash() function and its determinism is vague
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Dec 20 09:24:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2016 14:24:49 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
Message-ID: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The documentation of the time.time() mentions "epoch" which it doesn't define epoch. If I recall correctly, it's January 1st, 1970 on most OS and most implementations of Python, except of IronPython which uses a different epoch.

https://docs.python.org/dev/library/time.html#time.time

Moreover, the timezone is not defined. In practice, it's UTC, so it would be nice to document it.

I opened this issue because I wasn't sure if time.time() is impacted by DST or not. The answer is no. Maybe the behaviour of time.time() on DST should also be documentation. Hint: it is not impacted by DST since it uses UTC timezone.

Related question on StackOverflow:
http://stackoverflow.com/questions/32469318/python-time-time-and-daylight-saving-time

----------
assignee: docs at python
components: Documentation
messages: 283690
nosy: belopolsky, docs at python, haypo
priority: normal
severity: normal
status: open
title: time.time() documentation should mention UTC timezone
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Dec 20 09:35:15 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Dec 2016 14:35:15 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482244515.38.0.932240012738.issue29010@psf.upfronthosting.co.za>


R. David Murray added the comment:

Would it make it clearer if we said "BaseClassName must be defined in a namespace accessible from the scope containing the dervied class definition" ?

----------

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

From report at bugs.python.org  Tue Dec 20 09:49:45 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 20 Dec 2016 14:49:45 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482245385.3.0.37584893708.issue29010@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Worth putting them side by side I think:

"The name BaseClassName must be defined in a scope containing the derived class definition"

vs.

"BaseClassName must be defined in a namespace accessible from the scope containing the derived class definition"

----------

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

From report at bugs.python.org  Tue Dec 20 09:57:49 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 20 Dec 2016 14:57:49 +0000
Subject: [docs] [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482245869.85.0.426476506906.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

As for me, i prefer the new description, which is clear and easy to understand.

----------

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

From report at bugs.python.org  Tue Dec 20 09:59:11 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 20 Dec 2016 14:59:11 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482245951.77.0.511380281359.issue29026@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

time.time() is not quite UTC on Unix: it usually (*) doesn't include leap seconds, which UTC does.

The Wikipedia page has a good definition and explanation:

https://en.wikipedia.org/wiki/Unix_time

(*) "usually" because POSIX defines time() to not include leap seconds, but on some older or not quite POSIX compliant Unix systems, leap seconds are included.

----------
nosy: +lemburg

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

From report at bugs.python.org  Tue Dec 20 10:07:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2016 15:07:03 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482246423.72.0.28698303419.issue29026@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> time.time() is not quite UTC on Unix

Handling time is a complex task, so we should enhance the doc to help users.

If there are multiple cases, we can list them: "time.time() uses UTC timezone with or without leap seconds". Maybe with a link to https://en.wikipedia.org/wiki/Unix_time ?

----------

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

From report at bugs.python.org  Wed Dec 21 01:41:35 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Dec 2016 06:41:35 +0000
Subject: [docs] [issue29025] random.seed() relation to hash() function and
 its determinism is vague
In-Reply-To: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>
Message-ID: <1482302495.07.0.545718786563.issue29025@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In Python 3.5 and Python 3.6, this is already fixed (decoupled from PYTHONHASHSEED).  In Python 2.7, I could backport the fix, add a note to the docs, or just let it be (since seeding is turned off by default).  The other versions of Python are already inactive.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Wed Dec 21 04:08:52 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:08:52 +0000
Subject: [docs] [issue29032] How does the __self__ attribute of method
 become a class rather a instance?
Message-ID: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>


New submission from woo yoo:

The documentation of instance methods confused me, it classifies methods into two types:the one is retrieved by an instance of a class, the other is created by retrieving a method from a class or instance.

According to the description,

>When an instance method object is created by retrieving a class method >object from a class or instance, its __self__ attribute is the class >itself, and its __func__ attribute is the function object underlying the >class method.

the  __self__ attribute of the more complex methods is a class. How does this happen? Is this description incorrect?

----------
assignee: docs at python
components: Documentation
messages: 283724
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: How does the __self__ attribute of method become a class rather a instance?
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Dec 21 04:12:09 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:12:09 +0000
Subject: [docs] [issue29032] How does the __self__ attribute of method
 become a class rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482311529.74.0.67803459911.issue29032@psf.upfronthosting.co.za>


woo yoo added the comment:

The quotation section :

When an instance method object is created by retrieving a class method object from a class or instance, its __self__ attribute is the class itself, and its __func__ attribute is the function object underlying the class method.

The associated link is https://docs.python.org/3.6/reference/datamodel.html#the-standard-type-hierarchy ,which lies in the 'instance mthods' section.

----------

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

From report at bugs.python.org  Wed Dec 21 04:17:36 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:17:36 +0000
Subject: [docs] [issue29032] How does the __self__ attribute of method
 become a class rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482311856.47.0.463442690867.issue29032@psf.upfronthosting.co.za>


woo yoo added the comment:

Not a bug,sorry to bother

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

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

From report at bugs.python.org  Wed Dec 21 04:23:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 09:23:16 +0000
Subject: [docs] [issue29032] How does the __self__ attribute of method
 become a class rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482312196.31.0.955108757496.issue29032@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The description looks correct to me. Note that it says about class methods.

>>> class A:
...     @classmethod
...     def f(cls): pass
... 
>>> a = A()
>>> A.f
<bound method A.f of <class '__main__.A'>>
>>> A.f.__self__
<class '__main__.A'>
>>> a.f
<bound method A.f of <class '__main__.A'>>
>>> a.f.__self__
<class '__main__.A'>

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved

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

From report at bugs.python.org  Wed Dec 21 04:36:01 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:36:01 +0000
Subject: [docs] [issue29032] How does the __self__ attribute of method
 become a class rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482312961.3.0.0843487413475.issue29032@psf.upfronthosting.co.za>


woo yoo added the comment:

Thanks for your reply.

----------

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

From report at bugs.python.org  Wed Dec 21 06:48:02 2016
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Wed, 21 Dec 2016 11:48:02 +0000
Subject: [docs] [issue29025] random.seed() relation to hash() function and
 its determinism is vague
In-Reply-To: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>
Message-ID: <1482320882.14.0.620513370827.issue29025@psf.upfronthosting.co.za>


Jakub Mateusz Kowalski added the comment:

Python 2.7
I think note to the docs is enough.

Python 3.5+
I have a doubt. Isn't .seed(a, version=1) still coupled with PYTHONHASHSEED? The manual says version 1 is "reproducing random sequences from older versions of Python", and for 3.1 (and earlier) hash() is used, which (according to the manual) depends on PYTHONHASHSEED. Also, in Python 3.2-3.4 it is stated explicitly, that hash() is used.

----------

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

From report at bugs.python.org  Wed Dec 21 14:35:42 2016
From: report at bugs.python.org (Daniel Bolgheroni)
Date: Wed, 21 Dec 2016 19:35:42 +0000
Subject: [docs] [issue29038] Duplicate entry for SSLContext.get_ca_certs()
 in ssl
Message-ID: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>


New submission from Daniel Bolgheroni:

There is a duplicate entry for SSLContext.get_ca_certs() in ssl section 17.3.3. They are not equal, and the one that appears first has a more detailed description.

----------
assignee: docs at python
components: Documentation
messages: 283775
nosy: dbolgheroni, docs at python
priority: normal
severity: normal
status: open
title: Duplicate entry for SSLContext.get_ca_certs() in ssl
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 21 22:45:17 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 03:45:17 +0000
Subject: [docs] [issue29038] Duplicate entry for SSLContext.get_ca_certs()
 in ssl
In-Reply-To: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>
Message-ID: <1482378316.91.0.176880832413.issue29038@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The codes in py2.7 looks same as in py3.4+, so make the doc same as in py3.4+.

----------
keywords: +patch
nosy: +christian.heimes, xiang.zhang
stage:  -> patch review
Added file: http://bugs.python.org/file45995/duplicate-doc-entry.patch

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

From report at bugs.python.org  Thu Dec 22 01:06:20 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 06:06:20 +0000
Subject: [docs] [issue29045] Outdated C api doc about Windows error
Message-ID: <1482386780.7.0.302567843382.issue29045@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

https://docs.python.org/3.7/c-api/exceptions.html#c.PyErr_SetFromWindowsErrWithFilename it stills refers to PyErr_SetFromWindowsErrWithFilenameObject but this function doesn't exist since Py3.4. I didn't find when and why it's deleted.

And https://docs.python.org/3.4/c-api/exceptions.html#c.PyErr_SetFromWindowsErr raises OSError instead of WindowsError.

----------
assignee: docs at python
components: Documentation
messages: 283814
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Outdated C api doc about Windows error
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec 22 02:10:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 22 Dec 2016 07:10:46 +0000
Subject: [docs] [issue29045] Outdated C api doc about Windows error
In-Reply-To: <1482386780.7.0.302567843382.issue29045@psf.upfronthosting.co.za>
Message-ID: <1482390646.57.0.586885065545.issue29045@psf.upfronthosting.co.za>


Eryk Sun added the comment:

PyErr_SetFromWindowsErrWithFilenameObject was never implemented. See issue 11210.

Since 3.3 WindowsError is simply an alias for OSError. See PEP 3151.

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

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

From report at bugs.python.org  Thu Dec 22 02:24:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 07:24:32 +0000
Subject: [docs] [issue29045] Outdated C api doc about Windows error
In-Reply-To: <1482386780.7.0.302567843382.issue29045@psf.upfronthosting.co.za>
Message-ID: <1482391472.08.0.879466461239.issue29045@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> PyErr_SetFromWindowsErrWithFilenameObject was never implemented. See issue 11210.

> Since 3.3 WindowsError is simply an alias for OSError. See PEP 3151.

Ohh, thanks for the info. I don't find the implementation in 2.7 either.

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

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

From report at bugs.python.org  Thu Dec 22 05:44:26 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 10:44:26 +0000
Subject: [docs] [issue29046] Coverage related documentation missing
Message-ID: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>


New submission from Patrik Iselind:

Is it possible to do coverage -j8 or similar? Cannot find any documentation on this. Coverage takes so long on the tests...

I checked https://docs.python.org/devguide/coverage.html

----------
assignee: docs at python
components: Documentation
messages: 283824
nosy: docs at python, patriki
priority: normal
severity: normal
status: open
title: Coverage related documentation missing
versions: Python 3.7

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

From report at bugs.python.org  Thu Dec 22 05:44:33 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 10:44:33 +0000
Subject: [docs] [issue29047] Where are the test results stored?
Message-ID: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>


New submission from Patrik Iselind:

I cannot find any documentation on where the test results are stored.

Looked at https://docs.python.org/devguide/runtests.html

----------
assignee: docs at python
components: Documentation
messages: 283825
nosy: docs at python, patriki
priority: normal
severity: normal
status: open
title: Where are the test results stored?
versions: Python 3.7

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

From report at bugs.python.org  Thu Dec 22 06:48:50 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 22 Dec 2016 11:48:50 +0000
Subject: [docs] [issue29046] Coverage related documentation missing
In-Reply-To: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>
Message-ID: <1482407330.29.0.127730116972.issue29046@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

The ``-j`` arguments isn't present for coverage from what I know.

What you can do is build coverage's C extension. That results in a pretty significant change in overall execution time. 

For information about coverage.py you should also look in the docs for it; you can forward any questions about its usage from there (see: http://coverage.readthedocs.io/en/coverage-4.2/#getting-help)

----------
nosy: +Jim Fasarakis-Hilliard

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

From report at bugs.python.org  Thu Dec 22 06:50:43 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 22 Dec 2016 11:50:43 +0000
Subject: [docs] [issue29046] Coverage related documentation missing
In-Reply-To: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>
Message-ID: <1482407443.74.0.577956365388.issue29046@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I suggest this issue be closed as it isn't really an omission, I don't think we should expect the devguide to document *all* of coverage's options. That's what its dedicated docs are for.

----------

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

From report at bugs.python.org  Thu Dec 22 06:56:44 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 11:56:44 +0000
Subject: [docs] [issue29046] Coverage related documentation missing
In-Reply-To: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>
Message-ID: <1482407804.24.0.0175043879585.issue29046@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Agree

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

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

From report at bugs.python.org  Thu Dec 22 08:22:27 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Dec 2016 13:22:27 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482412947.57.0.0148402854966.issue29047@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's because tests results aren't stored anywhere.  The stdio output is the only output the tests produce.

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

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

From report at bugs.python.org  Thu Dec 22 08:44:48 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 13:44:48 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482414288.92.0.415165723574.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Is this something we could clarify in the docs?

I'd like to try and dip my toes in this.

Where can i find the source for
https://docs.python.org/devguide/runtests.html
?

----------

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

From report at bugs.python.org  Thu Dec 22 09:01:59 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Dec 2016 14:01:59 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482415319.39.0.714470748883.issue29047@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

https://github.com/python/devguide/blob/github/runtests.rst

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Dec 22 09:15:21 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 14:15:21 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482415319.39.0.714470748883.issue29047@psf.upfronthosting.co.za>
Message-ID: <CANzOjBg6w9JxN-GjW7UUYG+fFTV+oHB4TV59iJ6QFWawQQOfTQ@mail.gmail.com>


Patrik Iselind added the comment:

Great, thanks!

Patrik

Den 22 dec 2016 15:01 skrev "Eric V. Smith" <report at bugs.python.org>:

>
> Eric V. Smith added the comment:
>
> https://github.com/python/devguide/blob/github/runtests.rst
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29047>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Dec 22 09:54:54 2016
From: report at bugs.python.org (Eric Appelt)
Date: Thu, 22 Dec 2016 14:54:54 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482418493.92.0.280819664741.issue29026@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I would be happy to work on a documentation patch for this - I'll try to have something up by tomorrow evening if no one beats me to it.

----------
nosy: +Eric Appelt

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

From report at bugs.python.org  Thu Dec 22 17:47:25 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Dec 2016 22:47:25 +0000
Subject: [docs] [issue29002] typing.AnyStr doc is unclear about python2
 unicode support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1482446845.6.0.0217174535409.issue29002@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

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

From report at bugs.python.org  Thu Dec 22 22:15:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2016 03:15:20 +0000
Subject: [docs] [issue29038] Duplicate entry for SSLContext.get_ca_certs()
 in ssl
In-Reply-To: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>
Message-ID: <20161223031516.20560.90496.A6222F44@psf.io>


Roundup Robot added the comment:

New changeset 94900abda1a5 by Xiang Zhang in branch '2.7':
Issue #29038: Fix duplicate get_ca_certs() doc entry.
https://hg.python.org/cpython/rev/94900abda1a5

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

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

From report at bugs.python.org  Thu Dec 22 22:16:54 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 23 Dec 2016 03:16:54 +0000
Subject: [docs] [issue29038] Duplicate entry for SSLContext.get_ca_certs()
 in ssl
In-Reply-To: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>
Message-ID: <1482463014.63.0.889367168792.issue29038@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for the report Daniel!

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

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

From report at bugs.python.org  Thu Dec 22 23:58:56 2016
From: report at bugs.python.org (Eric Appelt)
Date: Fri, 23 Dec 2016 04:58:56 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482469135.91.0.0792719689612.issue29026@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I looked at the documentation and implementation and made a patch to hopefully clarify the issue. I also have some comments:

- The term "epoch" is actually defined at the top of the page with instructions for how to determine it, i.e. run "gmtime(0)".

- I added a definition for the term "seconds since the epoch" since this typically means the number of seconds that have elapsed since the epoch excluding leap seconds, although it may vary by platform.

- I'm a bit uncomfortable with potential confusion regarding Windows, since the Windows epoch begins on 1601, although we adjust it to 1970: https://github.com/python/cpython/blob/d739274e7b69f63263054cc24684e7e637264350/Python/pytime.c#L536-L539 I didn't add a note in the patch as I am not a windows developer, but I wonder if there could be some confusion.

- Even though its redundant with the top of the page, I added specific clarification to time.time() as it appears that most readers are going to navigate to that anchor specifically and not read the discussion of what we mean by "epoch" above.

- I need to test my assertion that Windows does not count leap seconds. I'm pretty sure but not 100% confident that I am correct from what I read, but I need to find someone with a windows machine tomorrow and actually check it. The windows documentation for the FILETIME structure suggests that leap seconds might be counted - https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx - but I think this is just an oversight in the documentation.

- Just out of personal curiousity does anyone have an example of a legacy UNIX system that counts leap seconds in the epoch? This seems tricky to do as I would presume that the OS would need some table that would be updated whenever the astronomers declare a new leap second.

----------
keywords: +patch
Added file: http://bugs.python.org/file46005/29026_unixtime_v1.patch

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

From report at bugs.python.org  Fri Dec 23 07:11:24 2016
From: report at bugs.python.org (Karsten Tinnefeld)
Date: Fri, 23 Dec 2016 12:11:24 +0000
Subject: [docs] [issue29052] Detect Windows platform 32bit/64bit
 automatically
Message-ID: <1482495084.23.0.916471956703.issue29052@psf.upfronthosting.co.za>


New submission from Karsten Tinnefeld:

When navigating https://www.python.org/ with a browser, in the main menu fly-out Downloads/Download for Windows it suggests to download the 32 bit version of the current 2.x and 3.x releases (leaving out the information that the buttons provide 32 bit binaries).

Further, https://www.python.org/downloads/ repeats this pattern in its header area "Download the latest version for Windows".

May I suggest that, depending on the User-Agent header, the menu offers 64 bit versions of the interpreter and tools package by default in case the browser suggests it is running on a 64 bit platform?

According to own tests and http://www.useragentstring.com/pages/useragentstring.php, this should be possible with a regexp like '(WOW|x)64' on at least IE, FF, Chrome and Edge.

----------
assignee: docs at python
components: Documentation
messages: 283875
nosy: Karsten Tinnefeld, docs at python
priority: normal
severity: normal
status: open
title: Detect Windows platform 32bit/64bit automatically
type: enhancement
versions: Python 2.7, Python 3.7

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

From report at bugs.python.org  Fri Dec 23 07:40:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 23 Dec 2016 12:40:42 +0000
Subject: [docs] [issue29052] Detect Windows platform 32bit/64bit
 automatically
In-Reply-To: <1482495084.23.0.916471956703.issue29052@psf.upfronthosting.co.za>
Message-ID: <1482496842.57.0.215126888318.issue29052@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, it looks like a reasonable request to me, but the issue tracker for python.org is located at https://github.com/python/pythondotorg/issues Please open a new issue there (or send a pull request)

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec 23 08:08:33 2016
From: report at bugs.python.org (issuefinder)
Date: Fri, 23 Dec 2016 13:08:33 +0000
Subject: [docs] [issue29018] Misinformation when showing how slices work in
 The Tutorial
In-Reply-To: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>
Message-ID: <1482498513.25.0.161640801497.issue29018@psf.upfronthosting.co.za>


issuefinder added the comment:

You seem to be right.
Sorry about the incovenience.

----------

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

From report at bugs.python.org  Fri Dec 23 10:59:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Dec 2016 15:59:48 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482508788.85.0.298299819423.issue29026@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Another suggestion: mention localtime() and gmtime() in time() documentation to explain how to convert such timestamp to a more common date format.

----------

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

From report at bugs.python.org  Fri Dec 23 12:22:30 2016
From: report at bugs.python.org (Eric Appelt)
Date: Fri, 23 Dec 2016 17:22:30 +0000
Subject: [docs] [issue29026] time.time() documentation should mention UTC
 timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482513750.9.0.765484821661.issue29026@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I had some checks performed on a Windows platform using the following snippet:

# valid for 2016
import time
def check():
    t = time.gmtime()
    print(46*86400*365 + 11*86400 + (t.tm_yday-1)*86400 + t.tm_hour*3600 + t.tm_min*60 + t.tm_sec)
    print(time.time())
    print(time.gmtime(0))
check()

This ensures that the time since the epoch is counted excluding leap seconds if the first two lines of output are approximately the same (to nearest second), and finally that the epoch is the Unix epoch.

On Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 I see:

1482502941
1482502941.9609053
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)

Unless there is major variation among windows versions on how FILETIMEs are calculated and the results of basic system calls, I feel fairly confident now that the calculation of time since the epoch in CPython is the same on Windows as it is in POSIX-compliant platforms.

----------

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

From report at bugs.python.org  Sat Dec 24 03:18:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 08:18:25 +0000
Subject: [docs] [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <20161224081822.5888.76805.336221E3@psf.io>


Roundup Robot added the comment:

New changeset a33472f8a2c6 by Martin Panter in branch '3.5':
Issue #29004: Document binascii.crc_hqx() implements CRC-CCITT
https://hg.python.org/cpython/rev/a33472f8a2c6

New changeset 52db2072e88b by Martin Panter in branch '3.6':
Issue #29004: Merge crc_hqx() doc from 3.5
https://hg.python.org/cpython/rev/52db2072e88b

New changeset 3af3702b2f0a by Martin Panter in branch 'default':
Issue #29004: Merge crc_hqx() doc from 3.6
https://hg.python.org/cpython/rev/3af3702b2f0a

New changeset 5ae6102270df by Martin Panter in branch '2.7':
Issue #29004: Document binascii.crc_hqx() implements CRC-CCITT
https://hg.python.org/cpython/rev/5ae6102270df

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

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

From report at bugs.python.org  Sat Dec 24 03:18:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 08:18:25 +0000
Subject: [docs] [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <20161224081822.5888.94151.0989B8A8@psf.io>


Roundup Robot added the comment:

New changeset 9347d0b2ee08 by Martin Panter in branch '3.5':
Issue #28960: Drop comma attached to dash in Thread.join() description
https://hg.python.org/cpython/rev/9347d0b2ee08

New changeset d70fcf1866ad by Martin Panter in branch '3.6':
Issue #28960: Merge Thread.join() doc from 3.5
https://hg.python.org/cpython/rev/d70fcf1866ad

New changeset cefcfacd87e4 by Martin Panter in branch 'default':
Issue #28960: Merge Thread.join() doc from 3.6
https://hg.python.org/cpython/rev/cefcfacd87e4

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

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

From report at bugs.python.org  Sat Dec 24 03:49:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 08:49:32 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <20161224084928.26751.95754.6F9021F6@psf.io>


Roundup Robot added the comment:

New changeset b0b17b41edfc by Martin Panter in branch '3.5':
Issue #1446619: Account for negative slice direction in description
https://hg.python.org/cpython/rev/b0b17b41edfc

New changeset 031af2160094 by Martin Panter in branch '3.6':
Issue #1446619: Merge slicing description from 3.5
https://hg.python.org/cpython/rev/031af2160094

New changeset 4383d403aaef by Martin Panter in branch 'default':
Issue #1446619: Merge slicing description from 3.6
https://hg.python.org/cpython/rev/4383d403aaef

New changeset d63a11bd98ce by Martin Panter in branch '2.7':
Issue #1446619: Account for negative slice direction in description
https://hg.python.org/cpython/rev/d63a11bd98ce

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

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

From report at bugs.python.org  Sat Dec 24 03:57:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 08:57:46 +0000
Subject: [docs] [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1482569866.41.0.0591137255663.issue28960@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree the second patch is more correct. This undoes the change as it was introduced in revision c4cf1b886d6b and matches the Python 2 text.

----------
nosy: +martin.panter
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Dec 24 04:21:43 2016
From: report at bugs.python.org (Frank Millman)
Date: Sat, 24 Dec 2016 09:21:43 +0000
Subject: [docs] [issue29062] Documentation link error
Message-ID: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>


New submission from Frank Millman:

If you call up online documentation for Python3.6, and select modules>h>hashlib, it takes you to 15.2. hashlib ? BLAKE2 hash functions

It should take you to 15.1. hashlib ? Secure hashes and message digests

----------
assignee: docs at python
components: Documentation
messages: 283930
nosy: docs at python, frankmillman
priority: normal
severity: normal
status: open
title: Documentation link error
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Dec 24 04:40:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 09:40:11 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482572411.08.0.924692872753.issue29062@psf.upfronthosting.co.za>


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


----------
nosy: +christian.heimes, georg.brandl, gregory.p.smith
title: Documentation link error -> hashlib documentation link error
versions: +Python 3.7

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

From report at bugs.python.org  Sat Dec 24 04:51:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 09:51:30 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1482573090.18.0.717235817719.issue1446619@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 24 04:51:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 09:51:36 +0000
Subject: [docs] [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482573095.92.0.950768608508.issue29004@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the help Serhiy

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

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

From report at bugs.python.org  Sat Dec 24 05:06:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 10:06:38 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1482573998.35.0.584951929873.issue28978@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Dec 24 05:09:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 10:09:28 +0000
Subject: [docs] [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1482574167.97.0.87010529175.issue22942@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 28978 covers the parameter list syntax (Bug 1 + plus another problem).

----------
dependencies: +a redundant right  parentheses in the EBNF rules of parameter_list

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

From report at bugs.python.org  Sat Dec 24 05:28:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 10:28:01 +0000
Subject: [docs] [issue28954] Incorrect EBNF rule of keywords_arguments
In-Reply-To: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>
Message-ID: <20161224102758.79374.49938.C2C3628A@psf.io>


Roundup Robot added the comment:

New changeset 3f94e3c7dcc5 by Martin Panter in branch '3.5':
Issue #28954: Add missing comma to keyword argument syntax
https://hg.python.org/cpython/rev/3f94e3c7dcc5

New changeset ef53ef8e09e5 by Martin Panter in branch '3.6':
Issue #28954: Merge keyword argument syntax from 3.5
https://hg.python.org/cpython/rev/ef53ef8e09e5

New changeset 8e311f109b22 by Martin Panter in branch 'default':
Issue #28954: Merge keyword argument syntax from 3.6
https://hg.python.org/cpython/rev/8e311f109b22

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

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

From report at bugs.python.org  Sat Dec 24 05:53:53 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 10:53:53 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482576833.42.0.032606372065.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Made a pull request for this

----------
pull_requests: +7

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

From report at bugs.python.org  Sat Dec 24 05:55:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 10:55:17 +0000
Subject: [docs] [issue28954] Incorrect EBNF rule of keywords_arguments
In-Reply-To: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>
Message-ID: <1482576917.67.0.82313156462.issue28954@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for finding this Woo!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Dec 24 05:55:29 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 10:55:29 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482576929.45.0.97978173298.issue29047@psf.upfronthosting.co.za>


Changes by Patrik Iselind <patrik.mrx at gmail.com>:


----------
pull_requests:  -7

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

From report at bugs.python.org  Sat Dec 24 05:58:06 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 10:58:06 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482577086.18.0.350190733485.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Cannot figure out how to add the link to the GitHub PR field. Adding link here instead.

https://github.com/python/devguide/pull/88

----------

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

From report at bugs.python.org  Sat Dec 24 07:52:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 24 Dec 2016 12:52:42 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482583962.18.0.0853020443155.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Is the https://docs.python.org/3/library/crypto.html section messed up? Two hashlib entries and some other bad entries?

----------
nosy: +xiang.zhang

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

From report at bugs.python.org  Sat Dec 24 12:56:32 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 17:56:32 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482602192.88.0.0846650585403.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

My GitHub PR got closed. So closing this issue as well.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec 24 13:01:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 24 Dec 2016 18:01:24 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482602484.41.0.746901303673.issue29047@psf.upfronthosting.co.za>


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


----------
stage:  -> resolved

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

From report at bugs.python.org  Sat Dec 24 13:01:36 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 24 Dec 2016 18:01:36 +0000
Subject: [docs] [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482602496.29.0.889571536054.issue29047@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.7

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

From report at bugs.python.org  Sat Dec 24 20:19:51 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 25 Dec 2016 01:19:51 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482628791.55.0.381703835433.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

1. remove `.. module:: hashlib` from Doc/library/hashlib-blake2.rst
2. merge Doc/library/hashlib-blake2.rst content into Doc/library/hashlib.rst

Hmm, which is better?

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Sun Dec 25 01:47:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 06:47:58 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482648478.81.0.889928871378.issue29062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Replace ".. module" with ".. currentmodule".

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

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

From report at bugs.python.org  Sun Dec 25 04:40:05 2016
From: report at bugs.python.org (Karsten Tinnefeld)
Date: Sun, 25 Dec 2016 09:40:05 +0000
Subject: [docs] [issue29052] Detect Windows platform 32bit/64bit
 automatically
In-Reply-To: <1482496842.57.0.215126888318.issue29052@psf.upfronthosting.co.za>
Message-ID: <a044cf72-53ca-7c46-e932-a1fd2d7003cb@gmail.com>


Karsten Tinnefeld added the comment:

Thanks. Opened at https://github.com/python/pythondotorg/issues/1044

Karsten
-- 
Karsten Tinnefeld <K.Tinnefeld at gmail.com>
Dortmund, Germany

----------

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

From report at bugs.python.org  Sun Dec 25 08:52:33 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 25 Dec 2016 13:52:33 +0000
Subject: [docs] [issue29068] Fix example code for PyErr_Fetch
Message-ID: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Remove an extra *

The typo is there in 3.5~3.7 branches. 2.7 branch does not have this example.

Nosy the two major commiters to Python/errors.c

----------
assignee: docs at python
components: Documentation
files: PyErr_Fetch-fix.patch
keywords: patch
messages: 283993
nosy: Chi Hsuan Yen, docs at python, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix example code for PyErr_Fetch
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46029/PyErr_Fetch-fix.patch

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

From report at bugs.python.org  Sun Dec 25 09:21:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 14:21:12 +0000
Subject: [docs] [issue29068] Fix example code for PyErr_Fetch
In-Reply-To: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>
Message-ID: <1482675672.86.0.546855159942.issue29068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thank you for your contribution Chi Hsuan Yen.

----------
assignee: docs at python -> serhiy.storchaka
stage:  -> commit review

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

From report at bugs.python.org  Sun Dec 25 09:24:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Dec 2016 14:24:34 +0000
Subject: [docs] [issue29068] Fix example code for PyErr_Fetch
In-Reply-To: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>
Message-ID: <20161225142431.107561.75177.40228826@psf.io>


Roundup Robot added the comment:

New changeset 34e7b9879e60 by Serhiy Storchaka in branch '3.5':
Issue #29068: Fixed a typo in PyErr_Fetch example.
https://hg.python.org/cpython/rev/34e7b9879e60

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

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

From report at bugs.python.org  Sun Dec 25 09:24:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 14:24:58 +0000
Subject: [docs] [issue29068] Fix example code for PyErr_Fetch
In-Reply-To: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>
Message-ID: <1482675898.98.0.498693358493.issue29068@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec 25 10:38:32 2016
From: report at bugs.python.org (paka)
Date: Sun, 25 Dec 2016 15:38:32 +0000
Subject: [docs] [issue29069] Default PyPI URL in docs is not what is really
 in code
Message-ID: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za>


New submission from paka:

Currently https://docs.python.org/3.7/distutils/packageindex.html#the-pypirc-file says that URL of the PyPI server defaults to https://www.python.org/pypi. That URL does not work.

Lib/distutils/config.py defines DEFAULT_REPOSITORY as https://upload.pypi.org/legacy/, so I'm attaching a patch for docs to update to current default.

I might be wrong about value that must be in docs, so guidance is appreciated :)

----------
assignee: docs at python
components: Distutils, Documentation
files: fix-pypi-url.patch
keywords: patch
messages: 283997
nosy: docs at python, dstufft, eric.araujo, paka
priority: normal
severity: normal
status: open
title: Default PyPI URL in docs is not what is really in code
versions: Python 3.7
Added file: http://bugs.python.org/file46034/fix-pypi-url.patch

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

From report at bugs.python.org  Mon Dec 26 03:53:33 2016
From: report at bugs.python.org (=?utf-8?b?5YqJ5YqN5bOw?=)
Date: Mon, 26 Dec 2016 08:53:33 +0000
Subject: [docs] [issue29072] the message of help(os.environ.setdefault) have
 some error
Message-ID: <1482742413.83.0.382615378598.issue29072@psf.upfronthosting.co.za>


New submission from ???:

the message `D.setdefault(k[,d])', compiler inform SyntaxError: invalid syntax. I think that it woulld be D.setdefault([k, d]).

----------
assignee: docs at python
components: Documentation
messages: 284015
nosy: docs at python, ???
priority: normal
severity: normal
status: open
title: the message of help(os.environ.setdefault) have some error
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec 26 05:48:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 10:48:49 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482749329.89.0.21622503008.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I like currentmodule directive.

----------
keywords: +patch
Added file: http://bugs.python.org/file46040/29062-currentmodule.patch

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

From report at bugs.python.org  Mon Dec 26 07:00:30 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 12:00:30 +0000
Subject: [docs] [issue27671] FAQ: len() is still function for good reason.
In-Reply-To: <1470214886.13.0.870924776007.issue27671@psf.upfronthosting.co.za>
Message-ID: <1482753629.88.0.459083965449.issue27671@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I can't write long English document.
Can I quote Guido's mail instead?

----------
keywords: +patch
Added file: http://bugs.python.org/file46041/faq-function-method.patch

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

From report at bugs.python.org  Mon Dec 26 08:37:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 13:37:15 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482759435.05.0.0691551032162.issue29062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I didn't tested my suggestion. If it solves the issue and makes all related references correct, feel free to push the patch Inada.

----------
assignee: docs at python -> inada.naoki
stage:  -> commit review

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

From report at bugs.python.org  Mon Dec 26 09:15:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Dec 2016 14:15:50 +0000
Subject: [docs] [issue29072] the message of help(os.environ.setdefault) have
 some error
In-Reply-To: <1482742413.83.0.382615378598.issue29072@psf.upfronthosting.co.za>
Message-ID: <1482761750.2.0.14857179293.issue29072@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documented syntax is correct.  The '[]' are part of the syntax *specification*, not the syntax itself.  They indicate an optional argument, just as they do in most syntax diagrams.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec 26 15:15:52 2016
From: report at bugs.python.org (Dhushyanth Ramasamy)
Date: Mon, 26 Dec 2016 20:15:52 +0000
Subject: [docs] [issue29078] Example in Section 8.1.5 time Objects is broken
Message-ID: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>


New submission from Dhushyanth Ramasamy:

The example doesn't import timedelta. This causes an error when attempting to run the example in the interactive window.

----------
assignee: docs at python
components: Documentation
files: datetime.patch
keywords: patch
messages: 284042
nosy: docs at python, rdhushyanth
priority: normal
severity: normal
status: open
title: Example in Section 8.1.5 time Objects is broken
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46045/datetime.patch

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

From report at bugs.python.org  Mon Dec 26 22:20:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 03:20:02 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <20161227031958.80407.60659.0174A99C@psf.io>


Roundup Robot added the comment:

New changeset 1970c9ea8572 by INADA Naoki in branch 'default':
Issue #29062: doc: Fix hashlib module index conflict
https://hg.python.org/cpython/rev/1970c9ea8572

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

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

From report at bugs.python.org  Mon Dec 26 22:28:27 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 03:28:27 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482809307.4.0.847928990043.issue29062@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Mon Dec 26 23:06:45 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 04:06:45 +0000
Subject: [docs] [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <1482811605.89.0.778209828422.issue29078@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

LGTM.

Thanks for your work Dhushyanth! It's appreciated if you could sign the CLA: https://www.python.org/psf/contrib/contrib-form/.

----------
assignee: docs at python -> xiang.zhang
nosy: +xiang.zhang
stage:  -> commit review
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 26 23:11:54 2016
From: report at bugs.python.org (Dhushyanth Ramasamy)
Date: Tue, 27 Dec 2016 04:11:54 +0000
Subject: [docs] [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <1482811914.75.0.0941453628181.issue29078@psf.upfronthosting.co.za>


Dhushyanth Ramasamy added the comment:

Hi Xiang,
Signed the CLA, but looks like it may take two days to reflect.

----------
Added file: http://bugs.python.org/file46049/Python Contributor Agreement Form - signed.pdf

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

From report at bugs.python.org  Mon Dec 26 23:39:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 04:39:11 +0000
Subject: [docs] [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <20161227043907.4083.58861.E8127BA8@psf.io>


Roundup Robot added the comment:

New changeset 878a91174e74 by Xiang Zhang in branch '2.7':
Issue #29078: Add the missing import in datetime.time doc example.
https://hg.python.org/cpython/rev/878a91174e74

New changeset 172b2ac82037 by Xiang Zhang in branch '3.5':
Issue #29078: Add the missing import in datetime.time doc example.
https://hg.python.org/cpython/rev/172b2ac82037

New changeset 83b089b7ab43 by Xiang Zhang in branch '3.6':
Issue #29078: Merge 3.5.
https://hg.python.org/cpython/rev/83b089b7ab43

New changeset f35c3b0b6eda by Xiang Zhang in branch 'default':
Issue #29078: Merge 3.6.
https://hg.python.org/cpython/rev/f35c3b0b6eda

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

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

From report at bugs.python.org  Mon Dec 26 23:41:15 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 04:41:15 +0000
Subject: [docs] [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <1482813674.95.0.389976011368.issue29078@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> Signed the CLA, but looks like it may take two days to reflect.

Thanks. This change is trivial so I can push it first. ;-)

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

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

From report at bugs.python.org  Tue Dec 27 00:08:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 05:08:37 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482815317.29.0.48168939806.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This fixed the index. But the section is still messed up: https://docs.python.org/3/library/crypto.html. The three entries: Module, Examples, Credits in my mind should not appear on the index.

----------

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

From report at bugs.python.org  Tue Dec 27 01:07:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 06:07:26 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <20161227060723.106757.22041.A008DCC6@psf.io>


Roundup Robot added the comment:

New changeset c75ef013bca3 by INADA Naoki in branch 'default':
Issue #29062: doc: Fix heading level of hashlib-blake2
https://hg.python.org/cpython/rev/c75ef013bca3

----------

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

From report at bugs.python.org  Tue Dec 27 01:50:35 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 06:50:35 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482821435.35.0.279504321598.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

While section level of Module, Examples, and Credits is fixed,
https://docs.python.org/3/library/crypto.html seems still weird.
It looks like there are two `hashlib` modules.

Now I think hashlib-blake2 should be merged into hashlib.

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

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

From report at bugs.python.org  Tue Dec 27 02:06:29 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 07:06:29 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482822389.05.0.330262857454.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> Now I think hashlib-blake2 should be merged into hashlib.

+1

INADA, 3.6 branch also suffers the problems here, I didn't see you patch it.

----------

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

From report at bugs.python.org  Tue Dec 27 02:44:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 07:44:29 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482824669.52.0.62593065478.issue29062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> While section level of Module, Examples, and Credits is fixed,
> https://docs.python.org/3/library/crypto.html seems still weird.
> It looks like there are two `hashlib` modules.

That is because hashlib-blake2.rst is explicitly added to the TOC list in Doc/library/crypto.rst.

----------

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

From report at bugs.python.org  Tue Dec 27 03:04:36 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 08:04:36 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482825876.65.0.689809088107.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> That is because hashlib-blake2.rst is explicitly added to the TOC list in Doc/library/crypto.rst.

Yes. All rst should be explicitly added by `toctree` or `include`.

In this case, I feel there are no reason to use `include` directive
instead of merging two files.

Another option is adding `toctree` directive in `hashlib.rst`.
But it means we should organize to use sub toctree, like Doc/library/asyncio.rst.

----------

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

From report at bugs.python.org  Tue Dec 27 03:46:40 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 08:46:40 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482828400.1.0.00991828317509.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> INADA, 3.6 branch also suffers the problems here, I didn't see you patch it.

Oh, I'm sorry.
I'll update 3.6 branch in next time.

----------

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

From report at bugs.python.org  Tue Dec 27 03:54:35 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 08:54:35 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482828875.19.0.223135733834.issue29062@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file46051/merge-hashlib-blake2.patch

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

From report at bugs.python.org  Tue Dec 27 06:36:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 11:36:53 +0000
Subject: [docs] [issue29025] random.seed() relation to hash() function and
 its determinism is vague
In-Reply-To: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>
Message-ID: <1482838613.17.0.572145793085.issue29025@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is out of date.
See http://bugs.python.org/issue27706

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Tue Dec 27 07:15:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 12:15:19 +0000
Subject: [docs] [issue29069] Default PyPI URL in docs is not what is really
 in code
In-Reply-To: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za>
Message-ID: <20161227121516.79585.8333.FB9FB0B9@psf.io>


Roundup Robot added the comment:

New changeset c4cd7e00a640 by Berker Peksag in branch '3.5':
Issue #29069: Update the default URL of PyPI server
https://hg.python.org/cpython/rev/c4cd7e00a640

New changeset b1ccf713e8f8 by Berker Peksag in branch '3.6':
Issue #29069: Merge from 3.5
https://hg.python.org/cpython/rev/b1ccf713e8f8

New changeset b712e4818ff8 by Berker Peksag in branch 'default':
Issue #29069: Merge from 3.6
https://hg.python.org/cpython/rev/b712e4818ff8

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

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

From report at bugs.python.org  Tue Dec 27 07:16:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 27 Dec 2016 12:16:11 +0000
Subject: [docs] [issue29069] Default PyPI URL in docs is not what is really
 in code
In-Reply-To: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za>
Message-ID: <1482840971.18.0.906080132891.issue29069@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Dec 27 14:01:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 19:01:59 +0000
Subject: [docs] [issue29086] Document C API that is not part of the limited
 API
Message-ID: <1482865319.03.0.627052322458.issue29086@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>From the documentation:

https://docs.python.org/3/c-api/stable.html

    In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API."

But they don't.

Following sample patch adds the notes to Unicode Objects and Codecs C API. I'm going to add them to all C API.

What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it?

----------
assignee: docs at python
components: Documentation
files: unicode-not-part-of-the-limited-api.patch
keywords: patch
messages: 284125
nosy: docs at python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document C API that is not part of the limited API
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46057/unicode-not-part-of-the-limited-api.patch

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

From report at bugs.python.org  Tue Dec 27 14:13:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 19:13:23 +0000
Subject: [docs] [issue29087] UCS4 support functions are not implemented
Message-ID: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a special section in the documentation of Unicode Objects C API: UCS4 Support.

https://docs.python.org/3/c-api/unicode.html#ucs4-support

It documents utility functions that work on strings of Py_UCS4 characters like Py_UCS4_strlen(), Py_UCS4_strcpy(), etc. But none of these functions is implemented. May be the documentation should be just removed?

----------
assignee: docs at python
components: Documentation, Unicode
messages: 284126
nosy: benjamin.peterson, docs at python, ezio.melotti, haypo, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: UCS4 support functions are not implemented
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Dec 27 16:27:05 2016
From: report at bugs.python.org (Xezlec)
Date: Tue, 27 Dec 2016 21:27:05 +0000
Subject: [docs] [issue29089] Python 2 dictionary keys described incorrectly
Message-ID: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>


New submission from Xezlec:

In section 5.5 on the page https://docs.python.org/2/tutorial/datastructures.html#dictionaries the requirements given for dictionary keys are not correct.

Specifically, it is claimed that only immutable objects (and tuples containing only immutable objects) may be used as keys.  This is false, as user-defined mutable objects may be used as keys.  I suggest rewording along these lines:

"Only user-defined objects and immutable built-in types may be used as keys.  Although allowed, it is bad practice to use a mutable user-defined object as a key when equality is determined in any way other than identity (the default)."

----------
assignee: docs at python
components: Documentation
messages: 284135
nosy: Xezlec, docs at python
priority: normal
severity: normal
status: open
title: Python 2 dictionary keys described incorrectly
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 27 16:36:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Dec 2016 21:36:47 +0000
Subject: [docs] [issue29089] Python 2 dictionary keys described incorrectly
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482874607.59.0.750948096474.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

It could say 'hashable object' instead of immutable object.  I don't know if hash has been introduced by that point, though.

It's the tutorial.  Probably better to just leave it alone.  Precise understanding can come later.

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

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

From report at bugs.python.org  Tue Dec 27 16:38:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Dec 2016 21:38:07 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482874687.08.0.544551812035.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note that this applies equally well to python3.

----------
title: Python 2 dictionary keys described incorrectly -> dictionary keys described incorrectly in tutorial
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Dec 27 18:18:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Dec 2016 23:18:51 +0000
Subject: [docs] [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <1482880731.85.0.101940170213.issue29087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I recall that the very first implementation of the PEP 393 (compact strings) was heavily based on UCS4. Slowly, I optimized the code by specializing functions to each kind of string (ACSII, Latin1, UCS2, UCS4).

----------

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

From report at bugs.python.org  Tue Dec 27 18:45:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Dec 2016 23:45:28 +0000
Subject: [docs] [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <1482882328.12.0.824846639686.issue29087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Py_UCS4_strlen() added by:

changeset:   72475:8beaa9a37387
user:        Martin v. L?wis <martin at v.loewis.de>
date:        Wed Sep 28 07:41:54 2011 +0200
files:       ...
description:
Implement PEP 393.


Removed by:

changeset:   73236:80a7ab9ac29f
user:        Martin v. L?wis <martin at v.loewis.de>
date:        Mon Oct 31 08:40:56 2011 +0100
files:       Include/unicodeobject.h Objects/unicodeobject.c Objects/uniops.h
description:
Drop Py_UCS4_ functions. Closes #13246.


80a7ab9ac29f came before Python 3.3.0:

haypo at selma$ hg log -r v3.3.0
changeset:   79242:bd8afb90ebf2
branch:      3.3
tag:         v3.3.0
parent:      79237:cb84dcb35114
user:        Georg Brandl <georg at python.org>
date:        Sat Sep 29 09:44:17 2012 +0200
files:       Lib/test/test_sys.py
description:
Fix test_sys.test_implementation for final releases.


Py_UCS4_strlen() was documented but was never part of any public Python release.

=> you can remove the doc.

----------

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

From report at bugs.python.org  Tue Dec 27 20:11:31 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 28 Dec 2016 01:11:31 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482887491.36.0.944210520969.issue29089@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> It's the tutorial.  Probably better to just leave it alone.  Precise understanding can come later.

I agree.
Beginner should start using dict with builtin immutable type as key.
hashable is too complex at this point.

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Tue Dec 27 20:45:58 2016
From: report at bugs.python.org (Xezlec)
Date: Wed, 28 Dec 2016 01:45:58 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482889558.28.0.0899697532357.issue29089@psf.upfronthosting.co.za>


Xezlec added the comment:

> It's the tutorial.  Probably better to just leave it alone.  Precise understanding can come later.

But the problem isn't that it's imprecise.  It's flat-out wrong.  My opinion would be that it's always a bad idea to put wrong information in the documentation, especially when it's the first Google hit.  It can lead to all sorts of confusion and frustration (as it did for me).  Users are likely to assume documentation from any official source is the final word.

If precision is the problem, could it be reworded to be more vague?

----------

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

From report at bugs.python.org  Tue Dec 27 21:27:30 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Dec 2016 02:27:30 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482892050.04.0.856377553634.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is not wrong.  It does not say that keys are limited to immutables, only that immutables can be keys.  Perhaps the sentence about a tuple pointing to a mutable could be tightened up, though, by saying that if a tuple points to something that can not itself be a dictionary key, then that tuple can not be a dictionary key.

----------

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

From report at bugs.python.org  Tue Dec 27 21:41:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 28 Dec 2016 02:41:49 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482892909.52.0.93574475294.issue29089@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> If precision is the problem, could it be reworded to be more vague?

"can be any immutable" seems vague enough to me.  It doesn't say "cannot be any mutable type.".

>  Users are likely to assume documentation from any official source is the final word.

But tutorial should use less words as possible.  This section is before introducing "class" statement.  Only strings, numbers, list and set are introduced before section.

I feel assuming early part of tutorial as final word bad practice.

----------

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

From report at bugs.python.org  Tue Dec 27 23:11:51 2016
From: report at bugs.python.org (Xezlec)
Date: Wed, 28 Dec 2016 04:11:51 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482898311.77.0.237408747855.issue29089@psf.upfronthosting.co.za>


Xezlec added the comment:

> Perhaps the sentence about a tuple pointing to a mutable could be tightened up, though, by saying that if a tuple points to something that can not itself be a dictionary key, then that tuple can not be a dictionary key.

That would be great.  Thank you.

> I feel assuming early part of tutorial as final word bad practice.

Alright.  If that's how both of you feel, then it can't be helped.

But if that's how it is, then maybe it would be a good idea to make the tutorial more distinct?  Right now, the only way I can tell Google has landed me on a tutorial page as opposed to a reference page is the word "tutorial" in the URL and in small print at the very top of the page.  They're styled similarly.  I never even realized they were separate things until today (let alone that one of them must be read skeptically).

Sorry to take up your time.  Thanks for listening.

----------

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

From report at bugs.python.org  Wed Dec 28 02:20:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 07:20:17 +0000
Subject: [docs] [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <20161228072014.4558.18844.B851ECE2@psf.io>


Roundup Robot added the comment:

New changeset 29d46d29e169 by Serhiy Storchaka in branch '3.5':
Issue #29087: Removed the documentation of non-existing UCS4 support functions.
https://hg.python.org/cpython/rev/29d46d29e169

New changeset e44b6b01c8cf by Serhiy Storchaka in branch '3.6':
Issue #29087: Removed the documentation of non-existing UCS4 support functions.
https://hg.python.org/cpython/rev/e44b6b01c8cf

New changeset 0ec4befef7e0 by Serhiy Storchaka in branch 'default':
Issue #29087: Removed the documentation of non-existing UCS4 support functions.
https://hg.python.org/cpython/rev/0ec4befef7e0

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

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

From report at bugs.python.org  Wed Dec 28 02:20:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 07:20:58 +0000
Subject: [docs] [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <1482909658.07.0.73751268781.issue29087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

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

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

From report at bugs.python.org  Wed Dec 28 03:42:26 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 28 Dec 2016 08:42:26 +0000
Subject: [docs] [issue29092] Sync os.stat's doc and doc string
Message-ID: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The accepted types of parameter *path* are different between os.stat's doc and doc string.

In doc, it mentions Pathlike, string and file descriptor. In doc string, it mentions string, bytes and file descriptor. (3.5 only lack bytes in doc).

----------
assignee: docs at python
components: Documentation
files: doc-os-stat.patch
keywords: patch
messages: 284167
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Sync os.stat's doc and doc string
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46061/doc-os-stat.patch

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

From paly90 at centrum.sk  Tue Dec 27 13:31:27 2016
From: paly90 at centrum.sk (paly90 at centrum.sk)
Date: Tue, 27 Dec 2016 19:31:27 +0100
Subject: [docs] =?utf-8?q?invalid_link_to_ZIP_format_documnetation?=
Message-ID: <20161227193127.55012DAA@centrum.sk>

Hi,
I'd like to report the invalid link <https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT> to ZIP format documentation used in zipfile module <https://docs.python.org/3/library/zipfile.html> doc.
?
?
? Paul

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

From report at bugs.python.org  Wed Dec 28 09:33:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Dec 2016 14:33:52 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482935632.36.0.164150156081.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

You know, it might actually not be a bad idea to use a slightly different color scheme for the tutorial.  We'll see if that idea generates any interest :)

----------

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

From report at bugs.python.org  Wed Dec 28 17:08:50 2016
From: report at bugs.python.org (Carl George)
Date: Wed, 28 Dec 2016 22:08:50 +0000
Subject: [docs] [issue29098] document minimum sqlite version
Message-ID: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za>


New submission from Carl George:

While attempting to build a Python 3.6 RPM for RHEL/CentOS 6, I noticed the following warning.

*** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-i686-3.6-pydebug/_sqlite3.cpython-36dm-i386-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly

I was able to locate changeset 284676cf2ac8 (#10740) which introduced the usage of the sqlite3_stmt_readonly interface.  That interface wasn't added to sqlite until 3.7.4 (http://www.sqlite.org/releaselog/3_7_4.html).  My RPM build failed because RHEL/CentOS 6 only has sqlite 3.6.20.  I understand that Python can't support old libraries forever, but can this minimum sqlite version be noted somewhere in the documentation?

----------
assignee: docs at python
components: Documentation
messages: 284202
nosy: carlwgeorge, docs at python
priority: normal
severity: normal
status: open
title: document minimum sqlite version
versions: Python 3.6

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

From report at bugs.python.org  Wed Dec 28 18:19:12 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 28 Dec 2016 23:19:12 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in the standard
 library
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1482967152.34.0.80446781801.issue28710@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Marking as a stdlib-wide issue since it's not configparser-specific.

FYI, as you probably noticed, the `term' syntax predates Sphinx and is used in lots of places. While I think it would be nice to fix it, it's a big diff.

----------
title: Sphinx incompatible markup in configparser.ConfigParser. -> Sphinx incompatible markup in the standard library

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

From report at bugs.python.org  Thu Dec 29 05:38:15 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Thu, 29 Dec 2016 10:38:15 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483007894.97.0.287353520561.issue28612@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hi,

I am new to Python and want to contribute. I am attaching a patch having required example of using defaultdict with translate. Please let me know if anything needs to be changed. I have tested the example and also the html doc in my local.

Regards,
Gaurav

----------
keywords: +patch
nosy: +Gaurav Tatke
Added file: http://bugs.python.org/file46072/translateexample_issue28612.patch

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

From report at bugs.python.org  Thu Dec 29 07:41:02 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:41:02 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1483015261.99.0.0166657720211.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Attached patche for Python 3.3 (change `defparameter` to use `+`).

----------
keywords: +patch
Added file: http://bugs.python.org/file46076/3.3_func_def.patch

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

From report at bugs.python.org  Thu Dec 29 07:41:49 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:41:49 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1483015308.98.0.297576202444.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Further patch for `3.4` and `3.5`:

Change `|` to `(` and fix `defparameter` to use `+`

----------
Added file: http://bugs.python.org/file46077/3.4_3.5_func_def.patch

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

From report at bugs.python.org  Thu Dec 29 07:42:44 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:42:44 +0000
Subject: [docs] [issue28978] a redundant right parentheses in the EBNF rules
 of parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1483015364.06.0.397732184918.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Further patch for 3.6 and 3.7 to address `defparameter` change here too.

----------
Added file: http://bugs.python.org/file46078/3.6_3.7_func_def.patch

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

From report at bugs.python.org  Thu Dec 29 11:29:54 2016
From: report at bugs.python.org (iMath)
Date: Thu, 29 Dec 2016 16:29:54 +0000
Subject: [docs] [issue29105] code or doc improvement for
 logging.handlers.RotatingFileHandler
Message-ID: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za>


New submission from iMath:

For 
class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=0) 

if backupCount is zero and maxBytes is non-zero, the log file size could exceed maxBytes, i.e. we are not able to restrict the log file size using RotatingFileHandler at this case .
I suggest add the above description to the doc 
https://docs.python.org/3.6/library/logging.handlers.html#logging.handlers.RotatingFileHandler
If possible , set backupCount=1 by default to avoid this pitfall as much as possible.

The doc right now just says "if either of maxBytes or backupCount is zero, rollover never occurs.", it is too difficult to understand the meaning of 'Rollover' to aviod the pitfall .

----------
assignee: docs at python
components: Documentation
messages: 284277
nosy: docs at python, redstone-cold
priority: normal
severity: normal
status: open
title: code or doc improvement for logging.handlers.RotatingFileHandler
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec 29 18:39:07 2016
From: report at bugs.python.org (Loic Pefferkorn)
Date: Thu, 29 Dec 2016 23:39:07 +0000
Subject: [docs] [issue29109] Small doc improvements for tracemalloc
Message-ID: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za>


New submission from Loic Pefferkorn:

Hello,

I believe that some improvements can be made to the Python 3.4 documentation of the tracemalloc module:

* Wrong parameter name, 'group_by' instead of 'key_type' (checked in tracemalloc.py)
* Don't round up numbers when explaining the examples. If they exactly match what can be read in the script output, it is to easier to understand (4.8 MiB vs 4855 KiB)
* Fix incorrect method link that was pointing to another module

I will wait for some feedback before checking the 3.5, 3.6 versions, hopefully I did not forget something :)

Cheers,
Loic

----------
assignee: docs at python
components: Documentation
files: doc_3.4_tracemalloc.diff
keywords: patch
messages: 284298
nosy: docs at python, haypo, loicp
priority: normal
severity: normal
status: open
title: Small doc improvements for tracemalloc
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file46086/doc_3.4_tracemalloc.diff

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

From report at bugs.python.org  Thu Dec 29 20:15:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 01:15:54 +0000
Subject: [docs] [issue29109] Small doc improvements for tracemalloc
In-Reply-To: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za>
Message-ID: <20161230011543.3396.54435.9B5B8C76@psf.io>


Roundup Robot added the comment:

New changeset 192e0ae17236 by Victor Stinner in branch '3.5':
Issue #29109: Enhance tracemalloc documentation
https://hg.python.org/cpython/rev/192e0ae17236

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

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

From report at bugs.python.org  Thu Dec 29 20:17:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Dec 2016 01:17:26 +0000
Subject: [docs] [issue29109] Small doc improvements for tracemalloc
In-Reply-To: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za>
Message-ID: <1483060644.85.0.0337744722708.issue29109@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thank you for your contribution! I applied your patch to Python 3.5, 3.6 and default (future 3.7).

You should consider signing the PSF Contributor Agreement:
https://www.python.org/psf/contrib/contrib-form/

"While you retain the copyright, giving the PSF the ability to license your code means it can be put under the PSF license so it can be legally distributed with Python."

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

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

From report at bugs.python.org  Thu Dec 29 21:04:27 2016
From: report at bugs.python.org (Jesse Hall)
Date: Fri, 30 Dec 2016 02:04:27 +0000
Subject: [docs] [issue29112] questionable wording in sequences documentation
Message-ID: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za>


New submission from Jesse Hall:

In note 3 of 4.6.1, the word "string" should be replaced with "sequence", because the note is describing a general example where this concept is not specifically used with a string type sequence, it is discussing the general use of negative indexes which can be used on any type of sequence.

----------
assignee: docs at python
components: Documentation
messages: 284303
nosy: Jesse Hall, docs at python
priority: normal
severity: normal
status: open
title: questionable wording in sequences documentation
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec 29 23:01:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 04:01:49 +0000
Subject: [docs] [issue29112] questionable wording in sequences documentation
In-Reply-To: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za>
Message-ID: <20161230040146.80213.91471.231C69BA@psf.io>


Roundup Robot added the comment:

New changeset 0d20da97a6a0 by Xiang Zhang in branch '2.7':
Issue #29112: Fix a questionable wording in sequence doc.
https://hg.python.org/cpython/rev/0d20da97a6a0

New changeset f4b747f59804 by Xiang Zhang in branch '3.5':
Issue #29112: Fix a questionable wording in sequence doc.
https://hg.python.org/cpython/rev/f4b747f59804

New changeset b09d0a2587da by Xiang Zhang in branch '3.6':
Issue #29112: Merge 3.5.
https://hg.python.org/cpython/rev/b09d0a2587da

New changeset 4432cba89398 by Xiang Zhang in branch 'default':
Issue #29112: Merge 3.6.
https://hg.python.org/cpython/rev/4432cba89398

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

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

From report at bugs.python.org  Thu Dec 29 23:03:44 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 30 Dec 2016 04:03:44 +0000
Subject: [docs] [issue29112] questionable wording in sequences documentation
In-Reply-To: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za>
Message-ID: <1483070624.36.0.894207062384.issue29112@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your report Jesse. Now fixed.

----------
nosy: +xiang.zhang
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5, Python 3.7

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

From report at bugs.python.org  Fri Dec 30 00:23:24 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:23:24 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483075404.51.0.928511000404.issue28612@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I like the idea of adding a mapping example but don't want to encourage use of defaultdict in contexts like this one.  A defaultdict usefully specifies a default but has the unpleasant side-effect of altering the dictionary (adding new keys) during the look-up phase.  This has bitten a lot of people (including famous ones like Peter Norvig).

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

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

From report at bugs.python.org  Fri Dec 30 00:32:30 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:32:30 +0000
Subject: [docs] [issue29089] dictionary keys described incorrectly in
 tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1483075950.07.0.237139587953.issue29089@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm going to concur with the other respondents on this.  As a Python teacher, this is how I teach what should be used as a dictionary key.

While immutability and hashability aren't equivalent, it is a good first approximation.  Also, even though it is true that you could make a hashable object that is mutable, it is generally a bad practice that leads to regrets.

I'm going to close this.  If someone wants to change the styling of the tutorial, that can reasonably be discussed in another patch.

Thank you for your ideas, but we're going to pass on this one.  The tutorial is a place where it can be counter-productive to 1) make discussions too long, 2) go into atypical practices, 3) add too many caveats in a effort to be overly precise, etc.   Also, this part of the tutorial has been around for many years and has done a reasonably good job at educating its readers.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec 30 00:57:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Dec 2016 05:57:49 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483077469.37.0.75078631136.issue28612@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If the side effect of defaultdict is unpleasant, the correct way is combining the translation mapping with the custom mapping by ChainMap. But this example is too complex for the documentation of str.translate(). On other side, it is trivial for more experience users and don't need special mentioning.

I think other resources (ActiveState Code Reciepes [1] or books) are better places for this example.

[1] http://code.activestate.com/recipes/popular/

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

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

From report at bugs.python.org  Fri Dec 30 04:43:41 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 30 Dec 2016 09:43:41 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1483091021.3.0.232501504354.issue28816@psf.upfronthosting.co.za>


Decorater added the comment:

OK, Well I just tested and it sadly don't support import hooks that adds support for importing custom file types or file types python does know about with a uncommon extension inside of zip files which is somewhat sad. However if someone was to do something similar to py2exe's import hook allowing memory loading pyd and so files they could allow it to work for their import hook's needs.

----------
keywords: +patch
Added file: http://bugs.python.org/file46090/zipimport.rst.patch

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

From report at bugs.python.org  Fri Dec 30 15:15:33 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Fri, 30 Dec 2016 20:15:33 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483128933.67.0.601009793562.issue28612@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hi,

Pardon my ignorance, I am new to this but have below queries/thoughts -

1. Why would we say that adding new keys during lookup phase is an unpleasant side-effect? From what I understood by docs, one of the main reasons to use defaultdicts is to be able to insert a missing key and give a default value to it. 'defaultdict' doc itself suggest that doing this is cleaner and faster than using dict.setdefault().

2. I believe defaultdict perfectly fits in this context of creating translation table for str.translate(). Even if we have very large string containing all characters from 4-5 languages, our defaultdict will still be comparatively small. It is easier to create a translation table using defaultdict when we have to strip most characters out of a string as in the example requested in the issue. Creating a translation table using str.maketrans() or by user defined function is tricky in this use case.

3. If argument for using defaultdict in this context is not convincing, shall I just give a patch, giving example of str.translate() using str.maketranse()?

Regards,

----------

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

From report at bugs.python.org  Fri Dec 30 15:18:00 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Fri, 30 Dec 2016 20:18:00 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483129079.93.0.769410977765.issue28612@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Should a user be suggested to use str.translate() for the use case where user only wants to keep certain characters and strip off everything else?

----------

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

From report at bugs.python.org  Fri Dec 30 18:40:16 2016
From: report at bugs.python.org (Christopher Barker)
Date: Fri, 30 Dec 2016 23:40:16 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1483129079.93.0.769410977765.issue28612@psf.upfronthosting.co.za>
Message-ID: <CALGmxE+8mFWMFKOsHaCf_ok7K-uqR-Z8L0F-jqcC1XMepoPd7w@mail.gmail.com>


Christopher Barker added the comment:

This all came out of a thread on python-ideas, starting here:

https://mail.python.org/pipermail/python-ideas/2016-October/043284.html

the thread kind of petered out, but it seems there was a kinda-sorta
consensus that we didn't need any new string methods, but rather same notes
in the docs on how to to use .translate() to remove "all but these" was in
order.

And the defaultdict method was proposed as the easiest / most pythonic.

As it happens, I did't live the fact hat defaultdict will build up a
big(ish) dict of Nones for no reason, and thus suggested a NoneDict option:

class NoneDict(dict):
    """
    Dictionary implementation that always returns None when a key is not in
the dict,
    rather than raising a KeyError
    """
    def __getitem__(self, key):
        try:
            val = dict.__getitem__(self, key)
        except KeyError:
            val = None
        return val

Though maybe that's a bit much for the docs.

However, in short:

either the defaultdict approach is siple and pythonic enough to be in teh
docs, or we SHOULD add something new to the string object.

(or maybe someone has another nifty pythonic way to do this with the stdlib
that's better than defaultdict?)

-CHB

On Fri, Dec 30, 2016 at 12:18 PM, Gaurav Tatke <report at bugs.python.org>
wrote:

>
> Gaurav Tatke added the comment:
>
> Should a user be suggested to use str.translate() for the use case where
> user only wants to keep certain characters and strip off everything else?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28612>
> _______________________________________
>

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

----------
nosy: +Chris.Barker

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

From report at bugs.python.org  Fri Dec 30 20:03:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 01:03:30 +0000
Subject: [docs] [issue29098] document minimum sqlite version
In-Reply-To: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za>
Message-ID: <1483146210.42.0.743912068247.issue29098@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec 30 20:16:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 01:16:35 +0000
Subject: [docs] [issue29105] code or doc improvement for
 logging.handlers.RotatingFileHandler
In-Reply-To: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za>
Message-ID: <1483146995.66.0.689349321375.issue29105@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat Dec 31 02:58:21 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 31 Dec 2016 07:58:21 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1483171101.65.0.377037384955.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

May I commit merge-hashlib-blake2.patch to 3.6 branch?

----------

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

From report at bugs.python.org  Sat Dec 31 03:02:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 08:02:24 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1483171344.42.0.914337813505.issue29062@psf.upfronthosting.co.za>


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


----------
nosy: +martin.panter, r.david.murray

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

From report at bugs.python.org  Sat Dec 31 06:07:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 11:07:48 +0000
Subject: [docs] [issue29105] code or doc improvement for
 logging.handlers.RotatingFileHandler
In-Reply-To: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za>
Message-ID: <20161231110743.25791.8083.F66F9A17@psf.io>


Roundup Robot added the comment:

New changeset 4255c7aae85b by Vinay Sajip in branch '3.6':
Closes #29105: Updated RotatingFileHandler documentation.
https://hg.python.org/cpython/rev/4255c7aae85b

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

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

From amikeysanders at gmail.com  Wed Dec 28 19:10:20 2016
From: amikeysanders at gmail.com (Lil' Drummer Boy)
Date: Wed, 28 Dec 2016 19:10:20 -0500
Subject: [docs] Bug in Path from pathlib
Message-ID: <CACWCx7hNMfZAXhWkJkpVShaNQC8T9QD=TRyyUA=PFNt8v4kngA@mail.gmail.com>

Hi,

Going through the basics at https://docs.python.org/3/library/pathlib.html ,
I encountered an issue.

In Basic Use, 11.1.1, Querying Path Properties: , for some reason the
answer was false whenever
q.exists() was typed in the python 3.6.0 interpreter.

Any help would be appreciated.

Thanks,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161228/688632f1/attachment.html>

From report at bugs.python.org  Sat Dec 31 12:06:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 17:06:59 +0000
Subject: [docs] [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <20161231170655.123564.75350.27A834C8@psf.io>


Roundup Robot added the comment:

New changeset 1a25c639f81e by Berker Peksag in branch '3.5':
Issue #26267: Improve uuid.UUID documentation
https://hg.python.org/cpython/rev/1a25c639f81e

New changeset c9e944cc6301 by Berker Peksag in branch '3.6':
Issue #26267: Merge from 3.5
https://hg.python.org/cpython/rev/c9e944cc6301

New changeset 8b19c2a1b197 by Berker Peksag in branch 'default':
Issue #26267: Merge from 3.6
https://hg.python.org/cpython/rev/8b19c2a1b197

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

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

From report at bugs.python.org  Sat Dec 31 12:07:33 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 17:07:33 +0000
Subject: [docs] [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1483204053.61.0.0351452678717.issue26267@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Ammar.

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

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

From report at bugs.python.org  Sat Dec 31 21:44:14 2016
From: report at bugs.python.org (Eric Ahn)
Date: Sun, 01 Jan 2017 02:44:14 +0000
Subject: [docs] [issue29127] Incorrect reference names in asyncio.subprocess
 documentation
Message-ID: <1483238654.05.0.408550900872.issue29127@psf.upfronthosting.co.za>


New submission from Eric Ahn:

On this page of the documentation https://docs.python.org/3/library/asyncio-subprocess.html it seems that some of the reference names are incorrect.

Namely, asyncio.subprocess.PIPE is referred to as asyncio.asyncio.subprocess.PIPE (along with STDOUT and DEVNULL), plus asyncio.subprocess.Process is referred to as asyncio.asyncio.subprocess.Process.

This is reflected in the permalinks as well as when one tries to reference these via intersphinx (which is how I discovered it; I was trying to link to this page and was failing).

----------
assignee: docs at python
components: Documentation
messages: 284418
nosy: Eric Ahn, docs at python
priority: normal
severity: normal
status: open
title: Incorrect reference names in asyncio.subprocess documentation
versions: Python 3.6

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

From report at bugs.python.org  Sat Dec 31 22:19:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 Jan 2017 03:19:52 +0000
Subject: [docs] [issue28911] Clarify the behaviour of assert_called_once_with
In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>
Message-ID: <1483240792.5.0.05790576679.issue28911@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag, michael.foord -153957
stage:  -> patch review
type: enhancement -> behavior
versions:  -Python 3.3, Python 3.4

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

From cbarry at symbiaudix.com  Sat Dec 31 15:17:55 2016
From: cbarry at symbiaudix.com (Christopher Barry)
Date: Sat, 31 Dec 2016 15:17:55 -0500
Subject: [docs] reference doc problem
Message-ID: <20161231151755.68228616@monolith.infinux.org>


https://docs.python.org/3.5/reference/lexical_analysis.html#keywords

describes 'is' as a keyword, yet

https://docs.python.org/3.5/reference/datamodel.html#objects-values-and-types

describes 'is' as an operator.

Which is it? If it really is an operator (too?), shouldn't it be here:

https://docs.python.org/3.5/reference/lexical_analysis.html#operators

as well?

-- 
Regards,
Christopher Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/docs/attachments/20161231/656bef81/attachment.sig>