From report at bugs.python.org  Tue Mar  1 00:37:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 01 Mar 2016 05:37:24 +0000
Subject: [docs] [issue26462] Patch to enhance literal block language
 declaration
In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za>
Message-ID: <1456810644.35.0.527650887195.issue26462@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6

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

From report at bugs.python.org  Tue Mar  1 01:00:34 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 01 Mar 2016 06:00:34 +0000
Subject: [docs] [issue26462] Patch to enhance literal block language
 declaration
In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za>
Message-ID: <1456812034.1.0.0443399018473.issue26462@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks for the patch!

Most "bash" blocks should be "console" (since the prompt is shown). "pycon" should not be needed, since it is detected automatically.

----------

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

From report at bugs.python.org  Tue Mar  1 03:34:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 01 Mar 2016 08:34:20 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1456821259.99.0.68909645096.issue23921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

James, could you please update your patch to address Martin's comments? In general the patch LGTM and I hope to commit it in short time.

----------
nosy: +georg.brandl
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Tue Mar  1 16:25:47 2016
From: report at bugs.python.org (Julien)
Date: Tue, 01 Mar 2016 21:25:47 +0000
Subject: [docs] [issue26462] Patch to enhance literal block language
 declaration
In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za>
Message-ID: <1456867541.25.0.286278042811.issue26462@psf.upfronthosting.co.za>


Julien added the comment:

I revewed all my ".. code-block:: bash" and you're right (I was unaware of the existence of the "console" lexer). I changed them (reviewing them one by one) to ".. code-block:: shell-session", a synonym for ".. code-block:: console" (http://pygments.org/docs/lexers/?highlight=console#pygments.lexers.shell.BashSessionLexer) which I find, in a Python context, semantically more precise, and less ambigious, as one may read "console" as "the repl" (I assume most writers of the doc are aware of commonly used pygment lexers, it's still better for newcomers to be explicit and readable).

For your other point, about pycon being automatically detected, I tried removeing them and it works, I was sure I was adding them only where the python3 parser was reporting an error (was fixing errors one by one). I keeped the explicit pycon lexer in the "Doc/extending/extending.rst" file which have a ".. highlightlang:: c".

Here is the new patch, and thanks for this usefull review !

----------
Added file: http://bugs.python.org/file42057/literal_blocks_languages.patch

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

From report at bugs.python.org  Tue Mar  1 16:38:49 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 01 Mar 2016 21:38:49 +0000
Subject: [docs] [issue26462] Patch to enhance literal block language
 declaration
In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za>
Message-ID: <1456868325.85.0.860116862352.issue26462@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Attaching regenerated patch to coax Rietveld into accepting it for easier review.

----------
nosy: +zach.ware
Added file: http://bugs.python.org/file42058/issue26462_regen.diff

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

From zachary.ware at gmail.com  Tue Mar  1 17:15:32 2016
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Tue, 01 Mar 2016 22:15:32 -0000
Subject: [docs] Patch to enhance literal block language declaration (issue
 26462)
Message-ID: <20160301221532.8472.98302@psf.upfronthosting.co.za>

LGTM, just one minor nit.


http://bugs.python.org/review/26462/diff/16666/Doc/whatsnew/3.2.rst
File Doc/whatsnew/3.2.rst (right):

http://bugs.python.org/review/26462/diff/16666/Doc/whatsnew/3.2.rst#newcode2048
Doc/whatsnew/3.2.rst:2048: .. code-block:: none
This can be 'doscon' instead of 'none'.

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

From georg at python.org  Wed Mar  2 01:21:37 2016
From: georg at python.org (georg at python.org)
Date: Wed, 02 Mar 2016 06:21:37 -0000
Subject: [docs] Patch to enhance literal block language declaration
 (issue 26462)
Message-ID: <20160302062137.5160.41715@psf.upfronthosting.co.za>


http://bugs.python.org/review/26462/diff/16666/Doc/extending/embedding.rst
File Doc/extending/embedding.rst (right):

http://bugs.python.org/review/26462/diff/16666/Doc/extending/embedding.rst#newcode296
Doc/extending/embedding.rst:296: .. code-block:: shell-session
Here (and below) the ".. code-block" should be indented two spaces to be
within the bullet list item.

http://bugs.python.org/review/26462/diff/16666/Doc/library/logging.config.rst
File Doc/library/logging.config.rst (right):

http://bugs.python.org/review/26462/diff/16666/Doc/library/logging.config.rst#newcode419
Doc/library/logging.config.rst:419: formatters:
This seems to be YAML as well?

http://bugs.python.org/review/26462/diff/16666/Doc/library/logging.config.rst#newcode703
Doc/library/logging.config.rst:703: [handler_hand02]
This could use the ini lexer.

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

From report at bugs.python.org  Wed Mar  2 01:21:51 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Mar 2016 06:21:51 +0000
Subject: [docs] [issue26462] Patch to enhance literal block language
 declaration
In-Reply-To: <1456790330.71.0.936150839602.issue26462@psf.upfronthosting.co.za>
Message-ID: <1456899711.49.0.775220414171.issue26462@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks good now! I left a few comments on Rietveld.

----------

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

From georg at python.org  Wed Mar  2 02:04:03 2016
From: georg at python.org (georg at python.org)
Date: Wed, 02 Mar 2016 07:04:03 -0000
Subject: [docs] Standardize documentation whitespace,
 formatting (issue 23921)
Message-ID: <20160302070403.14531.55084@psf.upfronthosting.co.za>


http://bugs.python.org/review/23921/diff/14579/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/faq/programming.rst#newcode668
Doc/faq/programming.rst:668: >>> print(b)
On 2016/01/07 02:41:26, vadmium wrote:
> Why not add prompts to the lines above as well?

Yes, link this it's a bit inconsistent.

http://bugs.python.org/review/23921/diff/14579/Doc/howto/logging-cookbook.rst
File Doc/howto/logging-cookbook.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/howto/logging-cookbook.rst#newcode742
Doc/howto/logging-cookbook.rst:742: root.setLevel(logging.DEBUG)  # send
all messages, for demo; no other level or filter logic applied.
this is probably too long a line (e.g. for PDF output), better move the
comment above the code

http://bugs.python.org/review/23921/diff/14579/Doc/howto/urllib2.rst
File Doc/howto/urllib2.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/howto/urllib2.rst#newcode178
Doc/howto/urllib2.rst:178: values = {'name' : 'Michael Foord',
could also remove the spaces before ':' as well.

http://bugs.python.org/review/23921/diff/14579/Doc/library/locale.rst
File Doc/library/locale.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/locale.rst#newcode473
Doc/library/locale.rst:473: >>> locale.strcoll('f\xe4n', 'foo')       #
compare a string containing an umlaut
keep only 2 spaces, the line is already long

http://bugs.python.org/review/23921/diff/14579/Doc/library/multiprocessing.rst
File Doc/library/multiprocessing.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/multiprocessing.rst#newcode2071
Doc/library/multiprocessing.rst:2071: print(result.get(timeout=1))      
  # prints "100" unless your computer is *very* slow
these lines are also too long.

http://bugs.python.org/review/23921/diff/14579/Doc/library/optparse.rst
File Doc/library/optparse.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/optparse.rst#newcode1827
Doc/library/optparse.rst:1827: [...]
replace by a single ellipsis, I don't think we're using that style
anywhere else

http://bugs.python.org/review/23921/diff/14579/Doc/library/tokenize.rst
File Doc/library/tokenize.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/tokenize.rst#newcode216
Doc/library/tokenize.rst:216: if toknum == NUMBER and '.' in tokval:    
    # replace NUMBER tokens
no, keep shorter line

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

http://bugs.python.org/review/23921/diff/14579/Doc/library/urllib.request.rst#newcode1105
Doc/library/urllib.request.rst:1105: ...                             
data=b'This data is passed to stdin of the CGI')
this is also a case where the longer line may hurt

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst
File Doc/whatsnew/3.2.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1540
Doc/whatsnew/3.2.rst:1540: >>> os.chdir('mydata')                       
       # change to the source directory
again, too long lines here.

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

From report at bugs.python.org  Wed Mar  2 02:04:33 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Mar 2016 07:04:33 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1456902272.86.0.311419852047.issue23921@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I had no idea we had so many cases of wonky indentation :)

This looks good to me, apart from a few comments I left on rietveld.

----------

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

From report at bugs.python.org  Wed Mar  2 06:26:37 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Mar 2016 11:26:37 +0000
Subject: [docs] [issue26468] shutil.copy2 raises OSError if filesystem
 doesn't support chmod
In-Reply-To: <1456910519.95.0.44073308632.issue26468@psf.upfronthosting.co.za>
Message-ID: <1456917997.4.0.103754023377.issue26468@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree that copy2 should not fail because chmod fails. Could you please provide the entire traceback message when it fails (on both 2.7 and 3.4 or 3.5)? And what OS are you running on, and what filesystem?

It looks like the error happens because errno=95 (EOPNOTSUPP, probably) isn't in the list of errors that _copyxattr catches, while (ENOTSUP=134 on Linux) is.

I think the documentation is also incorrect. Of course copy2 can fail: what about out of disk space? I think the documentation is trying to say that copy2 never fails because it can't preserve metadata. And the wording in the docs "copy2() never returns failure" is also odd, it should say "copy2() never raises an exception because it cannot preserve file metadata".

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eric.smith

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

From report at bugs.python.org  Wed Mar  2 07:33:26 2016
From: report at bugs.python.org (=?utf-8?q?Vojt=C4=9Bch_Pachol?=)
Date: Wed, 02 Mar 2016 12:33:26 +0000
Subject: [docs] [issue26468] shutil.copy2 raises OSError if filesystem
 doesn't support chmod
In-Reply-To: <1456910519.95.0.44073308632.issue26468@psf.upfronthosting.co.za>
Message-ID: <1456922006.43.0.235549868357.issue26468@psf.upfronthosting.co.za>


Vojt?ch Pachol added the comment:

Actually it is a remote fs mounted via samba. OS is Linux.

Tracebacks with Python versions I have:

$ python2.7
Python 2.7.11 (default, Jan 11 2016, 21:04:40) 
[GCC 5.3.1 20160101] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2("src", "dst")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/shutil.py", line 131, in copy2
    copystat(src, dst)
  File "/usr/lib/python2.7/shutil.py", line 100, in copystat
    os.chmod(dst, mode)
OSError: [Errno 95] Operation not supported: 'dst'
>>> 
$ python3.4
Python 3.4.4 (default, Jan  5 2016, 15:35:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2("src", "dst")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/shutil.py", line 246, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.4/shutil.py", line 191, in copystat
    lookup("chmod")(dst, mode, follow_symlinks=follow)
OSError: [Errno 95] Operation not supported: 'dst'
>>> 
$ python3.5
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2("src", "dst")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/shutil.py", line 252, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.5/shutil.py", line 197, in copystat
    lookup("chmod")(dst, mode, follow_symlinks=follow)
OSError: [Errno 95] Operation not supported: 'dst'
>>>

----------

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

From report at bugs.python.org  Wed Mar  2 12:40:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Mar 2016 17:40:36 +0000
Subject: [docs] [issue26246] Code output toggle button uses removed jQuery
 method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <20160302174025.60696.76443@psf.io>


Roundup Robot added the comment:

New changeset 7444bdd400cd by Berker Peksag in branch '3.4':
Issue #26246: Set initial value of the hidden attr when creating copy button.
https://hg.python.org/cpython/rev/7444bdd400cd

New changeset 256339c28d42 by Berker Peksag in branch '3.5':
Issue #26246: Set initial value of the hidden attr when creating copy button.
https://hg.python.org/cpython/rev/256339c28d42

New changeset 3e897eef0fac by Berker Peksag in branch 'default':
Issue #26246: Set initial value of the hidden attr when creating copy button.
https://hg.python.org/cpython/rev/3e897eef0fac

----------

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

From report at bugs.python.org  Wed Mar  2 12:43:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Mar 2016 17:43:49 +0000
Subject: [docs] [issue26246] Code output toggle button uses removed jQuery
 method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <20160302174344.89276.27013@psf.io>


Roundup Robot added the comment:

New changeset 305ae007899b by Berker Peksag in branch '2.7':
Issue #26246: Set initial value of the hidden attr when creating copy button.
https://hg.python.org/cpython/rev/305ae007899b

----------

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

From report at bugs.python.org  Wed Mar  2 12:44:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 02 Mar 2016 17:44:20 +0000
Subject: [docs] [issue26246] Code output toggle button uses removed jQuery
 method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <1456940660.35.0.673454125648.issue26246@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, thanks!

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

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

From abdulrhmanalfheem at yahoo.com  Wed Mar  2 17:02:49 2016
From: abdulrhmanalfheem at yahoo.com (Abdulrhman Alfheem)
Date: Wed, 2 Mar 2016 22:02:49 +0000 (UTC)
Subject: [docs] Download
References: <999103047.2517082.1456956169112.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <999103047.2517082.1456956169112.JavaMail.yahoo@mail.yahoo.com>

Hello 
Could you show me the steps of how can I download phython language programme in my laptop because it tried many time but there is no results

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

From report at bugs.python.org  Fri Mar  4 08:14:18 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Fri, 04 Mar 2016 13:14:18 +0000
Subject: [docs] [issue26479] Init documentation typo "may be return" > "may
 NOT be returned"
Message-ID: <1457097258.8.0.064409213234.issue26479@psf.upfronthosting.co.za>


New submission from Samuel Colvin:

https://docs.python.org/3/reference/datamodel.html#object.__init__

"no non-None value may be returned by __init__();" should read "no non-None value may *not* be returned by __init__();"

----------
assignee: docs at python
components: Documentation
messages: 261185
nosy: Samuel Colvin, docs at python
priority: normal
severity: normal
status: open
title: Init documentation typo "may be return" > "may NOT be returned"
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar  4 08:23:15 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 04 Mar 2016 13:23:15 +0000
Subject: [docs] [issue26479] Init documentation typo "may be return" > "may
 NOT be returned"
In-Reply-To: <1457097258.8.0.064409213234.issue26479@psf.upfronthosting.co.za>
Message-ID: <1457097795.53.0.448274692542.issue26479@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The text appears to be correct as it is. What is says is that __init__ must not return any value other than None and that is correct, you will get an exception when you return a value that is not None.

>>> class C():
...    def __init__(self): return 42
... 
>>> 
>>> C()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() should return None, not 'int'
>>> 

The text is basically a language-lawyer way of stating that __init__ should return by either running of the end of the method, or by using a bare return statement.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Fri Mar  4 15:09:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Mar 2016 20:09:50 +0000
Subject: [docs] [issue26459] Windows build instructions are very inaccurate
In-Reply-To: <1456756322.44.0.126364143286.issue26459@psf.upfronthosting.co.za>
Message-ID: <1457122190.33.0.76494585893.issue26459@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I built 2.7.11 on Win10 last Jan 16 with MCS v.1500 32 bit.  I believe that is VS2008.  Besides TortoiseHG, which I think is great, I downloaded SlikSVN minimal client only.  I somewhat arbitrarily picked it from some svn list.  http://www.sliksvn.com/en/download.  A suggestion, with note that minimal client is enough, would not help.  Tested install with 'svn help'. With that installed, pcbuild + appropriate args downloads all external dependencies needed.  F7 in VS GUI builds Python binary, no Perl needed.  The docs, including readme.TXT, are much better than 3 or 4 years ago.  (At the time, there was an undocumented requirement, to run tkinter, to move/copy some tcl/tk files.  Zack fixed the build script to make manual step unneeded.)  Obviously still needs improvement.

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

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

From report at bugs.python.org  Fri Mar  4 15:19:34 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Mar 2016 20:19:34 +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: <1457122774.31.0.0483971039327.issue26483@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, Unicode
nosy: +docs at python, ezio.melotti, haypo
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

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

From report at bugs.python.org  Fri Mar  4 15:20:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Mar 2016 20:20:12 +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: <1457122811.99.0.255573038045.issue26483@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> chars = ''.join(map(chr, range(sys.maxunicode+1)))
>>> digits = ''.join(filter(str.isdigit, chars))
>>> digits
'0123456789????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????'
>>> decimals = ''.join(filter(str.isdecimal, chars))
>>> decimals
'0123456789????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????'
>>> ''.join(sorted(set(decimals) - set(digits)))
''
>>> ''.join(sorted(set(digits) - set(decimals)))
'????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????'

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

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

From report at bugs.python.org  Fri Mar  4 15:35:29 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 04 Mar 2016 20:35:29 +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: <1457123729.15.0.825878866743.issue26483@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I like those code snippets!  Thanks, Serhiy!

Just to make sure I have understood correctly:  every decimal char is also a digit char, but some digit chars are not decimal chars.

----------

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

From report at bugs.python.org  Fri Mar  4 16:02:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Mar 2016 21:02:07 +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: <1457125327.62.0.151321027442.issue26483@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes. For details you need to read The Unicode Standard.

And every decimal character is accepted by the int() constructor, but non-decimal digits are not.

>>> for d in decimals: x = int(d)
... 
>>> for d in set(digits) - set(decimals):
...     try:
...         int(d)
...     except ValueError:
...         pass
...     else:
...         raise AssertionError
...

----------

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

From report at bugs.python.org  Fri Mar  4 18:59:01 2016
From: report at bugs.python.org (Julien)
Date: Fri, 04 Mar 2016 23:59:01 +0000
Subject: [docs] [issue26484] Broken table in
 /2.7/library/sets.html#set-objects
Message-ID: <1457135941.69.0.584697860353.issue26484@psf.upfronthosting.co.za>


New submission from Julien:

Hi,

Since: https://github.com/python/cpython/commit/5fdcdab5794d18adc4c66abdce8639440433ed24#diff-c191394dee92fb4800d40d9a8ba431ee

the table is broken (...Doc/library/sets.rst:76: ERROR: Malformed table.                                                                                                       ) so it is no longer displayed here: https://docs.python.org/2.7/library/sets.html#set-objects

Bests

----------
assignee: docs at python
components: Documentation
messages: 261202
nosy: docs at python, gregory.p.smith, sizeof
priority: normal
severity: normal
status: open
title: Broken table in /2.7/library/sets.html#set-objects
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar  4 19:14:52 2016
From: report at bugs.python.org (Julien)
Date: Sat, 05 Mar 2016 00:14:52 +0000
Subject: [docs] [issue26485] Missing newline, raising a warning,
 in /Doc/license.rst
Message-ID: <1457136892.69.0.383889491062.issue26485@psf.upfronthosting.co.za>


New submission from Julien:

o/

While fixing sphinx-doc warnings, I found this missing newline.

Yet the documentation is still correctly rendered.

----------
assignee: docs at python
components: Documentation
files: missing_newline_in_licence.rst
messages: 261204
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Missing newline, raising a warning, in /Doc/license.rst
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file42070/missing_newline_in_licence.rst

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

From report at bugs.python.org  Fri Mar  4 19:19:45 2016
From: report at bugs.python.org (Julien)
Date: Sat, 05 Mar 2016 00:19:45 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1457137185.63.0.53162377895.issue25907@psf.upfronthosting.co.za>


Changes by Julien <python at mandark.fr>:


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

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

From report at bugs.python.org  Fri Mar  4 19:32:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Mar 2016 00:32:57 +0000
Subject: [docs] [issue26484] Broken table in
 /2.7/library/sets.html#set-objects
In-Reply-To: <1457135941.69.0.584697860353.issue26484@psf.upfronthosting.co.za>
Message-ID: <20160305003254.20953.21453@psf.io>


Roundup Robot added the comment:

New changeset f7a2f81a190c by Gregory P. Smith in branch '2.7':
issue26484 - fix the broken table in the doc about len().
https://hg.python.org/cpython/rev/f7a2f81a190c

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

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

From report at bugs.python.org  Fri Mar  4 19:37:04 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Mar 2016 00:37:04 +0000
Subject: [docs] [issue26484] Broken table in
 /2.7/library/sets.html#set-objects
In-Reply-To: <1457135941.69.0.584697860353.issue26484@psf.upfronthosting.co.za>
Message-ID: <1457138224.8.0.90636866876.issue26484@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

thanks for reporting this!

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

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

From report at bugs.python.org  Fri Mar  4 21:23:34 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 05 Mar 2016 02:23:34 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1457144614.52.0.752284354363.issue25907@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> resolved

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

From report at bugs.python.org  Sat Mar  5 06:55:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Mar 2016 11:55:04 +0000
Subject: [docs] [issue26485] Missing newline, raising a warning,
 in /Doc/license.rst
In-Reply-To: <1457136892.69.0.383889491062.issue26485@psf.upfronthosting.co.za>
Message-ID: <20160305115501.116279.77177@psf.io>


Roundup Robot added the comment:

New changeset f69b777b3b3e by Berker Peksag in branch '2.7':
Issue #26485: Fix Sphinx warning in Doc/license.rst
https://hg.python.org/cpython/rev/f69b777b3b3e

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

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

From report at bugs.python.org  Sat Mar  5 06:56:29 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 05 Mar 2016 11:56:29 +0000
Subject: [docs] [issue26485] Missing newline, raising a warning,
 in /Doc/license.rst
In-Reply-To: <1457136892.69.0.383889491062.issue26485@psf.upfronthosting.co.za>
Message-ID: <1457178989.16.0.390811854067.issue26485@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Julien!

For the record, here is the warning:

Doc/license.rst:350: WARNING: Literal block ends without a blank line; unexpected unindent.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior

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

From report at bugs.python.org  Sun Mar  6 10:19:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 06 Mar 2016 15:19:24 +0000
Subject: [docs] [issue21034] Python docs reference the Distribute package
 which has been deprecated in favor of Setuptools
In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za>
Message-ID: <1457277564.2.0.810442473528.issue21034@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think it would be better to just remove the following part from the documentation:

"Of course, you need to install them into the venv first: this could be done by running ez_setup.py with the venv activated, followed by running easy_install pip. Alternatively, you could download the source tarballs and run python setup.py install after unpacking, with the venv activated."

Here is a patch.

----------
nosy: +berker.peksag, vinay.sajip
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42078/issue21034.diff

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

From report at bugs.python.org  Sun Mar  6 17:58:26 2016
From: report at bugs.python.org (Alessandro Molina)
Date: Sun, 06 Mar 2016 22:58:26 +0000
Subject: [docs] [issue26497] Documentation - HOWTO Use Python in the web
 paragraph on TurboGears still mentions it's based on Pylons
Message-ID: <1457305106.46.0.783108408481.issue26497@psf.upfronthosting.co.za>


New submission from Alessandro Molina:

https://docs.python.org/3.6/howto/webservers.html#turbogears still mentions "TurboGears 2 is based on the WSGI stack of another popular component-based web framework, Pylons." which is not true anymore since TurboGears 2.3.0.

TurboGears switched to its own micro-framework core since version 2.3.0 as Pylons wasn't Python3 compatible.

Also The TGBook is still mentioned even though it's 10 years old and not reliable anymore since TurboGears 1.0

----------
assignee: docs at python
components: Documentation
messages: 261274
nosy: Alessandro Molina, docs at python
priority: normal
severity: normal
status: open
title: Documentation - HOWTO Use Python in the web paragraph on TurboGears still mentions it's based on Pylons
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Mar  6 18:21:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Mar 2016 23:21:06 +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: <1457306466.94.0.072028074757.issue26483@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation could certainly be clarified to say that all decimals, as determined by isdecimal(), are also digits as determined by isdigit(). IMO the current documentation is confusing or wrong to stay that decimals ?include digit characters?; it is actually the other way around.

I think it could also be clearer about how ?general category ?Nd? ? and ?the property value Numeric_Type=Digit or Numeric_Type=Decimal? are related (if they are indeed related).

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

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

From report at bugs.python.org  Sun Mar  6 19:15:13 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Mar 2016 00:15:13 +0000
Subject: [docs] [issue26497] Documentation - HOWTO Use Python in the web
 paragraph on TurboGears still mentions it's based on Pylons
In-Reply-To: <1457305106.46.0.783108408481.issue26497@psf.upfronthosting.co.za>
Message-ID: <1457309713.14.0.987185681146.issue26497@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. Actually, the whole document is outdated. I think we can mark this as a duplicate of issue 24852.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix

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

From report at bugs.python.org  Sun Mar  6 19:20:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Mar 2016 00:20:14 +0000
Subject: [docs] [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web"
 needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <1457310014.75.0.945690384251.issue24852@psf.upfronthosting.co.za>


Berker Peksag added the comment:

See issue 26497 for another report about this. I will remove Doc/howto/webservers.rst.

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

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

From report at bugs.python.org  Mon Mar  7 00:57:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Mar 2016 05:57:20 +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: <1457330239.92.0.745338711267.issue26483@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

AFAIK ?general category ?Nd? ? is the same as ?the property value Numeric_Type=Decimal?.

Yet one related predicate is str.isnumeric().

https://docs.python.org/3/library/stdtypes.html?#str.isnumeric

Return true if all characters in the string are numeric characters, and there is at least one character, false otherwise. Numeric characters include digit characters, and all characters that have the Unicode numeric value property, e.g. U+2155, VULGAR FRACTION ONE FIFTH. Formally, numeric characters are those with the property value Numeric_Type=Digit, Numeric_Type=Decimal or Numeric_Type=Numeric.

>>> numerics = ''.join(filter(str.isnumeric, chars))
>>> ''.join(sorted(set(digits) - set(numerics)))
''
>>> ''.join(sorted(set(numerics) - set(digits)))
'????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????'

decimals is a subset of digits, and digits is a subset of numerics.

----------

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

From report at bugs.python.org  Mon Mar  7 04:19:27 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Mar 2016 09:19:27 +0000
Subject: [docs] [issue21034] Python docs reference the Distribute package
 which has been deprecated in favor of Setuptools
In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za>
Message-ID: <1457342366.99.0.65303432481.issue21034@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 from me for just removing the bootstrapping instructions from this note.

(The original reference to Distribute has already been replaced with a reference to Setuptools at some point since Jurko filed this issue)

----------

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

From report at bugs.python.org  Mon Mar  7 05:22:15 2016
From: report at bugs.python.org (Jaivish Kothari)
Date: Mon, 07 Mar 2016 10:22:15 +0000
Subject: [docs] [issue26500] Document of star operator missing. It must be
 documented for better understanding.
Message-ID: <1457346135.37.0.589425731268.issue26500@psf.upfronthosting.co.za>


New submission from Jaivish Kothari:

Star operator in python for unpacking could be documented for better understanding.

----------
assignee: docs at python
components: Documentation
messages: 261288
nosy: docs at python, janonymous
priority: normal
severity: normal
status: open
title: Document of star operator missing. It must be documented for better understanding.
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar  7 05:45:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 07 Mar 2016 10:45:35 +0000
Subject: [docs] [issue26500] Document of star operator missing. It must be
 documented for better understanding.
In-Reply-To: <1457346135.37.0.589425731268.issue26500@psf.upfronthosting.co.za>
Message-ID: <1457347535.74.0.338225852369.issue26500@psf.upfronthosting.co.za>


Martin Panter added the comment:

Previous report: Issue 19024.

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

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

From report at bugs.python.org  Mon Mar  7 06:15:48 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 07 Mar 2016 11:15:48 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
Message-ID: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

According to the docs [0], traceback.extract_tb should return 4-tuples (filename, line number, function name, text).

[0] https://docs.python.org/3/library/traceback.html#traceback.extract_tb

Instead, since Python 3.5, it returns FrameSummary objects, which are not tuples, nor tuple subclasses, nor even sequences. (This broke some code in the wild that called len() on FrameSummary.)

Issue 25111 pointed out another tuple incompatibility, which was fixed. Should __len__ be added as well? Or the whole Sequence ABC?

I can provide a patch when those questions are answered.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 261296
nosy: docs at python, encukou
priority: normal
severity: normal
status: open
title: traceback.extract_tb breaks compatibility by returning FrameSummary
versions: Python 3.5, Python 3.6

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

From danielcoates27 at gmail.com  Sun Mar  6 12:20:18 2016
From: danielcoates27 at gmail.com (danielcoates27 at gmail.com)
Date: Sun, 6 Mar 2016 17:20:18 +0000
Subject: [docs] bugs
Message-ID: <56dc66d1.42121c0a.451a9.ffffecbb@mx.google.com>

I downloaded python 3.3.1 and it worked fine yesterday march 6th but now it keeps saying
I downloaded python 3.3.1 and it worked fine yester day but today it says IDLE?s subprocess didn?t make a connection.
Sent from Mail for Windows 10

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

From jacko21 at aliceadsl.fr  Mon Mar  7 10:54:36 2016
From: jacko21 at aliceadsl.fr (Jacques)
Date: Mon, 7 Mar 2016 16:54:36 +0100
Subject: [docs] Python documentation : some points requiring attention
 v.3.5.1
In-Reply-To: <54399D3F.5030503@aliceadsl.fr>
References: <54399D3F.5030503@aliceadsl.fr>
Message-ID: <56DDA43C.2000500@aliceadsl.fr>

Hello,

First, I want to thank you again for the useful and clear documentation 
of Python.

Beeing a fanatic reader of it, sometimes I encounter some mistake (or it 
seems to me it is such). If this could bring some help, you will find in 
the attached file a list of points requiring attention. Some of them are 
only grammatical typos, the others are more interesting (I hope!).

All the comments concern the official standard documentation of Python 
3.5.1.

With best regards.

Jacques Ducasse
FRANCE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PythonDocErreurs160307.pdf
Type: application/pdf
Size: 73431 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20160307/80dd8833/attachment-0001.pdf>

From report at bugs.python.org  Mon Mar  7 11:50:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Mar 2016 16:50:56 +0000
Subject: [docs] [issue21034] Python docs reference the Distribute package
 which has been deprecated in favor of Setuptools
In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za>
Message-ID: <20160307165051.10248.24059@psf.io>


Roundup Robot added the comment:

New changeset 50f593ed1469 by Berker Peksag in branch '3.5':
Issue #21034: Remove outdated paragraph from venv documentation
https://hg.python.org/cpython/rev/50f593ed1469

New changeset ac95719f1803 by Berker Peksag in branch 'default':
Issue #21034: Remove outdated paragraph from venv documentation
https://hg.python.org/cpython/rev/ac95719f1803

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

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

From report at bugs.python.org  Mon Mar  7 11:52:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Mar 2016 16:52:11 +0000
Subject: [docs] [issue21034] Python docs reference the Distribute package
 which has been deprecated in favor of Setuptools
In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za>
Message-ID: <1457369531.78.0.103147111953.issue21034@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Jurko.

> +1 from me for just removing the bootstrapping instructions from this note.

Thanks, Nick.

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

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

From report at bugs.python.org  Mon Mar  7 12:00:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Mar 2016 17:00:58 +0000
Subject: [docs] [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web"
 needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <20160307170051.10728.97160@psf.io>


Roundup Robot added the comment:

New changeset b8ee8f79a024 by Berker Peksag in branch '3.5':
Issue #24852: Remove outdated "HOWTO Use Python in the web" document
https://hg.python.org/cpython/rev/b8ee8f79a024

New changeset ee1d44f7d3e7 by Berker Peksag in branch 'default':
Issue #24852: Remove outdated "HOWTO Use Python in the web" document
https://hg.python.org/cpython/rev/ee1d44f7d3e7

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

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

From report at bugs.python.org  Mon Mar  7 12:02:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Mar 2016 17:02:12 +0000
Subject: [docs] [issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web"
 needs fix
In-Reply-To: <1439425233.4.0.643704057203.issue24852@psf.upfronthosting.co.za>
Message-ID: <1457370132.16.0.36656771287.issue24852@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  7 12:47:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Mar 2016 17:47:03 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
Message-ID: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I regulary see Python code using hex(value)[2:], whereas "%x" % value does the same thing. We should mention "%x" % value in the hex() doc. Maybe also mention "%#X" % value to format in upper case?

----------
assignee: docs at python
components: Documentation
messages: 261308
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: hex() documentation: mention "%x" % int
versions: Python 3.6

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

From report at bugs.python.org  Mon Mar  7 13:58:59 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 07 Mar 2016 18:58:59 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457377139.51.0.983983760887.issue26506@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

For 3.5 and 2.7, I'd suggest:
format(value, 'x')
or:
format(value, 'X')

Although you might disagree because of the verbosity. But at least you're not parsing a string at runtime. 

And for 3.6 with PEP-498:
f'{value:x}'

There are of course options for padding and adding the '0x', as well.

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

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

From report at bugs.python.org  Tue Mar  8 07:36:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Mar 2016 12:36:47 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1457440607.97.0.563914081324.issue26502@psf.upfronthosting.co.za>


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


----------
nosy: +rbcollins

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

From report at bugs.python.org  Tue Mar  8 07:52:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 08 Mar 2016 12:52:51 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1457441571.42.0.569316278227.issue26502@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is basically a duplicate of issue 25573. We need to add the examples in traceback module documentation to test_traceback.py.

> Should __len__ be added as well?

IMO, the new FrameSummary API (and its friends) shouldn't change the return value of the existing traceback functions like extract_tb() so I'd say yes.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Tue Mar  8 10:39:22 2016
From: report at bugs.python.org (Mike Vertolli)
Date: Tue, 08 Mar 2016 15:39:22 +0000
Subject: [docs] [issue26511] Add link to id() built-in in comparison
 operator documentation for "is"
Message-ID: <1457451562.01.0.849547274402.issue26511@psf.upfronthosting.co.za>


New submission from Mike Vertolli:

Here's the doc: https://docs.python.org/2/reference/expressions.html#is

It would be great if this line:
"The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value.[7]"

Could link to the id() builtin doc:
https://docs.python.org/2/library/functions.html#id

One way to rephrase this could be:
"The operators is and is not test for object identity: x is y is true if and only if x and y are the same object or id(x) == id(y). x is not y yields the inverse truth value.[7]"

And, the id's can be hyperlinks.

It would also be nice if that reference linked to a page on integer caching in Python.

----------
assignee: docs at python
components: Documentation
messages: 261364
nosy: Mike Vertolli, docs at python
priority: normal
severity: normal
status: open
title: Add link to id() built-in in comparison operator documentation for "is"
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  8 11:45:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Mar 2016 16:45:34 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1457455533.9.0.168097841171.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed in changesets 5fbd16326353 (2.7), 9ead3a6c5f81 (3.5), and fefedbaac640 (default). Due to SMTP failure there is no Roundup report.

Warnings are not emitted in maintained releases.

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

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

From report at bugs.python.org  Tue Mar  8 15:41:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 08 Mar 2016 20:41:31 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1457469691.22.0.890272875234.issue15068@psf.upfronthosting.co.za>


Martin Panter added the comment:

It seems this change is causing some (intermittent?) buildbot failures in 2.7:

http://buildbot.python.org/all/builders/s390x%20RHEL%202.7/builds/273/steps/test/logs/stdio

======================================================================
FAIL: test_saveall (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/2.7.edelsohn-rhel-z/build/Lib/test/test_gc.py", line 199, in test_saveall
    self.assertEqual(gc.garbage, [])
AssertionError: Lists differ: [<fileinput.FileInput instance... != []

First list contains 28 additional elements.
First extra element 0:
<fileinput.FileInput instance at 0x3fff6821a68>

Diff is 1461 characters long. Set self.maxDiff to None to see it.

======================================================================
FAIL: test_create_read (test.test_csv.TestLeaks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/2.7.edelsohn-rhel-z/build/Lib/test/test_csv.py", line 1103, in test_create_read
    self.assertEqual(gc.garbage, [])
AssertionError: Lists differ: [<fileinput.FileInput instance... != []

First list contains 28 additional elements.
First extra element 0:
<fileinput.FileInput instance at 0x3fff6821a68>

Diff is 1461 characters long. Set self.maxDiff to None to see it.

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

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

From report at bugs.python.org  Tue Mar  8 16:24:04 2016
From: report at bugs.python.org (Julien)
Date: Tue, 08 Mar 2016 21:24:04 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
Message-ID: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>


New submission from Julien:

o/

TL;DR: I think the various usages of "Integral" in https://docs.python.org/3.5/library/stdtypes.html#numeric-types-int-float-complex are either wrong or too hard to understand and should be rewriten as "int".


While translating the documentation I found the sentence "x truncated to Integral" in https://docs.python.org/3.5/library/stdtypes.html#numeric-types-int-float-complex for the `math.floor(x)` method.

By "Integral" I assume you're speaking about the ABC `numbers.Integral`, whish is already not clear, but the capital I helps.

According to pydoc and PEP3141, the `numbers.Integral` ABC inherits from Rational, which inherits from Real which inherits from Complex which inherits from Number. So number is the broader ABC and integral the opposite, the representation of an integer.

I do _NOT_ assume that someone reading the stdtypes.html section is aware of those ABCs, so I don't think it's nice for them to use them without linking to them.

So I infer than "x truncated to integral" means "x truncated to the nearest integer". Which is far more readable.

Two lines after, I found "The greatest integral float <= x" for `math.floor(x)` which is less readable, no capital I to `integral` and what is an `integral float` ?

Also the documentation of `math.floor` states an `int` is returned (as the doc for math.trunc states an Integral is returned).

So there's two possibilities here:

 - The doc uses vocabulary and phrase structures I don't understand and "integral float" actually mean something.
 - The doc is not clear

In both cases, I suggest to either transform "integral" usages to a link to :class:`numbers.Integral` or simply speaking of "int" here.

Context: I'm translating the documentation in French, I achieved `tutorial.html` and `functions.html` and it's until here the hardest sentence to understand (others were simply wrong like in http://bugs.python.org/issue26029) or understandable, so even if those structures are semantically and gramatically correct, they're clearly one of the hardest to understand, which is sad as we're only speaking of rounding numbers. I mean, if there's a goal to sand away spikes in doc readability, this one is a big one.

So, can an english native speaker can enlighten me about this ?

Bests,

----------
assignee: docs at python
components: Documentation
messages: 261380
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Vocabulary: Using "integral" in library/stdtypes.html
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  8 16:31:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Mar 2016 21:31:53 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1457472713.27.0.507979021775.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, thanks Martin. I forgot that assigning an attribute to a bound method creates a reference loop.

This can be fixed without performance lost by using a clever trick.

----------

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

From report at bugs.python.org  Tue Mar  8 16:37:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Mar 2016 21:37:04 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <20160308213646.10718.29254@psf.io>


Roundup Robot added the comment:

New changeset 88d6742aa99a by Serhiy Storchaka in branch '2.7':
Issue #15068: Avoid creating a reference loop in fileinput.
https://hg.python.org/cpython/rev/88d6742aa99a

New changeset a0de41b46aa6 by Serhiy Storchaka in branch '3.5':
Issue #15068: Avoid creating a reference loop in fileinput.
https://hg.python.org/cpython/rev/a0de41b46aa6

New changeset 27c9849ba5f3 by Serhiy Storchaka in branch 'default':
Issue #15068: Avoid creating a reference loop in fileinput.
https://hg.python.org/cpython/rev/27c9849ba5f3

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

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

From report at bugs.python.org  Tue Mar  8 16:37:32 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Mar 2016 21:37:32 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457473052.79.0.132600249845.issue26512@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

In the contexts that you mentioned, "integral" is a synonym of "integer."

----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Mar  8 21:43:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Mar 2016 02:43:41 +0000
Subject: [docs] [issue26515] Update extending/embedding docs to new way to
 build modules in C
Message-ID: <1457491421.2.0.684118231911.issue26515@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://docs.python.org/3/extending/extending.html#a-simple-example uses PyModule_Create() instead of PyModuleDef_Init().

----------
assignee: docs at python
components: Documentation
messages: 261398
nosy: brett.cannon, docs at python, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Update extending/embedding docs to new way to build modules in C
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Mar  8 22:00:25 2016
From: report at bugs.python.org (Dan Haffey)
Date: Wed, 09 Mar 2016 03:00:25 +0000
Subject: [docs] [issue21910] File protocol should document if writelines
 must handle generators sensibly
In-Reply-To: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>
Message-ID: <1457492424.87.0.520193001251.issue21910@psf.upfronthosting.co.za>


Dan Haffey added the comment:

+1, I just lost an hour-plus compute job to this. It sure violates POLA. I've been passing large generators to file.writelines since about as long as generators have existed, so I never would have guessed that a class named "StreamWriter" of all things wouldn't, you know, stream its writelines argument.

----------
nosy: +dhaffey

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

From report at bugs.python.org  Wed Mar  9 03:45:49 2016
From: report at bugs.python.org (Julien)
Date: Wed, 09 Mar 2016 08:45:49 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457513149.02.0.424018006127.issue26512@psf.upfronthosting.co.za>


Julien added the comment:

> In the contexts that you mentioned, "integral" is a synonym of "integer."

Can you provide a source ? There's no mention of "integral" in the Wikipedia page of "integer" (but there's mentions of "integral element" and "integral domain" which are not synonyms for "integer".

Even if "integral" is a synonym for "integer", I think we should use "integer" or "int" in the documentation because "integral" is harder to understand as readers are searching why "integral" is used in this particular context instead of "integer".

It looks like the documentation describes the mathematical, theoretical, point of view of those functions, as supported by the PEP3141, but those functions are not theoretical, they're actual implementations returning actual integers.

I can understand the need to abstract the implementations to make the documentation more readable, we're already not manipulating bits or even bytes, there's nice abstractions of those implementations so we can manipulate `int`, `float` etc, which are also implementation we may want to abstract again and say we're not manipulating "the implementation" (like "an int") but a mathematical domain (like "a natural number"), but going all the way down to vocabulary I can't even find on Wikipedia is probably going the wrong way: The documentation is less readable this way.

----------

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

From rmulholland7 at icloud.com  Wed Mar  9 06:30:51 2016
From: rmulholland7 at icloud.com (Robert Mulholland)
Date: Wed, 09 Mar 2016 06:30:51 -0500
Subject: [docs] Python 3.5.1 Documentation
Message-ID: <026BB1FE-CD26-4F58-9CF6-0A720D07CD84@icloud.com>

ALL OF THE LINKS TO DOWNLOAD PYTHON 3.5.1 DOCUMENTATION ARE BROKEN !




From report at bugs.python.org  Wed Mar  9 10:29:17 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Mar 2016 15:29:17 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457537356.94.0.0938663191408.issue26512@psf.upfronthosting.co.za>


Georg Brandl added the comment:

There's two different uses here:

The one use in "truncated to Integral" means that you get an integer type out.  It is not specified to be `int` because `__trunc__` may return other types.  It could be made into a link like the other use of Integral.

The other uses are "integral float", which is *not* the same as an integer.  It is a float whose value is a whole number, and AFAIK "integral" is the correct adjective for that.

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

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

From report at bugs.python.org  Wed Mar  9 11:20:11 2016
From: report at bugs.python.org (Julien)
Date: Wed, 09 Mar 2016 16:20:11 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457540411.75.0.133304186603.issue26512@psf.upfronthosting.co.za>


Julien added the comment:

> It could be made into a link like the other use of Integral.

I'll propose a patch.

> The other uses are "integral float", which is *not* the same as an integer.  It is a float whose value is a whole number, and AFAIK "integral" is the correct adjective for that.

Can you please give me some links to definitions / usages of the "integral" adjective ? As "integral float" is not verbose on google SERPs, so I can document myself on it and eventually translate it correctly in french ?

I'm still thinking that those sentences are way too hard to understand for a youg user (Think of all the childs learning Python ^^), and they're contrasting a lot with the other parts of the documentations which are far more readable. (Also remember that I'm not native english, maybe "integral" is a wisely used word for this context and I completly missed it).

----------

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

From report at bugs.python.org  Wed Mar  9 13:55:04 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Mar 2016 18:55:04 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457549704.07.0.255040680833.issue26512@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Can you provide a source ?

How about a dictionary?  For example, Oxford English Dictionary has

"""
integral, adj. and n.

4. Math.

 a. That is, or is denoted by, an integer, or involves only integers; consisting of a whole number or undivided quantity; not fractional, or not involving a fraction.
"""

http://www.oed.com/view/Entry/97344?redirectedFrom=integral#eid

----------

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

From report at bugs.python.org  Wed Mar  9 16:06:55 2016
From: report at bugs.python.org (John Beck)
Date: Wed, 09 Mar 2016 21:06:55 +0000
Subject: [docs] [issue26524] document what config directory is used for
Message-ID: <1457557615.13.0.55098857732.issue26524@psf.upfronthosting.co.za>


New submission from John Beck:

Solaris ships Python versions 2.7, 3.4 and 3.5 at present.  For 2.7,
we ship both 32-bit and 64-bit versions; for 3.4 and 3.5 we only ship
64-bit versions.  For 2.7, we ship /usr/lib/python2.7/config/ with the
usual suspects (Makefile, Setup.config, config.c, install-sh, python.o,
Setup, Setup.local, config.c.in, makesetup) thereunder for the 32-bit
version but for the 64-bit version, we don't ship the equivalent
directory at all.  For 3.4 and 3.5, we ship
/usr/lib/python3.[45]/config-3.[45]m/ with its usual suspects.  We had
a bug filed about the discrepancy in shipping the 32-bit but not the
64-bit version of that directory for 2.7.  An investigation suggested
the directory is not used for 2.7, nor did it seem used (per docs we
could find) for 3.x.  But testing revealed it is used for 3.x, as our
builds failed, e.g.:

error: invalid Python installation: unable to open
    /usr/lib/python3.4/config-3.4m/Makefile (No such file or directory)

when we removed the config-3.[45]m directories.  OK, fine, it was an
experiment, so we'll keep the directories.  But it was not clear to
us from the docs we could find, such as:
    https://docs.python.org/3.6/extending/extending.html
exactly how the config directory is used.  This is a documentation
enhancement request to clarify how the config directory is used.

----------
assignee: docs at python
components: Documentation
messages: 261477
nosy: docs at python, jbeck
priority: normal
severity: normal
status: open
title: document what config directory is used for
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar  9 16:15:46 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 09 Mar 2016 21:15:46 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457558146.35.0.234187004467.issue26506@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Your two suggestions prompted me to do a speed comparison between them and the result surprised me.

I tried:

import random
nums = [random.randint(0, 255) for n in range(10000000)]

then timed the simple:

for n in nums:
    hx = '%X' % n  # or hx = format(n, 'X')

I also tested a number of more complex formats like:
hx = '%{:02X}'.format(n) vs hx = '%%%02X' % n

In all cases, the old vs new formatting styles are rather similar in speed in my system Python 2.7.6 (with maybe a slight advantage for the format-based formatting).
In Python 3.5.0, however, old-style %-formatting is much speedier than under Python 2, while new-style formatting doesn't appear to have changed much, with the result that %-formatting is now between 30-50% faster than format-based formatting.

So I guess my questions are:

- are my timings wrong?

and if not:

- how got %-formatting improved (generally? or for %X specifically?)
- can this speed up be transferred to format-based formatting somehow?

----------
nosy: +wolma

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

From report at bugs.python.org  Wed Mar  9 16:43:11 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Mar 2016 21:43:11 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457559791.36.0.885805084084.issue26506@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Without lots of analysis (and disassembly), I can't speak to how valid your tests are, but they don't seem unreasonable.

format() will always be slower, because it's more general (primarily in that it can be extended to new types). Plus, it involves at least a name lookup that %-formatting can skip. The usual ways to optimize this lookup holds here, too, if speed is really that critical (which I'm skeptical of).

For example, say you had a custom type which implemented __format__ to understand the "X" format code. Using format(), this type could format itself as hex. %-formatting can't do that.

In any event, I don't think we want to promulgate the fastest way to do a hex conversion, just the clearest.

I can't say why format() in 3.5 is slower. There are many changes and tracking it down would be quite time consuming.

----------

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

From report at bugs.python.org  Wed Mar  9 16:47:42 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 09 Mar 2016 21:47:42 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457560062.43.0.831908300108.issue26506@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Ah, but it's not that format() is slower in 3.5, but that %-formatting got faster.
It looks as if it got optimized and I was wondering whether the same optimization could be applied to format().

----------

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

From report at bugs.python.org  Wed Mar  9 18:16:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Mar 2016 23:16:57 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457565417.41.0.0556401980322.issue26506@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Ah, but it's not that format() is slower in 3.5, but that %-formatting got faster.

Hum, python3 looks faster on this dummy microbenchmark yeah. Who said that Python 3 is slower? :-)

$ python2 -m timeit -s 'import random; nums = [random.randint(0, 255) for n in range(10**5)]' '["%x" % x for x in nums]'
10 loops, best of 3: 43.7 msec per loop

$ python3 -m timeit -s 'import random; nums = [random.randint(0, 255) for n in range(10**5)]' '["%x" % x for x in nums]'
10 loops, best of 3: 19.2 msec per loop

I spent a lot time to micro-optimize str%args, str.format(args), and operations on str in general in Python 3. I wrote a first article to explain my work on optimization:
https://haypo.github.io/pybyteswriter.html

I have a draft article explaning other kinds of optimizations related to the PEP 393.

> It looks as if it got optimized and I was wondering whether the same optimization could be applied to format().

str.format(args) was also optimized, but it's still faster than str%args.

On Python 3, "%x" % 0x1234abc takes 17 nanoseconds according to timeit. It's super fast! Any extra work can have a non negligible overhead. For example, it's known that operators are faster than functions in Python. One reason is that a calling requires to lookup the function in namespaces (local, global or builtin namespaces). It can be even worse (slower) to lookup a method (especially with custom __getattr__ method).

--

Hum, I don't recall why you started to talk about performance :-D

Why not documenting "%x" % value *and* format(value, 'x')?

I prefer "%x" % value. I never use format(value, ...) but sometimes I use "{0:x}".format(value).

f'{x:value}' looks too magical for me.

----------

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

From report at bugs.python.org  Wed Mar  9 19:21:05 2016
From: report at bugs.python.org (Joseph Moran)
Date: Thu, 10 Mar 2016 00:21:05 +0000
Subject: [docs] [issue26322] Missing docs for typing.Set
In-Reply-To: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za>
Message-ID: <1457569265.91.0.348114437775.issue26322@psf.upfronthosting.co.za>


Joseph Moran added the comment:

Deleted second ABSTRACTSET and added SET in typing docs

----------
nosy: +joegotflow83
Added file: http://bugs.python.org/file42109/26322

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

From report at bugs.python.org  Thu Mar 10 03:51:32 2016
From: report at bugs.python.org (gladman)
Date: Thu, 10 Mar 2016 08:51:32 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
Message-ID: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>


New submission from gladman:

It is very easy to misread the greek 'nu' used in the ord(c) documentation as ord('v') (i.e. an alphabetic 'v').  This can lead the reader to draw a wrong conclusion about the behaviour of the function. 

Would it not be better if this example used a greek letter that is less easy to misread in this way?  Or, perhaps, add extra text indicating that the greek letter 'nu' is being referenced?

----------
assignee: docs at python
components: Documentation
messages: 261485
nosy: docs at python, gladman
priority: normal
severity: normal
status: open
title: Documentation of ord(c) easy to misread
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 10 04:22:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Mar 2016 09:22:21 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457601741.92.0.682822105726.issue26525@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar 10 06:18:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Mar 2016 11:18:46 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457608726.75.0.585660516325.issue26525@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I suggest to use the EURO SIGN ? (U+20ac).

----------
keywords: +easy
nosy: +haypo

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

From report at bugs.python.org  Thu Mar 10 06:21:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Mar 2016 11:21:10 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457608870.08.0.000642012161195.issue26506@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I regulary see Python code using hex(value)[2:]

In fact, it's even worse, I also saw Python 2 code stripping trailing "L", since hex(long) adds a L suffix...

$ python2
Python 2.7.10 (default, Sep  8 2015, 17:20:17) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux2
>>> hex(123L)
'0x7bL'
>>> "%x" % 123L
'7b'
>>> format(123L, "x")
'7b'
>>> "%#x" % 123L
'0x7b'
>>> format(123L, "#x")
'0x7b'

----------

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

From report at bugs.python.org  Thu Mar 10 06:32:40 2016
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 10 Mar 2016 11:32:40 +0000
Subject: [docs] [issue15693] expose glossary link on hover
In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>
Message-ID: <1457609560.41.0.488636735.issue15693@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

It looks like the issue I previously filed on the Sphinx tracker was migrated here: https://github.com/sphinx-doc/sphinx/issues/996 . But the patch I submitted seems to have been dropped.

----------

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

From report at bugs.python.org  Thu Mar 10 08:36:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Mar 2016 13:36:03 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457616962.99.0.776280899667.issue26512@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Mar 10 08:59:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Mar 2016 13:59:29 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457618369.5.0.279980288941.issue26512@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar 10 10:19:57 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 10 Mar 2016 15:19:57 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457623197.56.0.272994460834.issue26525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Sure!

----------

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

From report at bugs.python.org  Thu Mar 10 12:25:59 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 10 Mar 2016 17:25:59 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457630759.83.0.924095184001.issue26506@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

> Hum, python3 looks faster on this dummy microbenchmark yeah. Who said that Python 3 is slower? :-)

If you're alluding to that seemingly endless thread over on python-list, let me say that it is not my motivation to start anything like that here. Sorry also if I sort of hijacked your documentation issue with my performance question.

I really only wondered whether there would be any argument for or against any of the two versions (%-interpolation, format-based) other than stylistic ones.
That's why I ran the micro-benchmark and, in fact, I was expecting %-interpolation to be faster exactly because it is less flexible.
What I am surprised by is not the fact that %-interpolation got faster in Python3, but the fact that format didn't.
I was wondering whether %-interpolation maybe takes some fast path in Python3 that simply wasn't implemented for format. If that was the case it could have been rewarding to just optimize format the same way.
As I know Victor is working on performance stuff I thought I'd just ask here, but from your answer I gather that things are rather not so simple and that's ok.

> I wrote a first article to explain my work on optimization:
https://haypo.github.io/pybyteswriter.html

Thanks for the link.

> str.format(args) was also optimized, but it's still faster than str%args.

You mean slower I assume ?

> Hum, I don't recall why you started to talk about performance :-D

See above.

> Why not documenting "%x" % value *and* format(value, 'x')?

> I prefer "%x" % value. I never use format(value, ...) but sometimes I use "{0:x}".format(value).

I prefer the last version, use the first sometimes, but documenting several ways seems reasonable.

----------

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

From report at bugs.python.org  Thu Mar 10 12:47:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Mar 2016 17:47:35 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457632055.73.0.226285535114.issue26506@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> That's why I ran the micro-benchmark and, in fact, I was expecting %-interpolation to be faster exactly because it is less flexible.

Actually %-interpolation is more flexible.

>>> '%x' % 123
'7b'
>>> '%0X' % 123
'7B'
>>> '%#x' % 123
'0x7b'
>>> '%04x' % 123
'007b'

If document alternatives for hex(), we should also document formatting alternatives for bin(), oct(), repr(), ascii(), str(), chr(), str.ljust(), str.rjust(), str.center(), str.zfill().

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

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

From report at bugs.python.org  Thu Mar 10 17:36:31 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Mar 2016 22:36:31 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457649391.63.0.0828580747081.issue26525@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Wouldn't '\N{SNAKE}' look more pythonic?  ?

>>> hex(ord('?'))
'0x1f40d'

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Mar 10 17:42:17 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 10 Mar 2016 22:42:17 +0000
Subject: [docs] [issue23220] Documents input/output effects of how IDLE runs
 user code
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1457649737.5.0.208389225798.issue23220@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Different \r behavior is the gist of https://stackoverflow.com/questions/35895864/what-is-the-difference-between-cmd-and-idle-when-using-tqdm.  The new section should have more on the different effect of control characters on different display devices and windows. It should also better differentiate between Python result, which is the string written to stdout, and which is nearly always the same in IDLE and console, and visual display result, which is  outside of Python's control.  This separation is the point of Serhiy's msg246602.

----------

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

From report at bugs.python.org  Thu Mar 10 18:24:04 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 10 Mar 2016 23:24:04 +0000
Subject: [docs] [issue23220] Documents input/output effects of how IDLE runs
 user code
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1457652244.66.0.245861214212.issue23220@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Part of this issue is the difference between typing a character at the keyboard, which produces a key event whose effect is determined by key bindings (some default, some added) and inserting a character into a Text widget, which does not produce an event (except, in some sense, \t and \n).  Whether or not a key event results in character insertion depends on key bindings.  The visual effect of inserted chars other than \t and \n is determined by the font.  (I believe I got the above right.) I believe some terminals treat chars coming over the wire the same as those typed.  I am not sure what the Win10 console is doing with control-x keystrokes.

>>> import sys; out=sys.stdout.write
# use direct write to avoid str(), repr() conversion of control chars
>>> out('\x03')
1  # The first char is an empty thin box in my IDLE.
>>> # type ^C
KeyboardInterrupt

----------

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

From report at bugs.python.org  Thu Mar 10 18:32:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Mar 2016 23:32:38 +0000
Subject: [docs] [issue23220] Documents input/output effects of how IDLE runs
 user code
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1457652758.45.0.16405205247.issue23220@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As for StackOverflow question, there is tkinter.ttk.Progressbar.

----------

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

From report at bugs.python.org  Thu Mar 10 18:37:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Mar 2016 23:37:38 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457653058.52.0.311907505619.issue26525@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

'?' is astral character and not all systems have fonts that support it installed by default. It can be hard to render it in TeX.

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

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

From report at bugs.python.org  Thu Mar 10 21:45:19 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 11 Mar 2016 02:45:19 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
Message-ID: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docstring of struct.unpack currently reads

Unpack from the buffer buffer (presumably packed by pack(fmt, ...)) according to the format string fmt. The result is a tuple even if it contains exactly one item. The buffer must contain exactly the amount of data required by the format (len(bytes) must equal calcsize(fmt)).

It should probably read "len(buffer) must equal calcsize(fmt)".

----------
assignee: docs at python
components: Documentation
messages: 261538
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in the docs for struct.unpack
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar 11 01:38:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 06:38:43 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457632055.73.0.226285535114.issue26506@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZWgFgpKx52ByGNg+yCEGFnQ4aqFnpiupTqRc5HcrO8KQ@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> If document alternatives for hex(), we should also document formatting
alternatives for bin(), oct(),

Ok for these two since they also add a prefix. But I don't see the point of
documenting alternatives for the other listed functions. The matter here is
the 0x prefix.

----------

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

From report at bugs.python.org  Fri Mar 11 01:56:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2016 06:56:51 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457679411.47.0.761641049964.issue26506@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no harm if use hex(value)[2:]. It's a matter of taste.

We can mention "%x" % value for the case if the user just doesn't know about this alternative. The same is for value.ljust(5) and '%-5s' % value.

----------

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

From report at bugs.python.org  Fri Mar 11 02:04:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2016 07:04:06 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457679846.36.0.0836503311045.issue26535@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would remove "len(bytes) must equal " at all. len() can return a value not equal to the number of bytes contained in the buffer (e.g. for array('I')).

----------
nosy: +martin.panter, serhiy.storchaka

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

From report at bugs.python.org  Fri Mar 11 02:04:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2016 07:04:35 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457679875.53.0.244816465158.issue26535@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson, meador.inge

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

From report at bugs.python.org  Fri Mar 11 02:36:31 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 11 Mar 2016 07:36:31 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457681791.47.0.970476132517.issue26535@psf.upfronthosting.co.za>


Antony Lee added the comment:

I think mentioning calcsize is still helpful, so perhaps something like
"The buffer must contain exactly as many bytes (I think this is clearer than "the amount of data") as required by the format (this number can be obtained as `struct.calcsize(fmt)`)"?  (and likewise for "unpack_from" and "iter_unpack").

----------

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

From report at bugs.python.org  Fri Mar 11 02:59:07 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Mar 2016 07:59:07 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457683147.59.0.378083196655.issue26535@psf.upfronthosting.co.za>


Georg Brandl added the comment:

That sounds good to me. Maybe without so many parentheses :)

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

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

From report at bugs.python.org  Fri Mar 11 03:01:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2016 08:01:07 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457683267.45.0.507140920974.issue26535@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 11 03:37:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 08:37:32 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457685452.46.0.309954772623.issue26506@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I opened the issue when I read this change:
https://review.openstack.org/#/c/288224/2/neutron/common/utils.py

    rndstr = hex(...)[2:]
    # Whether there is a trailing 'L' is a py2/3 incompatibility
    rndstr = rndstr.rstrip('L')
    return rndstr.zfill(length)

can be simply written

    return "{0:0{1}x}".format(..., length)

It's less readable, but it's more efficient.

----------

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

From report at bugs.python.org  Fri Mar 11 03:51:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2016 08:51:37 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1457686296.97.0.907974070086.issue26506@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree with you and always prefer formatting strings.

Your example shows that at least an alternative to str.zfill() should be mentioned in the educational purposes.

With C-style formatting your example can be written more laconically:

    return "%0*x" % (length, ...)

----------

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

From report at bugs.python.org  Fri Mar 11 05:11:48 2016
From: report at bugs.python.org (baji)
Date: Fri, 11 Mar 2016 10:11:48 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457691108.04.0.15619058637.issue26535@psf.upfronthosting.co.za>


baji added the comment:

Modified as suggested in the comments

----------
keywords: +patch
nosy: +baji
Added file: http://bugs.python.org/file42125/issue26535.diff

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

From report at bugs.python.org  Fri Mar 11 05:13:29 2016
From: report at bugs.python.org (Manvi B)
Date: Fri, 11 Mar 2016 10:13:29 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457691209.71.0.280803916537.issue26247@psf.upfronthosting.co.za>


Manvi B added the comment:

Made changes according to last comment by Ezio.

----------
Added file: http://bugs.python.org/file42126/issue26247.diff

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

From report at bugs.python.org  Fri Mar 11 05:25:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 10:25:19 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457691919.9.0.356188132034.issue26535@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Issue title: "Minor typo in the docs for struct.unpack"

I can say the same on issue26535.diff: there is a typo ;)

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

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

From report at bugs.python.org  Fri Mar 11 05:25:41 2016
From: report at bugs.python.org (Anna Koroliuk)
Date: Fri, 11 Mar 2016 10:25:41 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1457691941.64.0.27601447955.issue16851@psf.upfronthosting.co.za>


Anna Koroliuk added the comment:

This patch fixes Python 2.7.

----------
nosy: +Anna Koroliuk
Added file: http://bugs.python.org/file42128/inspect2.patch

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

From report at bugs.python.org  Fri Mar 11 05:28:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Mar 2016 10:28:21 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <20160311102751.9519.71727@psf.io>


Roundup Robot added the comment:

New changeset 813a0e0934ce by Victor Stinner in branch '2.7':
Fix inspect.ismethod() doc
https://hg.python.org/cpython/rev/813a0e0934ce

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

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

From report at bugs.python.org  Fri Mar 11 05:29:10 2016
From: report at bugs.python.org (Baji)
Date: Fri, 11 Mar 2016 10:29:10 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457692150.35.0.911083258438.issue26535@psf.upfronthosting.co.za>


Changes by Baji <bajibabu7 at gmail.com>:


Added file: http://bugs.python.org/file42129/issue26535.diff

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

From report at bugs.python.org  Fri Mar 11 05:29:24 2016
From: report at bugs.python.org (Baji)
Date: Fri, 11 Mar 2016 10:29:24 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457692164.5.0.22616779273.issue26535@psf.upfronthosting.co.za>


Changes by Baji <bajibabu7 at gmail.com>:


Removed file: http://bugs.python.org/file42125/issue26535.diff

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

From report at bugs.python.org  Fri Mar 11 05:30:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 10:30:20 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1457692220.22.0.372650540906.issue16851@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks Anna, I pushed your doc fix.

Can you please sign the Python Contributor Agreement?
https://www.python.org/psf/contrib/

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

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

From report at bugs.python.org  Fri Mar 11 05:32:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Mar 2016 10:32:00 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <20160311102846.31083.62868@psf.io>


Roundup Robot added the comment:

New changeset a90b39aa6af4 by Victor Stinner in branch '2.7':
Issue #16851: Add Anna Koroliuk to Misc/ACKS
https://hg.python.org/cpython/rev/a90b39aa6af4

----------

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

From report at bugs.python.org  Fri Mar 11 05:57:28 2016
From: report at bugs.python.org (Susan Sun)
Date: Fri, 11 Mar 2016 10:57:28 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457693848.88.0.243974591859.issue26525@psf.upfronthosting.co.za>


Susan Sun added the comment:

This was changed in the following commit.

changeset:   95165:f6c6304c8193
user:        Benjamin Peterson <benjamin at python.org>
date:        Tue Mar 24 12:12:44 2015 -0400
summary:
  change ? to ? for obscure joke reasons

https://twitter.com/ncoghlan_dev/status/579173053793353728

----------
nosy: +Susan Sun, benjamin.peterson, ncoghlan

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

From report at bugs.python.org  Fri Mar 11 08:21:44 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 11 Mar 2016 13:21:44 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457702504.06.0.694954324521.issue26247@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

The ``versionadded::`` directive should only be used to annotate descriptions of new API entries.  While it would be correctly applied to the ``Chrome`` and ``Chromium`` classes, those are not separately documented here, but are only listed in the table.

See http://bugs.python.org/issue26366 for further discussion on the use of ``versionadded::``.

----------
nosy: +fdrake

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

From report at bugs.python.org  Fri Mar 11 08:43:40 2016
From: report at bugs.python.org (Varpu Rantala)
Date: Fri, 11 Mar 2016 13:43:40 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <1457703820.4.0.470419438499.issue25959@psf.upfronthosting.co.za>


Varpu Rantala added the comment:

crashes also with Python 3.5.0 (Mac OS X 10.11.3) when x and y are the following or bigger, but works when they are smaller. Tried it with the mapbe.gif image (size 1000 x 681). 

30, 27 
31, 26 
32, 25 
33, 24 
34, 24 
35, 23 
36, 22 
37, 22 
38, 22 
39, 21 
40, 20

----------
nosy: +Varpu Rantala

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

From report at bugs.python.org  Fri Mar 11 08:46:31 2016
From: report at bugs.python.org (Guido Treutwein)
Date: Fri, 11 Mar 2016 13:46:31 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1457703991.67.0.255531275721.issue26156@psf.upfronthosting.co.za>


Guido Treutwein added the comment:

Yurys answer and resolution misses the point. Nobody complained about the await operator. Fact is, that in the _power_ operator (chapter 6.5) as base specification now "await" is given. This is likely to be an inadvertent copy of the previous chapter, makes no sense here and should probably be replaced by "u_expr" or similar.

----------
nosy: +Guido Treutwein

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

From report at bugs.python.org  Fri Mar 11 08:52:40 2016
From: report at bugs.python.org (Manvi B)
Date: Fri, 11 Mar 2016 13:52:40 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457704359.89.0.9272957614.issue26247@psf.upfronthosting.co.za>


Manvi B added the comment:

Modified the patch with this directive instead   ``versionchanged::``.

----------
Added file: http://bugs.python.org/file42134/issue26247.diff

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

From report at bugs.python.org  Fri Mar 11 09:26:38 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 11 Mar 2016 14:26:38 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457706398.28.0.699124187044.issue26247@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

Sorry; I guess I wasn't clear.

``versionadded::`` and ``versionchanged::`` are applied to specific API points (modules, classes, methods, attributes) that are identified structurally in the documentation.  That isn't the case for this.

While a bit of text noting the addition is less discoverable for documentation processors, I believe it to be sufficient.

----------

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

From report at bugs.python.org  Fri Mar 11 09:50:24 2016
From: report at bugs.python.org (Manvi B)
Date: Fri, 11 Mar 2016 14:50:24 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457707823.94.0.716211820169.issue26247@psf.upfronthosting.co.za>


Manvi B added the comment:

@Fred L. Drake, Jr. (fdrake)
Is it okay if I can remove ``versionchanged::``. And simply say that,
Support for Chrome/Chromium has been added from 2.7.5 version or later.

----------

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

From report at bugs.python.org  Fri Mar 11 10:23:22 2016
From: report at bugs.python.org (Manvi B)
Date: Fri, 11 Mar 2016 15:23:22 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457709802.36.0.156336278314.issue26247@psf.upfronthosting.co.za>


Manvi B added the comment:

Submitted the patch with the text noting below the table.

----------
Added file: http://bugs.python.org/file42135/issue26247.diff

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

From report at bugs.python.org  Fri Mar 11 10:41:57 2016
From: report at bugs.python.org (Elena Oat)
Date: Fri, 11 Mar 2016 15:41:57 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1457710917.13.0.770592839609.issue13305@psf.upfronthosting.co.za>


Elena Oat added the comment:

I submitted a patch for documentation changes related to strftime "%Y" directive inconsistencies. I am not sure that specifying the OS is correct, because I haven't tested the inconsistencies on all Linux PCs, Windows versions or OS X. I still left them there though, so let me know what's your opinion on it.

----------
nosy: +Elena.Oat
Added file: http://bugs.python.org/file42136/issue13305.diff

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

From report at bugs.python.org  Fri Mar 11 11:16:49 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 11 Mar 2016 16:16:49 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457713008.96.0.0654942536956.issue26247@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

LGTM

Thanks for getting this documented!

----------

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

From report at bugs.python.org  Fri Mar 11 13:14:45 2016
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCd0Y/RhdCw0LnRh9GL0Lo=?=)
Date: Fri, 11 Mar 2016 18:14:45 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1457720085.09.0.333191047322.issue14787@psf.upfronthosting.co.za>


?????? ???????? added the comment:

Any hope to add the warning in pkgutil docs about this problem? 

For example:
Warning!!! The walk_packages function uses sys.path to import nested packages for provided paths. It means it walks deeply by relative import for subpackages. If you provide path that is not in sys.path as an argument the result won't be correct.

----------
nosy: +?????? ????????

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

From report at bugs.python.org  Fri Mar 11 13:20:27 2016
From: report at bugs.python.org (Dmitry Shachnev)
Date: Fri, 11 Mar 2016 18:20:27 +0000
Subject: [docs] [issue26542] Wrongly formatted doctest block in difflib
 documentation
Message-ID: <1457720427.82.0.520743466398.issue26542@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

Look at the documentation of difflib.SequenceMatcher.get_opcodes:
https://docs.python.org/dev/library/difflib.html#difflib.SequenceMatcher.get_opcodes

There, the result part of the example is rendered as plain reStructuredText, separately from the code block itself.
The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: doctest.diff
keywords: patch
messages: 261591
nosy: docs at python, mitya57
priority: normal
severity: normal
status: open
title: Wrongly formatted doctest block in difflib documentation
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42137/doctest.diff

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

From report at bugs.python.org  Fri Mar 11 14:32:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Mar 2016 19:32:42 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <20160311193239.108829.10106@psf.io>


Roundup Robot added the comment:

New changeset 8ef74c7f3fdc by Ezio Melotti in branch '2.7':
#26247: document Chrome/Chromium addition to webbrowser.  Patch by Manvi B.
https://hg.python.org/cpython/rev/8ef74c7f3fdc

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

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

From report at bugs.python.org  Fri Mar 11 14:35:58 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Mar 2016 19:35:58 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1457724958.09.0.643899595985.issue26247@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patches and reviews!

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

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

From report at bugs.python.org  Fri Mar 11 15:21:13 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Mar 2016 20:21:13 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <1457727673.2.0.617136073671.issue25959@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> terry.reedy
stage: needs patch -> commit review

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

From report at bugs.python.org  Fri Mar 11 15:31:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Mar 2016 20:31:44 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <20160311203141.29607.2178@psf.io>


Roundup Robot added the comment:

New changeset 1e7c388dc3c5 by Terry Jan Reedy in branch '2.7':
Issue 25959: Explain in docstring that PhotoImage.zoom arguments are
https://hg.python.org/cpython/rev/1e7c388dc3c5

New changeset 7474695874d9 by Terry Jan Reedy in branch '3.5':
Issue 25959: Explain in docstring that PhotoImage.zoom arguments are
https://hg.python.org/cpython/rev/7474695874d9

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

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

From report at bugs.python.org  Fri Mar 11 15:32:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Mar 2016 20:32:28 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <1457728348.97.0.658164755856.issue25959@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 11 15:41:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2016 20:41:30 +0000
Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault
In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za>
Message-ID: <1457728890.49.0.78562017783.issue25959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Terry.

----------

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

From report at bugs.python.org  Fri Mar 11 16:04:33 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 11 Mar 2016 21:04:33 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1457730273.62.0.727504401881.issue14787@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


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

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

From report at bugs.python.org  Fri Mar 11 16:19:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Mar 2016 21:19:37 +0000
Subject: [docs] [issue26542] Wrongly formatted doctest block in difflib
 documentation
In-Reply-To: <1457720427.82.0.520743466398.issue26542@psf.upfronthosting.co.za>
Message-ID: <20160311211934.10732.36477@psf.io>


Roundup Robot added the comment:

New changeset ffd0603f5251 by Berker Peksag in branch '3.5':
Issue #26542: Fix markup of code example in difflib documentation
https://hg.python.org/cpython/rev/ffd0603f5251

New changeset 40d92c92eb6e by Berker Peksag in branch 'default':
Issue #26542: Fix markup of code example in difflib documentation
https://hg.python.org/cpython/rev/40d92c92eb6e

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

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

From report at bugs.python.org  Fri Mar 11 16:20:29 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 11 Mar 2016 21:20:29 +0000
Subject: [docs] [issue26542] Wrongly formatted doctest block in difflib
 documentation
In-Reply-To: <1457720427.82.0.520743466398.issue26542@psf.upfronthosting.co.za>
Message-ID: <1457731229.6.0.0107034702252.issue26542@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, Dmitry. Thanks for the patch!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar 11 16:36:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Mar 2016 21:36:40 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <20160311213637.9523.28414@psf.io>


Roundup Robot added the comment:

New changeset 291d47954618 by Victor Stinner in branch 'default':
Always test datetime.strftime("%4Y")
https://hg.python.org/cpython/rev/291d47954618

----------

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

From report at bugs.python.org  Fri Mar 11 16:37:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 21:37:44 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1457732264.45.0.0761389681961.issue13305@psf.upfronthosting.co.za>


STINNER Victor added the comment:

About Elena Oat's patch issue13305.diff: I'm not sure that strftime("%4Y") works on all platforms, so I enabled the test on strftime("%4Y"). I will check our buildbots.

----------

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

From report at bugs.python.org  Fri Mar 11 16:43:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Mar 2016 21:43:51 +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: <1457732631.53.0.449506999801.issue26483@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 11 16:43:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 21:43:52 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1457732632.1.0.526544157378.issue13305@psf.upfronthosting.co.za>


STINNER Victor added the comment:

acucci's patch doc.patch suggests to use format "%4Y". Problem: I tried it on Linux, and it looks like it doesn't work.

>>> datetime.datetime.strptime("1980", "%Y")
datetime.datetime(1980, 1, 1, 0, 0)
>>> datetime.datetime.strptime("1980", "%4Y")
Traceback (most recent call last):
  ...
ValueError: '4' is a bad directive in format '%4Y'

Or maybe I misunderstood the doc change. Do you suggest to use %4Y format with strptime(), with strftime() or with both?

----------

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

From report at bugs.python.org  Fri Mar 11 18:42:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Mar 2016 23:42:38 +0000
Subject: [docs] [issue24136] document PEP 448: unpacking generalization
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1457739758.4.0.0381931173304.issue24136@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It is now 10 months and 2 releases since the rather large code patch.  Documenting the extensive changes does not seem easy to me ;-).  Certainly, a beginner needs feedback.

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

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

From report at bugs.python.org  Fri Mar 11 18:50:55 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Mar 2016 23:50:55 +0000
Subject: [docs] [issue26500] Document of new star unpacking is missing.
In-Reply-To: <1457346135.37.0.589425731268.issue26500@psf.upfronthosting.co.za>
Message-ID: <1457740255.1.0.784456339094.issue26500@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#19024 was about adding a general section on the various uses of '*'.  This was before the new * unpacking generalizations.  It was closed because the then existing uses *are* documented and are indexed in the first, Symbols, section of the index. 

There are now 4 entries. I think entries for standalone '*' (operator and function defs) should be separated from those for '*identifier'.  Entries for new *identifier uses need to be added to the index.  Assignment statement *identifier target is in 7.2. Assignment statements. 

Actually documenting the changes in #2292 is #24136 (untouched since July).

----------
nosy: +terry.reedy
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> document PEP 448: unpacking generalization
title: Document of star operator missing. It must be documented for better understanding. -> Document of new star unpacking is missing.
versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar 11 18:52:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 11 Mar 2016 23:52:00 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457740320.93.0.421157375697.issue26512@psf.upfronthosting.co.za>


Martin Panter added the comment:

I have looked at PEP 3141, the history of the documentation in question, and the documentation of the functions in the ?math? module. It seems that trunc(), floor() and ceil() were all intended to return a numbers.Integral type, but then PEP 3141?s floor() and ceil() were reverted from Python 2 due to compatibility concerns, where they only accept and return float objects. So it would be correct to clarify that Integral means numbers.Integral.

The term ?integral float? was added by revision 94eeaeeb3ce9, to mean a Python float() object that represents an integer. This is correct (but hard to understand) for Python 2, but the change is not appropriate for Python 3, where floor() and ceil() follow PEP 3141 instead and do return integers (numbers.Integral).

I propose to just point to the proper math.trunc(), round() etc documentation and remove the table (originally added in revision 4f9723d9ca32). Julien: do you think the definitions in <https://docs.python.org/3.5/library/math.html#number-theoretic-and-representation-functions> are understandable?

Also I noticed Python 3?s floor() and ceil() doc strings say int not numbers.Integral. That should probably also be fixed.

Julien, if you agree with my suggestion, do you still want to do a patch for this? Otherwise, I could have a go when I get a chance.

----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri Mar 11 18:58:27 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Mar 2016 23:58:27 +0000
Subject: [docs] [issue26511] Add link to id() built-in in comparison
 operator documentation for "is"
In-Reply-To: <1457451562.01.0.849547274402.issue26511@psf.upfronthosting.co.za>
Message-ID: <1457740707.74.0.444122607519.issue26511@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There is not 'integer caching in Python'.  This is strictly an implementation feature of CPython, and any other implementation that does similarly.

"or id(x) == id(y)" should be "(id(x) == id(y))" as the addition is an alternate wording, not an alternate condition.  I am not sure that this will always be helpful.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar 11 19:18:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Mar 2016 00:18:21 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457741901.18.0.833253631202.issue26525@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The easily misread "ord('?')" could be expanded to "ord('?') (Greek nu)" but I agree that "ord('?') (Euro sign)" would be either better for a global doc.  (And the return is 8364.)  If no objection (Benjamin? Nick?), I am willing to do it for 3.5/6

There is no need to change the 2.7 version "ord(u'\u2020') returns 8224."

----------
nosy: +terry.reedy
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.6

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

From report at bugs.python.org  Fri Mar 11 19:28:18 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Mar 2016 00:28:18 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457742498.18.0.826211006135.issue26535@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/issue26535>
_______________________________________

From report at bugs.python.org  Fri Mar 11 19:51:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 12 Mar 2016 00:51:09 +0000
Subject: [docs] [issue21910] File protocol should document if writelines
 must handle generators sensibly
In-Reply-To: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>
Message-ID: <1457743869.45.0.98982221435.issue21910@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 11 20:50:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 12 Mar 2016 01:50:05 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457747404.9.0.388906550509.issue26535@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks good to me, though it should be applied to all three unpack functions and Struct methods, and the doc strings (struct.unpack.__doc__ etc).

An alternative wording is already used for struct.iter_unpack(): ?the buffer?s size in bytes?. Maybe that is slightly clearer, but it?s no big deal.

----------
stage: needs patch -> patch review
versions: +Python 3.5

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

From report at bugs.python.org  Fri Mar 11 21:49:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 12 Mar 2016 02:49:22 +0000
Subject: [docs] [issue26511] Add link to id() built-in in comparison
 operator documentation for "is"
In-Reply-To: <1457451562.01.0.849547274402.issue26511@psf.upfronthosting.co.za>
Message-ID: <1457750962.57.0.0270722080258.issue26511@psf.upfronthosting.co.za>


Martin Panter added the comment:

Please don?t use nested brackets like that in English text. Try to rewrite the sentence without brackets (e.g. use a comma or say ?This is equivalent to?) [or use a different kind of bracket if you really must (to make the nesting clearer)].

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

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

From report at bugs.python.org  Sat Mar 12 01:33:03 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Mar 2016 06:33:03 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1457764383.09.0.22555443673.issue13305@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> About Elena Oat's patch issue13305.diff: I'm not sure that
> strftime("%4Y") works on all platforms

It doesn't, that's what the patch is trying to document.
AFAICT it works on my Linux (but not on yours), it gives '4Y' on Mac, and raises an error on Windows.  This should depend on the libc used by system, so the same OS can give different results depending on which libc it uses, and the only sure thing is that %4Y is not a portable solution.
FWIW the patch LGTM (except a couple minor nits -- zero-pad should be hyphenated and there should be a double space after the dot), but I'm not sure if it's better mentioning platforms at all or just being vague and say that it works on some platforms but not others and leave up to the user figuring out where.

----------

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

From report at bugs.python.org  Sat Mar 12 02:10:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Mar 2016 07:10:52 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1457766652.43.0.117032983039.issue13305@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> About Elena Oat's patch issue13305.diff: I'm not sure that
>> strftime("%4Y") works on all platforms

> It doesn't, that's what the patch is trying to document.

Oh. I confirm: %4Y gives "4Y" for any year on FreeBSD and Mac OS X, it raises ValueError("Invalid format string") on Windows, etc.

----------

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

From report at bugs.python.org  Sat Mar 12 02:14:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Mar 2016 07:14:52 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1457766892.88.0.426917365236.issue13305@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Elena's issue13305.diff:

"Zero padding can be forced on some platforms by using e.g. ``%4Y``"

Sorry, I still doesn't understand the change. %4Y doesn't work with strptime() and it only work with strftime() on very few platforms.

Can you explain when %4Y should be used? strftime() and/or strptime()? Which platform?

To me, it looks wrong to document %4Y since it almost never works...

----------

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

From report at bugs.python.org  Sat Mar 12 02:17:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Mar 2016 07:17:11 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <20160312071708.10736.6341@psf.io>


Roundup Robot added the comment:

New changeset e54224e8d6a9 by Victor Stinner in branch 'default':
Revert change 291d47954618
https://hg.python.org/cpython/rev/e54224e8d6a9

----------

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

From report at bugs.python.org  Sat Mar 12 04:34:15 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Mar 2016 09:34:15 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1457775255.46.0.748187068687.issue26205@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> enhancement

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

From report at bugs.python.org  Sat Mar 12 06:08:47 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 11:08:47 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457780927.1.0.749707456205.issue26512@psf.upfronthosting.co.za>


Julien added the comment:

Hi Martin, awesome work you've done here. I was meditating those past days about the subject and came to a similar yet not that good conclusion that the table should have the same definitions than those from [library/math.html](https://docs.python.org/3.5/library/math.html#number-theoretic-and-representation-functions). But your solution is better, copy-paste is wrong, let's just link to the right documentation, in which case, a simple list is enough, there is no need for a table.

The definitions in the *library/math.html* and *library/functions.html* (for round) are perfectly clear and understandable, and properly link to number.Integral each time it's used. For the record:

    math.trunc(x)
    Return the Real value x truncated to an Integral (usually an integer). Delegates to x.__trunc__().

    math.ceil(x)
    Return the ceiling of x, the smallest integer greater than or equal to x. If x is not a float, delegates to x.__ceil__(), which should return an Integral value.

    math.floor(x)
    Return the floor of x, the largest integer less than or equal to x. If x is not a float, delegates to x.__floor__(), which should return an Integral value.

    round(number[, ndigits])
    Return the floating point value number rounded to ndigits digits after the decimal point. If ndigits is omitted, it returns the nearest integer to its input. Delegates to number.__round__(ndigits).

    For the built-in types supporting round(), values are rounded to the closest multiple of 10 to the power minus ndigits; if two multiples are equally close, rounding is done toward the even choice (so, for example, both round(0.5) and round(-0.5) are 0, and round(1.5) is 2). The return value is an integer if called with one argument, otherwise of the same type as number.

    Note The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it?s a result of the fact that most decimal fractions can?t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information.

About the docstrings not being the same as the documentation, is there a "best practice" on how it should be ? Should'nt them always be the same ?

Here's a first patch to replace the table with a simple list.

----------
keywords: +patch
Added file: http://bugs.python.org/file42144/stdtypes.patch

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

From report at bugs.python.org  Sat Mar 12 06:33:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Mar 2016 11:33:21 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457782401.8.0.0181384090957.issue26512@psf.upfronthosting.co.za>


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


----------
nosy: +jyasskin

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

From report at bugs.python.org  Sat Mar 12 07:42:31 2016
From: report at bugs.python.org (Varpu Rantala)
Date: Sat, 12 Mar 2016 12:42:31 +0000
Subject: [docs] [issue26250] no document for sqlite3.Cursor.connection
In-Reply-To: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>
Message-ID: <1457786551.51.0.63035534422.issue26250@psf.upfronthosting.co.za>


Varpu Rantala added the comment:

The sentencing was complicated. I changed the formulation and added an example of connection.

----------
nosy: +Varpu Rantala
Added file: http://bugs.python.org/file42146/issue26250.diff

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

From report at bugs.python.org  Sat Mar 12 08:42:49 2016
From: report at bugs.python.org (HyeSoo Park)
Date: Sat, 12 Mar 2016 13:42:49 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1457790169.45.0.667741094817.issue26176@psf.upfronthosting.co.za>


HyeSoo Park added the comment:

Could you please specify which example of the Provisional API among 2 examples of the documentation and how does it not work? Thank you

----------
nosy: +flyjwayur

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

From report at bugs.python.org  Sat Mar 12 09:42:57 2016
From: report at bugs.python.org (Susan Sun)
Date: Sat, 12 Mar 2016 14:42:57 +0000
Subject: [docs] [issue26014] Guide users to the newer package install
 instructions
In-Reply-To: <1451999065.99.0.467691766338.issue26014@psf.upfronthosting.co.za>
Message-ID: <1457793777.01.0.12058209636.issue26014@psf.upfronthosting.co.za>


Susan Sun added the comment:

Below two issues are fixed. 

* add See Also links to the modern docs from the legacy docs
* append the (Legacy) suffix in the 2.x docs

----------
keywords: +patch
nosy: +Susan Sun, ezio.melotti
Added file: http://bugs.python.org/file42148/issue26014.diff

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

From report at bugs.python.org  Sat Mar 12 09:50:06 2016
From: report at bugs.python.org (Anna Koroliuk)
Date: Sat, 12 Mar 2016 14:50:06 +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: <1457794206.58.0.230212257345.issue26483@psf.upfronthosting.co.za>


Anna Koroliuk added the comment:

Hi, all!

At Helsinki Python sprint I with the kind help of Ezio found two things. 

1) This code gives results which are attached in the file. I will just now show some interesting cases where isdigit() and isdecimal() give different results.

for c in map(chr, range(0x10FFFF)):
if unicodedata.digit(c, None) is not None: print(c, c.isdigit(), c.isdecimal())
... 

0 True True
1 True True
2 True True
? True False
? True False
? True False
? True False
? True False
? True False
? True False
? True False
? True False
? True False

So it's different commands, although for usual digits 0-9 in usual typewriting without those upper indexes etc they give same results. Full file command_comparison.txt is attached. 

2) Both commands isdigit() and isdecimal() are traced back that symbol is compared to a certain tables (masks), but masks are different. For isdigit() it is DIGIT_MASK = 0x04 and for isdecimal() is DECIMAL_MASK 0x02.

Here is how all the commands are traced to the mask. 

A) isdecimal()

./Objects/unicodeobject.c:    {"isdecimal", (PyCFunction) unicode_isdecimal, METH_NOARGS, isdecimal__doc__},

./Objects/unicodeobject.c:
static PyObject*
unicode_isdecimal(PyObject *self)
....
    if (length == 1)
        return PyBool_FromLong(
            Py_UNICODE_ISDECIMAL(PyUnicode_READ(kind, data, 0)));

./Include/unicodeobject.h:#define Py_UNICODE_ISDECIMAL(ch) _PyUnicode_IsDecimalDigit(ch)

./Objects/unicodectype.c:
int _PyUnicode_IsDecimalDigit(Py_UCS4 ch)
{
    if (_PyUnicode_ToDecimalDigit(ch) < 0)
        return 0;
    return 1;
}

int _PyUnicode_ToDecimalDigit(Py_UCS4 ch)
{
    const _PyUnicode_TypeRecord *ctype = gettyperecord(ch);

    return (ctype->flags & DECIMAL_MASK) ? ctype->decimal : -1;
}
./Objects/unicodectype.c:#define DECIMAL_MASK 0x02

B) isdigit()

./Objects/unicodeobject.c:    {"isdigit", (PyCFunction) unicode_isdigit, METH_NOARGS, isdigit__doc__},

./Objects/unicodeobject.c: static PyObject*
unicode_isdigit(PyObject *self)
...
    if (length == 1) {
        const Py_UCS4 ch = PyUnicode_READ(kind, data, 0);
        return PyBool_FromLong(Py_UNICODE_ISDIGIT(ch));
    }

./Include/unicodeobject.h:#define Py_UNICODE_ISDIGIT(ch) _PyUnicode_IsDigit(ch)

./Objects/unicodectype.c: int _PyUnicode_IsDigit(Py_UCS4 ch)
{
    if (_PyUnicode_ToDigit(ch) < 0)
        return 0;
    return 1;
}

int _PyUnicode_ToDigit(Py_UCS4 ch)
{
    const _PyUnicode_TypeRecord *ctype = gettyperecord(ch);

    return (ctype->flags & DIGIT_MASK) ? ctype->digit : -1;
}

./Tools/unicode/makeunicodedata.py:DIGIT_MASK = 0x04

BR,
Anna

----------
nosy: +Anna Koroliuk
Added file: http://bugs.python.org/file42149/command_comparison.txt

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

From report at bugs.python.org  Sat Mar 12 09:50:24 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 14:50:24 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
Message-ID: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>


New submission from Julien:

Hi,

The [french translation of the Python documentation](https://github.com/afpy/python_doc_fr) just hit a 21% coverage in terms of pageviews (According to statistics [nicely provided by EWDurbin](https://github.com/AFPy/python_doc_fr/issues/32#issuecomment-195071379)). (It's 14% of the total strings to translate).

I think it may be a good time to push the translation to *docs.python.org*, so french speaking people will be able to find it naturally, and more translators will be aware of it, increasing the translation speed.

Also it will probably motivate other translations (http://docs.python.jp/3/, http://docs.python.org.ar/tutorial/3/index.html, others ?) to work in a more standardized ways, and make their translations more discoverable.

So there's two discussions to have: The URL, and the "how".

# URL

I think the only reasonable possibility is *docs.python.org/{country_code}/*

Having a CCTLD per translation is near impossible (a LOT or work and highly time consuming) as some domains are unavailable like python.fr and some other have high restrictions like having a physical presence in the country (like python.ca, python.pt.br) or having a commercial relation with a local company like for python.com.tr).

Also it allows localization via *docs.python.org/fr_FR/* even if I don't think we need it soon.

If you have other ideas, better than *docs.python.org/fr/*, that's why this issue is opened.

# How to

We have a [Makefile](https://github.com/AFPy/python_doc_fr/blob/master/Makefile) which like [docsbuild-scripts](https://github.com/python/docsbuild-scripts) delegates naturally most of its work to the sphinx Makefile in *Doc/Makefile*, and is capable of building french versions of 2.7, 3.3, 3.4, and 3.5 in a simple invocation of `make build_all MODE=autobuild-stable` (cloning itself from the github repository, applying various patches (typically to configure sphinx to generate french). 3.2 is also possible but not built by default (no autobuild-html in its sphinx Makefile). 

I think docsbuild-scripts may delegate the french generation by simply cloning/updating our repository and calling our makefile. A patch (attached) will be necessary in docsbuild-scripts to copy generated doc to /fr/ and send purges to the CDN.

Finally, once all this is running, we'll start a discussion about cross-linking both documentations, probably reopening https://github.com/sphinx-doc/sphinx/issues/1246.

----------
assignee: docs at python
components: Documentation
files: build_doc_fr.patch
keywords: patch
messages: 261654
nosy: benjamin.peterson, docs at python, sizeof
priority: normal
severity: normal
status: open
title: Provide translated french translation on docs.python.org
type: enhancement
Added file: http://bugs.python.org/file42150/build_doc_fr.patch

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

From report at bugs.python.org  Sat Mar 12 16:31:15 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 21:31:15 +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: <1457818275.65.0.809023061424.issue26483@psf.upfronthosting.co.za>


Julien added the comment:

To dig further, the DIGIT_MASK and DECIMAL_MASK used in `unicodeobject.c` are from `unicodectype.c` and they match values from `unicodetype_db.h` witch is generated by `Tools/unicode/makeunicodedata.py` which built those masks this way:

    # decimal digit, integer digit
    decimal = 0
    if record[6]:
        flags |= DECIMAL_MASK
        decimal = int(record[6])
    digit = 0
    if record[7]:
        flags |= DIGIT_MASK
        digit = int(record[7])
    if record[8]:
        flags |= NUMERIC_MASK
        numeric.setdefault(record[8], []).append(char)

Those "record"s are documented in ftp://unicode.org/Public/3.2-Update/UnicodeData-3.2.0.html in which fields 6, 7, and 8 are:

 - 6	Decimal digit value	N	This is a numeric field. If the character has the decimal digit property, as specified in Chapter 4 of the Unicode Standard, the value of that digit is represented with an integer value in this field

 - 7	Digit value	N	This is a numeric field. If the character represents a digit, not necessarily a decimal digit, the value is here. This covers digits which do not form decimal radix forms, such as the compatibility superscript digits

 - 8	Numeric value	N	This is a numeric field. If the character has the numeric property, as specified in Chapter 4 of the Unicode Standard, the value of that character is represented with an integer or rational number in this field. This includes fractions as, e.g., "1/5" for U+2155 VULGAR FRACTION ONE FIFTH Also included are numerical values for compatibility characters such as circled numbers.

Which is very close of the actual documentation. Yet the documentation is misleading using "This category includes digit characters" in the "isdecimal" documentation.

Posssible rewriting:

isdecimal: 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 decimal-radix numbers, e.g. U+0660, ARABIC-INDIC DIGIT ZERO. Formally a decimal character is a character in the Unicode General Category "Nd".

isdigit: 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 do not form decimal radix forms. Formally, a digit is a character that has the property value Numeric_Type=Digit or Numeric_Type=Decimal.

I don't think we can refactor more than this without rewriting documentation for isnumeric which mentions the Unicode standard the same way.

----------
nosy: +sizeof

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

From report at bugs.python.org  Sat Mar 12 16:36:07 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 21:36:07 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1457818567.85.0.969960764192.issue26176@psf.upfronthosting.co.za>


Julien added the comment:

Is this your bug:

  Traceback (most recent call last):
    File "/tmp/email_example.py", line 9, in <module>
      with open(textfile) as fp:
  NameError: name 'textfile' is not defined

?

If not, can you please provide us the full traceback ?

----------
nosy: +sizeof

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

From report at bugs.python.org  Sat Mar 12 17:23:24 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 22:23:24 +0000
Subject: [docs] [issue26547] Undocumented use of the term dictproxy in
 vars() documentation
Message-ID: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za>


New submission from Julien:

I spotted un undocumented term here : https://docs.python.org/3.5/library/functions.html#vars

in: "Objects such as modules and instances have an updateable __dict__ attribute; however, other objects may have write restrictions on their __dict__ attributes (for example, classes use a dictproxy to prevent direct dictionary updates)."

The term "dictproxy" is not documented anywhere in the documentation, I assume it's a https://docs.python.org/3.4/library/types.html#types.MappingProxyType, which is right:

    >>> class Foo():
    ...     pass
    ... 
    >>> vars(Foo)
    mappingproxy({'__doc__': None, '__weakref__': <attribute '__weakref__' of 'Foo' objects>, '__dict__': <attribute '__dict__' of 'Foo' objects>, '__module__': '__main__'})

So I propose a patch to link to it via a :class:`dictproxy <types.MappingProxyType>`.

Should we leave "dictproxy" or change it to "mappingproxy" ?

----------
assignee: docs at python
components: Documentation
files: dictproxy.patch
keywords: patch
messages: 261665
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Undocumented use of the term dictproxy in vars() documentation
type: enhancement
Added file: http://bugs.python.org/file42152/dictproxy.patch

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

From report at bugs.python.org  Sat Mar 12 17:44:26 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 22:44:26 +0000
Subject: [docs] [issue26548] Probably missing word in a sentence in the doc
 of bitwise operations on integer types
Message-ID: <1457822666.05.0.586831290634.issue26548@psf.upfronthosting.co.za>


New submission from Julien:

In https://docs.python.org/3.5/library/stdtypes.html#bitwise-operations-on-integer-types the sentence "this assumes a sufficiently large number of bits that no overflow occurs during the operation" looks wrong to me, so I asked on #python and got from @benzrf:

"this assumes that there are sufficiently many bits for no overflow to occur during the operation"

Which looks better to me.

----------
assignee: docs at python
components: Documentation
messages: 261667
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Probably missing word in a sentence in the doc of bitwise operations on integer types
type: enhancement

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

From report at bugs.python.org  Sun Mar 13 00:28:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Mar 2016 05:28:19 +0000
Subject: [docs] [issue26547] Undocumented use of the term dictproxy in
 vars() documentation
In-Reply-To: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za>
Message-ID: <1457846899.36.0.219691005608.issue26547@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would add a space between "dict" and "proxy".

----------
nosy: +martin.panter, serhiy.storchaka

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

From report at bugs.python.org  Sun Mar 13 00:44:30 2016
From: report at bugs.python.org (Alejandro Soini)
Date: Sun, 13 Mar 2016 05:44:30 +0000
Subject: [docs] [issue26550] documentation minor issue : "Step back: WSGI"
 section from "HOWTO Use Python in the web"
Message-ID: <1457847869.95.0.52045610793.issue26550@psf.upfronthosting.co.za>


New submission from Alejandro Soini:

Bad article usage in the following sentence from the WSGI section on HOWTO Use Python in the web (https://docs.python.org/2/howto/webservers.html#wsgi) :

"Authentication is another a problem easily solved using existing middleware."

suggested change:

"Authentication is another problem that is easily solved using existing middleware."

----------
assignee: docs at python
components: Documentation
messages: 261671
nosy: Alejandro Soini, docs at python
priority: normal
severity: normal
status: open
title: documentation minor issue : "Step back: WSGI" section from "HOWTO Use Python in the web"
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Mar 13 01:48:48 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 06:48:48 +0000
Subject: [docs] [issue26548] Probably missing word in a sentence in the doc
 of bitwise operations on integer types
In-Reply-To: <1457822666.05.0.586831290634.issue26548@psf.upfronthosting.co.za>
Message-ID: <1457851728.52.0.34951201944.issue26548@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/issue26548>
_______________________________________

From report at bugs.python.org  Sun Mar 13 01:58:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Mar 2016 06:58:54 +0000
Subject: [docs] [issue26548] Probably missing word in a sentence in the doc
 of bitwise operations on integer types
In-Reply-To: <1457822666.05.0.586831290634.issue26548@psf.upfronthosting.co.za>
Message-ID: <20160313065850.118695.73657@psf.io>


Roundup Robot added the comment:

New changeset b9256d5f1ab4 by Raymond Hettinger in branch '3.5':
Issue #26548:  Minor fix to awkward wording in docs
https://hg.python.org/cpython/rev/b9256d5f1ab4

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

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

From report at bugs.python.org  Sun Mar 13 01:59:42 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 06:59:42 +0000
Subject: [docs] [issue26548] Probably missing word in a sentence in the doc
 of bitwise operations on integer types
In-Reply-To: <1457822666.05.0.586831290634.issue26548@psf.upfronthosting.co.za>
Message-ID: <1457852382.51.0.469290763281.issue26548@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 13 03:09:02 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 07:09:02 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457852942.05.0.318807562542.issue26512@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think taking the table out makes the docs better.  It just removes a source of information just because the OP stumbled on the word "integral" which has both a standard (albeit erudite) meaning in Engligh and a precise meaning in the context of PEP-3141.   I recommend leaving the table as-is and linking to the PEP or to the numbers module so that an interested person can delved deeper if needed.  The table communicates a central concept that there are differences in the several ways to convert a float to an integer.

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

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

From report at bugs.python.org  Sun Mar 13 03:12:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 07:12:50 +0000
Subject: [docs] [issue26511] Add link to id() built-in in comparison
 operator documentation for "is"
In-Reply-To: <1457451562.01.0.849547274402.issue26511@psf.upfronthosting.co.za>
Message-ID: <1457853170.39.0.815534240563.issue26511@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I agree with the OP that is would be useful to link to id().  I also concur with Terry that integer caching is to remain an undocumented implementation specific detail (just an optimization).  Also, Martin is correct that the proposed wording doesn't read well.

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

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

From report at bugs.python.org  Sun Mar 13 03:14:56 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 07:14:56 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457853296.33.0.347107126841.issue26535@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The proposed wording looks fine.

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

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

From report at bugs.python.org  Sun Mar 13 03:17:06 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Mar 2016 07:17:06 +0000
Subject: [docs] [issue26511] Add link to id() built-in in comparison
 operator documentation for "is"
In-Reply-To: <1457451562.01.0.849547274402.issue26511@psf.upfronthosting.co.za>
Message-ID: <1457853426.57.0.674031225361.issue26511@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Mar 13 03:22:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Mar 2016 07:22:27 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457853747.16.0.069381564688.issue26535@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 13 03:22:35 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 07:22:35 +0000
Subject: [docs] [issue26545] os.walk is limited by python's recursion limit
In-Reply-To: <1457744340.04.0.931517157669.issue26545@psf.upfronthosting.co.za>
Message-ID: <1457853755.27.0.710279856241.issue26545@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I think the code should be left as-is (we've used some variation of recursion for walking a very long time with no reported real-world problems).  Perhaps a documentation note can be added to the effect that the there is a recursion limit and that it can be changed by the user if needed.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, rhettinger
priority: normal -> low

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

From report at bugs.python.org  Sun Mar 13 03:23:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Mar 2016 07:23:07 +0000
Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1457853787.55.0.0476040581871.issue26535@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 13 03:24:51 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Mar 2016 07:24:51 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1457853891.17.0.102138693749.issue26525@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I concur that the Euro sign would be best (more recognizable and more likely to be renderable in a given font).

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

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

From report at bugs.python.org  Sun Mar 13 03:56:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 13 Mar 2016 07:56:10 +0000
Subject: [docs] [issue26547] Undocumented use of the term dictproxy in
 vars() documentation
In-Reply-To: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za>
Message-ID: <1457855770.11.0.525324959146.issue26547@psf.upfronthosting.co.za>


Martin Panter added the comment:

In Python 2, the class was called ?dictproxy?, the repr() used ?dict_proxy? with an underscore, and it is exposed as types.DictProxyType. So I guess that is where the term comes from. In Python 3.3, Issue 14386 renamed the class and repr() to ?mappingproxy?, and re-introduced it to types as MappingProxyType. (DictProxyType was previously removed in revision 15649aef2db5.)

So in Python 3 I would probably change it from ?dictproxy? to a types.MappingProxyType link.

----------

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

From report at bugs.python.org  Sun Mar 13 04:58:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 13 Mar 2016 08:58:31 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457859511.12.0.638923782831.issue26512@psf.upfronthosting.co.za>


Martin Panter added the comment:

Julien: I tend to keep doc strings rather concise. Just mention the main points, not all the obscure corner cases or examples. In this case I would probably just change ?int? to ?integer? (lowercase) or ?numbers.Integral? if you want to be specific. You might also want to change ?integral value? ? ?integer?.

Raymond: If you want to keep the table, please also fix the ?integral float? references in Python 3 as well. Also see footnote (3) for the previous table, which also covers rounding.

I would still suggest to remove the empty ?Notes? column. If there are any details worthy of footnotes, they should be added to the main documentation, not this table.

----------

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

From report at bugs.python.org  Sun Mar 13 05:43:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Mar 2016 09:43:04 +0000
Subject: [docs] [issue24918] Docs layout bug
In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za>
Message-ID: <20160313094300.20929.67854@psf.io>


Roundup Robot added the comment:

New changeset 78e9c18d3e5b by Ezio Melotti in branch '3.5':
#24918: fix CSS for code blocks when a side box is present.  Patch by Manvi B.
https://hg.python.org/cpython/rev/78e9c18d3e5b

New changeset 444d80ae123e by Ezio Melotti in branch 'default':
#24918: merge with 3.5.
https://hg.python.org/cpython/rev/444d80ae123e

New changeset e3833106f612 by Ezio Melotti in branch '2.7':
#24918: fix CSS for code blocks when a side box is present.  Patch by Manvi B.
https://hg.python.org/cpython/rev/e3833106f612

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

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

From report at bugs.python.org  Sun Mar 13 05:44:42 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Mar 2016 09:44:42 +0000
Subject: [docs] [issue24918] Docs layout bug
In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za>
Message-ID: <1457862282.09.0.215497485592.issue24918@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch(es)!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar 13 05:55:40 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Mar 2016 09:55:40 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1457862940.84.0.195226804475.issue26176@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

#26426 has been marked as duplicate of this, and contains more information about the error.

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sun Mar 13 05:58:06 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Mar 2016 09:58:06 +0000
Subject: [docs] [issue26250] no document for sqlite3.Cursor.connection
In-Reply-To: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>
Message-ID: <1457863086.66.0.0116785489834.issue26250@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
stage:  -> patch review

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

From report at bugs.python.org  Sun Mar 13 14:23:07 2016
From: report at bugs.python.org (Julien)
Date: Sun, 13 Mar 2016 18:23:07 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457893387.64.0.794753103981.issue26512@psf.upfronthosting.co.za>


Julien added the comment:

Daily meditations:

 - This table is nice to show that there's various operations common to int and float (and does it well), not to list rounding methods (it happen to have only rounding methods, but that's a coincidence).

 - A coma separated list like ":func:`math.trunc`, :func:`round`, :func:`math.floor`, and :func:`math.ceil`." are enough to list them and to show they contain various rounding methods which is clear about the fact they are a bit different.

 - Yet we have to be both readable for everybody and ultra precise about implementation for those implementing their own __floor__, and the math module does it really nicely.

But we can keep the table without the empty "Notes" column, leaving place to explain them with more words, so they  can be more readable, approaching this way the readability of the math module ?

Finally, the problem is the conciseness of the result column (which make me think a link is better than a too-concise explanation).

----------

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

From report at bugs.python.org  Sun Mar 13 23:10:29 2016
From: report at bugs.python.org (Robert Collins)
Date: Mon, 14 Mar 2016 03:10:29 +0000
Subject: [docs] [issue23890] assertRaises increases reference counter
In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za>
Message-ID: <1457925029.7.0.791930241613.issue23890@psf.upfronthosting.co.za>


Robert Collins added the comment:

I don't think we make any guarantees for or against references, but - we attempt to free references already (see how we call clear_frames), so this is a bug, pure and simple.

----------

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

From report at bugs.python.org  Mon Mar 14 02:23:18 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Mar 2016 06:23:18 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457936598.3.0.928413720941.issue26512@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Julian, I don't see a bug here and think you've ventured too far into stylistic micro-rewordings.   If there is something unintelligible, we'll fix it, but this tracker item has lost focus and isn't using people's time efficiently (i.e. this isn't a forum for "daily meditations").

----------

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

From report at bugs.python.org  Mon Mar 14 02:23:33 2016
From: report at bugs.python.org (Sudheer Satyanarayana)
Date: Mon, 14 Mar 2016 06:23:33 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
Message-ID: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>


New submission from Sudheer Satyanarayana:

"The Requests package is recommended for a higher-level http client interface."
Change 'http' to uppercase.
https://docs.python.org/2/library/httplib.html
https://docs.python.org/2/library/urllib.html
https://docs.python.org/3/library/http.client.html

----------
assignee: docs at python
components: Documentation
messages: 261726
nosy: Sudheer Satyanarayana, docs at python
priority: normal
severity: normal
status: open
title: Write HTTP in uppercase

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

From report at bugs.python.org  Mon Mar 14 02:27:14 2016
From: report at bugs.python.org (Julien)
Date: Mon, 14 Mar 2016 06:27:14 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457936833.95.0.323534740452.issue26512@psf.upfronthosting.co.za>


Julien added the comment:

I completely agree we're consuming too much time for what it is, sry for that. Let's just link to numbers.Integral and close it.

I attached a simple patch for it.

----------
Added file: http://bugs.python.org/file42157/stdtypes-integral.patch

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

From storchaka at gmail.com  Mon Mar 14 03:44:31 2016
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Mon, 14 Mar 2016 07:44:31 -0000
Subject: [docs] Vocabulary: Using "integral" in library/stdtypes.html (issue
 26512)
Message-ID: <20160314074431.26960.9422@psf.upfronthosting.co.za>


http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode364
Doc/library/stdtypes.rst:364:
+--------------------+------------------------------------+--------+
Remained pluses are not needed. May be this is error.

http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode367
Doc/library/stdtypes.rst:367: | ``math.trunc(x)``  | *x* truncated to
:class:`numbers.Integral`  |
I would write :class:`~numbers.Integral`.

http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode367
Doc/library/stdtypes.rst:367: | ``math.trunc(x)``  | *x* truncated to
:class:`numbers.Integral`  |
I'm wandering, is it possible to make a link from ``math.trunc(x)`` to
the math.trunc() function?

http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode369
Doc/library/stdtypes.rst:369: | ``round(x[, n])``  | *x* rounded to n
digits,                    |
"n" should be emphasized as well as "x": *n*.

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

From report at bugs.python.org  Mon Mar 14 03:46:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Mar 2016 07:46:45 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1457941604.96.0.269054348063.issue26512@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Georg, is it possible to make a link from formatted text ``math.trunc(x)`` to the math.trunc() function?

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

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

From report at bugs.python.org  Mon Mar 14 03:49:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Mar 2016 07:49:23 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1457941763.87.0.116746016994.issue26553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide a patch Sudheer?

----------
keywords: +easy
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6

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

From georg at python.org  Mon Mar 14 03:47:40 2016
From: georg at python.org (georg at python.org)
Date: Mon, 14 Mar 2016 07:47:40 -0000
Subject: [docs] Vocabulary: Using "integral" in library/stdtypes.html
 (issue 26512)
Message-ID: <20160314074740.3720.52621@psf.upfronthosting.co.za>


http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode364
Doc/library/stdtypes.rst:364:
+--------------------+------------------------------------+--------+
On 2016/03/14 08:44:32, storchaka wrote:
> Remained pluses are not needed. May be this is error.

Indeed, the pluses should be changed to minuses.

http://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode367
Doc/library/stdtypes.rst:367: | ``math.trunc(x)``  | *x* truncated to
:class:`numbers.Integral`  |
On 2016/03/14 08:44:32, storchaka wrote:
> I'm wandering, is it possible to make a link from ``math.trunc(x)`` to
the
> math.trunc() function?

You could write
 :func:`math.trunc`\ ``(x)`` 
or
 :func:`math.trunc(x) <math.trunc>`

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

From report at bugs.python.org  Mon Mar 14 06:28:59 2016
From: report at bugs.python.org (Akira Li)
Date: Mon, 14 Mar 2016 10:28:59 +0000
Subject: [docs] [issue23220] Documents input/output effects of how IDLE runs
 user code
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1457951339.35.0.230460841099.issue23220@psf.upfronthosting.co.za>


Akira Li added the comment:

IDLE can implement functionality similar to what colorama [1] module does on Windows: translate ANSI escape character sequences into corresponding GUI method calls.

For example, \b might be implemented using a .delete() call, \r using .mark_set(), etc.

[1] https://pypi.python.org/pypi/colorama

----------
nosy: +akira

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

From report at bugs.python.org  Mon Mar 14 07:27:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Mar 2016 11:27:11 +0000
Subject: [docs] [issue26557] dictviews methods not present on shelve objects
In-Reply-To: <1457954340.57.0.630883947605.issue26557@psf.upfronthosting.co.za>
Message-ID: <1457954831.88.0.652494062589.issue26557@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The shelve object inherits its dict-like methods from UserDict.DictMixin. The documentation for UserDict.DictMixin should be updated too.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python, serhiy.storchaka
stage:  -> needs patch

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

From report at bugs.python.org  Mon Mar 14 10:42:03 2016
From: report at bugs.python.org (Anish Shah)
Date: Mon, 14 Mar 2016 14:42:03 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1457966523.48.0.537950577369.issue26553@psf.upfronthosting.co.za>


Anish Shah added the comment:

Patch for urllib and httplib in Python 2

----------
keywords: +patch
nosy: +anish.shah
Added file: http://bugs.python.org/file42159/issue26553.patch

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

From report at bugs.python.org  Mon Mar 14 10:42:30 2016
From: report at bugs.python.org (Anish Shah)
Date: Mon, 14 Mar 2016 14:42:30 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1457966550.13.0.965179679106.issue26553@psf.upfronthosting.co.za>


Anish Shah added the comment:

Patch for http.client in Python3

----------
Added file: http://bugs.python.org/file42160/issue26553-python3.patch

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

From report at bugs.python.org  Mon Mar 14 11:06:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Mar 2016 15:06:12 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1457967972.07.0.271728883746.issue26553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are occurrences of "http" in lower case in docstrings and comments. The same for https and ftp (and may be other abbreviations).

----------

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

From sabarnadh.kintali at gmail.com  Tue Mar 15 01:42:19 2016
From: sabarnadh.kintali at gmail.com (Sabarinath K)
Date: Tue, 15 Mar 2016 11:12:19 +0530
Subject: [docs] Documentation bug
Message-ID: <CAAeRWcezaWvbrPLYZ53of-twL70nfVL8cVaRxJsfQJ28A8cU5g@mail.gmail.com>

Hello,

In the page, https://docs.python.org/3.5/tutorial/controlflow.html

Section 4.4, break statement should be added in else block and output
should be corrected as follows.

>>> for n in range(2,10):
    for x in range(2,n):
        if n%x == 0:
            print(n, 'equals', x , '*',n//x)
            break
        else:
            print(n, 'is a prime number')
            break



*Output:*3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 is a prime number

Best Regards,
Sabarinath,
mail to: sabarnadh.kintali at gmail.com,
(+91) 88677 31530.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160315/78333cf7/attachment.html>

From sabarnadh.kintali at gmail.com  Tue Mar 15 01:45:11 2016
From: sabarnadh.kintali at gmail.com (Sabarinath K)
Date: Tue, 15 Mar 2016 11:15:11 +0530
Subject: [docs] Documentation bug
In-Reply-To: <CAAeRWcezaWvbrPLYZ53of-twL70nfVL8cVaRxJsfQJ28A8cU5g@mail.gmail.com>
References: <CAAeRWcezaWvbrPLYZ53of-twL70nfVL8cVaRxJsfQJ28A8cU5g@mail.gmail.com>
Message-ID: <CAAeRWceb3UL6Cn=tOCFNv8XkPDwrLmcSSXkYcgx1SpgTK9HvKw@mail.gmail.com>

Kindly ignore the previous email. It's my mistake.

Best Regards,
Sabarinath,
mail to: sabarnadh.kintali at gmail.com,
(+91) 88677 31530.

On 15 March 2016 at 11:12, Sabarinath K <sabarnadh.kintali at gmail.com> wrote:

> Hello,
>
> In the page, https://docs.python.org/3.5/tutorial/controlflow.html
>
> Section 4.4, break statement should be added in else block and output
> should be corrected as follows.
>
> >>> for n in range(2,10):
>     for x in range(2,n):
>         if n%x == 0:
>             print(n, 'equals', x , '*',n//x)
>             break
>         else:
>             print(n, 'is a prime number')
>             break
>
>
>
> *Output:*3 is a prime number
> 4 equals 2 * 2
> 5 is a prime number
> 6 equals 2 * 3
> 7 is a prime number
> 8 equals 2 * 4
> 9 is a prime number
>
> Best Regards,
> Sabarinath,
> mail to: sabarnadh.kintali at gmail.com,
> (+91) 88677 31530.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160315/4769d7a2/attachment.html>

From vadmium+py at gmail.com  Mon Mar 14 17:29:25 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 14 Mar 2016 21:29:25 -0000
Subject: [docs] Vocabulary: Using "integral" in library/stdtypes.html
 (issue 26512)
Message-ID: <20160314212925.12310.18961@psf.upfronthosting.co.za>


https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode373
Doc/library/stdtypes.rst:373: | ``math.floor(x)``  | the greatest
integral float <= *x*          |
For Python 3:

the greatest integer <= *x*

or

the greatest :class:`numbers.Integral` <= *x*

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

From report at bugs.python.org  Wed Mar 16 16:56:03 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Mar 2016 20:56:03 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>
Message-ID: <1458161762.91.0.990190423499.issue15660@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This came up again on python-list today in thread "Replace weird error message?" by "the.gerenuk--- via Python-list".  After reading the discussion, I decided that expecting someone to read and connect together two sentences half a page apart is expecting a bit too much.

'''
'=' 	Forces the padding to be placed after the sign (if any) but before the digits. This is used for printing fields in the form ?+000000120?. This alignment option is only valid for numeric types.
'''

Add "It becomes the default when '0' precedes the field width."

''' 
Preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='.
'''

This is not true when an explicit alignment other than '=' is given.
>>> "{:09}".format(-1)
'-00000001'
>>> "{:>09}".format(-1)  # 2.7.11 and 3.5.1
'0000000-1'

Proposal: Replace with
'''
When no explicit alignment is given, preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='.
'''

I presume the problem with changing the error message is that it is not immediately known that alignment was set implicitly, by 0 before decimal width, rather than explicitly.  If the spec string is still available, it could be searched and the message adjusted if '=' is not present.  That proposal should be a new issue if someone wants to push it.

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

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

From report at bugs.python.org  Wed Mar 16 17:03:02 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 16 Mar 2016 21:03:02 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1458161762.91.0.990190423499.issue15660@psf.upfronthosting.co.za>
Message-ID: <56E9CA00.2030302@trueblade.com>


Eric V. Smith added the comment:

> '''
> When no explicit alignment is given, preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='.
> '''

I think that's good.

> I presume the problem with changing the error message is that it is not immediately known that alignment was set implicitly, by 0 before decimal width, rather than explicitly.  If the spec string is still available, it could be searched and the message adjusted if '=' is not present.  That proposal should be a new issue if someone wants to push it.

Yes, that's the problem. I guess it would be easier to keep track of
which fields were set via defaults, and which explicitly. Currently,
that information is lost.

----------

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

From report at bugs.python.org  Wed Mar 16 22:38:34 2016
From: report at bugs.python.org (py.user)
Date: Thu, 17 Mar 2016 02:38:34 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>
Message-ID: <1458182314.17.0.053443562129.issue15660@psf.upfronthosting.co.za>


py.user added the comment:

There is a funny thing in 3.6.0a0

>>> '{:<09}'.format(1)
'100000000'
>>> '{:<09}'.format(10)
'100000000'
>>> '{:<09}'.format(100)
'100000000'
>>>

Actually, it behaves like a string, but the format should call internal format function of the passed number and the internal format function should not format different numbers as equal numbers.

Why does it represent number 1 as number 10?

>>> format(1, '<02')
'10'
>>> format(10, '')
'10'
>>>

I guess, there should be a restriction.
Zero padding for numbers should be correct.

----------

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

From report at bugs.python.org  Thu Mar 17 02:29:58 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 17 Mar 2016 06:29:58 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
Message-ID: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>


New submission from Chris Angelico:

The official documentation declares an unambiguous equivalence which is not true in some corner cases:

    @deco
    def f(x): pass

is not quite the same as

    def f(x): pass
    f = deco(f)

as the name is never bound to the undecorated function. This is what makes @property and @prop.setter work; otherwise, the undecorated setter function would overwrite the property, and the decoration would fail. Attached patch loosens the wording slightly to "broadly equivalent"; this permits corner cases to vary from the equivalence, while still retaining its simplicity for the 99% of cases where it's correct. (Think of explaining "yield from iter" as "for x in iter: yield x" and you have a similar near-equivalence.)

Also, class decorators aren't required to return classes. Text removed saying that they do.

----------
assignee: docs at python
components: Documentation
files: deco-docos.patch
keywords: patch
messages: 261888
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: Tweak wording of decorator docos
Added file: http://bugs.python.org/file42181/deco-docos.patch

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

From report at bugs.python.org  Thu Mar 17 02:36:18 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 17 Mar 2016 06:36:18 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458196578.48.0.162374627407.issue26576@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Question: Is it worth having an explanation somewhere of exactly what *does* happen? To what extent is it guaranteed by the language?

----------

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

From report at bugs.python.org  Thu Mar 17 03:02:08 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Mar 2016 07:02:08 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458198128.24.0.76956021773.issue26576@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The patch is definitely an improvement.

What about a remark like ", except that `deco` is evaluated before the function `f` is created"?  That should cover the remaining difference.

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

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

From report at bugs.python.org  Thu Mar 17 03:02:53 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Mar 2016 07:02:53 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458198173.7.0.800426452082.issue26576@psf.upfronthosting.co.za>


Georg Brandl added the comment:

(Also, toggled your "is committer" bit so you get the Python logo next to your name.)

----------

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

From report at bugs.python.org  Thu Mar 17 03:16:36 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 17 Mar 2016 07:16:36 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458198996.25.0.438002592338.issue26576@psf.upfronthosting.co.za>


Chris Angelico added the comment:

The remaining difference that's actually of use, perhaps. But the decoration itself happens before the name is bound. It's impossible to describe in Python code; but it can be probed - you can monkeypatch a class using a decorator:

def monkeypatch(cls):
    orig = globals()[cls.__name__] # Undocumented magic
    print("Monkeypatch",id(cls),"into",id(orig))
    for attr in dir(cls):
        if not attr.startswith("_"):
            setattr(orig,attr,getattr(cls,attr))
    return orig

class Foo:
    def method1(self):
        print("I am method 1")

print("Foo is currently",id(Foo))
some_object = Foo()

@monkeypatch
class Foo:
    def method2(self):
        print("I am method 2")

print("Foo is now",id(Foo))

some_object.method1()
some_object.method2()



Is this undocumented behaviour? Should it be supported? It works on every Python I've tried it on (CPython 2.7 and 3.6, PyPy2 and PyPy3, Jython, and MicroPython), but it's not something I'd depend on in production code unless it's documented.

----------

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

From report at bugs.python.org  Thu Mar 17 03:17:37 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 17 Mar 2016 07:17:37 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458199057.73.0.054042237065.issue26576@psf.upfronthosting.co.za>


Chris Angelico added the comment:

I may be a committer, but I don't push to cpython - just to the peps. But sure, pretty little logo :)

----------

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

From report at bugs.python.org  Thu Mar 17 03:24:19 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 17 Mar 2016 07:24:19 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458199459.42.0.57433234005.issue26576@psf.upfronthosting.co.za>


Georg Brandl added the comment:

That is definitely supported.  Whether it's actually useful to document, I'm not sure.

"except that the original function is not temporarily bound to the name `f`" could work.

----------

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

From report at bugs.python.org  Thu Mar 17 03:38:17 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 17 Mar 2016 07:38:17 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458200297.84.0.988864187731.issue26576@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Sounds good to me. Replacement patch.

----------
Added file: http://bugs.python.org/file42182/deco-docos.patch

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

From report at bugs.python.org  Thu Mar 17 07:52:24 2016
From: report at bugs.python.org (Alex Walters)
Date: Thu, 17 Mar 2016 11:52:24 +0000
Subject: [docs] [issue26580] Documentation for ftplib still references
 ftpmirror.py
Message-ID: <1458215544.62.0.0104806566658.issue26580@psf.upfronthosting.co.za>


New submission from Alex Walters:

in #23130 ftpmirror.py was removed from the python source distribution.  The documentation still references this, and sends people looking for the file (ostensibly as an example of how to use ftplib).

----------
assignee: docs at python
components: Documentation
messages: 261908
nosy: docs at python, tritium
priority: normal
severity: normal
status: open
title: Documentation for ftplib still references ftpmirror.py
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 17 10:45:53 2016
From: report at bugs.python.org (awilfox)
Date: Thu, 17 Mar 2016 14:45:53 +0000
Subject: [docs] [issue26582] asyncio documentation links to wrong
 CancelledError
Message-ID: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>


New submission from awilfox:

In the 3.5 and 3.6a0 documentation for asyncio, "CancelledError" is linked to the concurrent.futures.CancelledError.  This led me to try catching that exception and finding that it did not work correctly at all.  Only after searching for asyncio example code and seeing how other people caught asyncio.CancelledError did I realise the issue.

The fact asyncio.CancelledError even exists isn't actually documented, and I believe that is why the :exc: reference is linking to the wrong module.

----------
assignee: docs at python
components: Documentation
messages: 261911
nosy: awilfox, docs at python
priority: normal
severity: normal
status: open
title: asyncio documentation links to wrong CancelledError
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 17 10:49:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Mar 2016 14:49:41 +0000
Subject: [docs] [issue26582] asyncio documentation links to wrong
 CancelledError
In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>
Message-ID: <1458226181.31.0.734110607023.issue26582@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar 17 12:44:13 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 17 Mar 2016 16:44:13 +0000
Subject: [docs] [issue26580] Documentation for ftplib still references
 ftpmirror.py
In-Reply-To: <1458215544.62.0.0104806566658.issue26580@psf.upfronthosting.co.za>
Message-ID: <1458233053.94.0.283642112588.issue26580@psf.upfronthosting.co.za>


SilentGhost added the comment:

This patch removes the offending paragraph.

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> patch review
type:  -> behavior
versions: +Python 3.6
Added file: http://bugs.python.org/file42187/issue26580.diff

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

From report at bugs.python.org  Thu Mar 17 13:04:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Mar 2016 17:04:01 +0000
Subject: [docs] [issue23890] assertRaises increases reference counter
In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za>
Message-ID: <1458234241.59.0.684208403376.issue23890@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 18 02:19:53 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 06:19:53 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458281993.34.0.128079011621.issue26553@psf.upfronthosting.co.za>


Changes by Aatish Neupane <aatishnn at gmail.com>:


Added file: http://bugs.python.org/file42197/fix_2.7.patch

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

From report at bugs.python.org  Fri Mar 18 02:20:13 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 06:20:13 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458282013.24.0.298397387445.issue26553@psf.upfronthosting.co.za>


Changes by Aatish Neupane <aatishnn at gmail.com>:


Added file: http://bugs.python.org/file42198/fix_3.5.patch

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

From report at bugs.python.org  Fri Mar 18 02:20:49 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 06:20:49 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458282049.44.0.425948589249.issue26553@psf.upfronthosting.co.za>


Changes by Aatish Neupane <aatishnn at gmail.com>:


Added file: http://bugs.python.org/file42199/fix_3.6.patch

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

From report at bugs.python.org  Fri Mar 18 02:21:52 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 06:21:52 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458282112.78.0.621501284341.issue26553@psf.upfronthosting.co.za>


Aatish Neupane added the comment:

I have attached the patches fixing numerous case errors.

----------
nosy: +aatishnn

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

From report at bugs.python.org  Fri Mar 18 06:48:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 18 Mar 2016 10:48:47 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458298127.06.0.141606631067.issue26553@psf.upfronthosting.co.za>


Martin Panter added the comment:

The three fix_x.y patches look good to me. I pointed out one more fix on the review. I think there are plenty more similar changes that could be made if somebody wanted to.

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

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

From report at bugs.python.org  Fri Mar 18 07:42:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Mar 2016 11:42:14 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458301334.17.0.327715909359.issue26553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Similar changes could be made in docstrings and comments. But changing error messages can be not safe and could be made only in 3.6.

----------

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

From maurice.charbit at telecom-paristech.fr  Fri Mar 18 05:08:00 2016
From: maurice.charbit at telecom-paristech.fr (maurice.charbit at telecom-paristech.fr)
Date: Fri, 18 Mar 2016 10:08:00 +0100
Subject: [docs] why x is changed in the following program?
Message-ID: <951C1857-2586-4438-8F6F-70F7A442FB60@telecom-paristech.fr>

from numpy import random
x=random.randn(6)
y=x
y[0]=12
print x[0]


Maurice Charbit
Emeritus Prof.
mob.: 33 (0)6 5230 1171
tel.: 33 (0)1 4581 7178
fax:  33 (0)1 4581 7144
maurice.charbit at telecom-paristech.fr <mailto:maurice.charbit at telecom-paristech.fr>
Adresse:
Institut Mines-Telecom,
46, rue Barrault, 75014 Paris

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

From vadmium+py at gmail.com  Fri Mar 18 06:48:59 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Fri, 18 Mar 2016 10:48:59 -0000
Subject: [docs] Write HTTP in uppercase (issue 26553)
Message-ID: <20160318104859.19139.20587@psf.upfronthosting.co.za>


https://bugs.python.org/review/26553/diff/16771/Doc/library/urllib.request.rst
File Doc/library/urllib.request.rst (right):

https://bugs.python.org/review/26553/diff/16771/Doc/library/urllib.request.rst#newcode74
Doc/library/urllib.request.rst:74: For HTTP and HTTPS urls, this
function returns a
HTTPS URLs

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

From report at bugs.python.org  Fri Mar 18 08:25:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Mar 2016 12:25:29 +0000
Subject: [docs] [issue26580] Documentation for ftplib still references
 ftpmirror.py
In-Reply-To: <1458215544.62.0.0104806566658.issue26580@psf.upfronthosting.co.za>
Message-ID: <20160318122522.84282.14943.3253CB33@psf.io>


Roundup Robot added the comment:

New changeset 23ad18068814 by Berker Peksag in branch '3.5':
Issue #26580: Remove outdated reference to ftpmirror
https://hg.python.org/cpython/rev/23ad18068814

New changeset 48e106bf2add by Berker Peksag in branch 'default':
Issue #26580: Remove outdated reference to ftpmirror
https://hg.python.org/cpython/rev/48e106bf2add

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

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

From report at bugs.python.org  Fri Mar 18 08:26:49 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 18 Mar 2016 12:26:49 +0000
Subject: [docs] [issue26580] Documentation for ftplib still references
 ftpmirror.py
In-Reply-To: <1458215544.62.0.0104806566658.issue26580@psf.upfronthosting.co.za>
Message-ID: <1458304009.05.0.35610798765.issue26580@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar 18 10:02:12 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 14:02:12 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458309732.01.0.5237070929.issue26553@psf.upfronthosting.co.za>


Changes by Aatish Neupane <aatishnn at gmail.com>:


Added file: http://bugs.python.org/file42201/2_fix_2.7.patch

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

From report at bugs.python.org  Fri Mar 18 10:02:24 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 14:02:24 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458309744.17.0.320626827561.issue26553@psf.upfronthosting.co.za>


Changes by Aatish Neupane <aatishnn at gmail.com>:


Added file: http://bugs.python.org/file42202/2_fix_3.5.patch

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

From report at bugs.python.org  Fri Mar 18 10:02:33 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 14:02:33 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458309752.83.0.457468493052.issue26553@psf.upfronthosting.co.za>


Changes by Aatish Neupane <aatishnn at gmail.com>:


Added file: http://bugs.python.org/file42203/2_fix_3.6.patch

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

From report at bugs.python.org  Fri Mar 18 10:05:09 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Fri, 18 Mar 2016 14:05:09 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458309909.6.0.876068947611.issue26553@psf.upfronthosting.co.za>


Aatish Neupane added the comment:

I found some other similar errors with the suggestion from the patch review. I have uploaded the new patches as 2_fix* .

----------

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

From report at bugs.python.org  Fri Mar 18 12:18:18 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Mar 2016 16:18:18 +0000
Subject: [docs] [issue26240] Docstring of the subprocess module should be
 cleaned up
In-Reply-To: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>
Message-ID: <1458317898.89.0.00657272966144.issue26240@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar 18 12:19:31 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Mar 2016 16:19:31 +0000
Subject: [docs] [issue26246] Code output toggle button uses removed jQuery
 method
In-Reply-To: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>
Message-ID: <1458317971.05.0.0183307215159.issue26246@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks both for spotting the bug and fixing it!

----------

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

From report at bugs.python.org  Fri Mar 18 12:20:07 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Mar 2016 16:20:07 +0000
Subject: [docs] [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <1458318007.81.0.623830434858.issue26248@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> resolved
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar 18 14:13:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Mar 2016 18:13:30 +0000
Subject: [docs] [issue26250] no document for sqlite3.Cursor.connection
In-Reply-To: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>
Message-ID: <20160318181315.84264.21484.5C9F494F@psf.io>


Roundup Robot added the comment:

New changeset 52660878c833 by Ezio Melotti in branch '3.5':
#26250: document the sqlite3.Cursor.connection attribute.  Initial patches by Aviv Palivoda and Varpu Rantala.
https://hg.python.org/cpython/rev/52660878c833

New changeset 6fed752fd88e by Ezio Melotti in branch 'default':
#26250: merge with 3.5.
https://hg.python.org/cpython/rev/6fed752fd88e

New changeset 6dcf60bf855b by Ezio Melotti in branch '2.7':
#26250: document the sqlite3.Cursor.connection attribute.  Initial patches by Aviv Palivoda and Varpu Rantala.
https://hg.python.org/cpython/rev/6dcf60bf855b

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

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

From report at bugs.python.org  Fri Mar 18 14:14:13 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Mar 2016 18:14:13 +0000
Subject: [docs] [issue26250] no document for sqlite3.Cursor.connection
In-Reply-To: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>
Message-ID: <1458324853.66.0.304517506221.issue26250@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patches!

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

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

From report at bugs.python.org  Fri Mar 18 15:37:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Mar 2016 19:37:16 +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: <1458329836.22.0.589041175926.issue26546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree on the url.  It can always redirect to a CCTLD if there is one.

You *might* want to discuss the how on python-ideas list.

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

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

From report at bugs.python.org  Fri Mar 18 15:44:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Mar 2016 19:44:29 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458330269.76.0.053990997217.issue26553@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Aatish, please sign the CLA 
https://www.python.org/psf/contrib/
https://www.python.org/psf/contrib/contrib-form/

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

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

From report at bugs.python.org  Fri Mar 18 16:05:04 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Mar 2016 20:05:04 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458331504.67.0.877826787804.issue26576@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Guido, the discrepancy between the decorator doc's 'equivalent code' and actual, optimized, behavior with regard to skipping an intermediate binding of the function to the name came up soon after decorators were added.  I cannot find the issue, but as I remember, you said at the time that the doc's 'equivalent' code was good enough, and perhaps that you did not want to force the optimization on other implementations (not sure of this latter).

This issue has come up often enough on Python list and SO that many think that the actual behavior should be documented.  But should it be documented as a guaranteed language feature or as just an optional optimization?

----------
nosy: +gvanrossum, terry.reedy

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

From report at bugs.python.org  Fri Mar 18 16:24:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Mar 2016 20:24:25 +0000
Subject: [docs] [issue26095] Update porting HOWTO to special-case Python 2
 code, not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <20160318202420.53386.59889.053ECB65@psf.io>


Roundup Robot added the comment:

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

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

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

From report at bugs.python.org  Fri Mar 18 16:24:39 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 18 Mar 2016 20:24:39 +0000
Subject: [docs] [issue26095] Update porting HOWTO to special-case Python 2
 code, not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1458332679.64.0.488812213004.issue26095@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 18 22:37:56 2016
From: report at bugs.python.org (Aatish Neupane)
Date: Sat, 19 Mar 2016 02:37:56 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1458355076.03.0.484095861485.issue26553@psf.upfronthosting.co.za>


Aatish Neupane added the comment:

I already did that.

----------

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

From report at bugs.python.org  Sat Mar 19 03:09:18 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Mar 2016 07:09:18 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458371358.32.0.664739092652.issue26576@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Elsewhere we use "roughly equivalent to" instead of "broadly equivalent to".  The latter seems a little bit off the mark.

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

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

From report at bugs.python.org  Sat Mar 19 03:15:20 2016
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 19 Mar 2016 07:15:20 +0000
Subject: [docs] [issue26576] Tweak wording of decorator docos
In-Reply-To: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>
Message-ID: <1458371720.07.0.680068311749.issue26576@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Sure - changing it to "roughly". I started with that wording, and then changed to "broadly", for reasons which I now can't remember - so they can't have been too important. Consistency wins.

----------
Added file: http://bugs.python.org/file42214/deco-docos.patch

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

From report at bugs.python.org  Sat Mar 19 12:49:44 2016
From: report at bugs.python.org (Julien)
Date: Sat, 19 Mar 2016 16:49:44 +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: <1458406184.68.0.596355037996.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

You're right Terry, I posted on python ideas in case someone comes with a good idea, I also explained my vision in a lot of details to gather the widest feedback possible on each point that came to my mind:

https://mail.python.org/pipermail/python-ideas/2016-March/038879.html

----------

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

From report at bugs.python.org  Sun Mar 20 03:26:33 2016
From: report at bugs.python.org (Andrew Szeto)
Date: Sun, 20 Mar 2016 07:26:33 +0000
Subject: [docs] [issue26593] silly typo in logging cookbook
Message-ID: <1458458793.09.0.189282246745.issue26593@psf.upfronthosting.co.za>


New submission from Andrew Szeto:

In all versions of https://docs.python.org/3/howto/logging-cookbook.html, there is a very silly typo. It bothered me, and I wanted to get a taste of the patching workflow for contribution to Python, so I figured I'd write a patch.

----------
assignee: docs at python
components: Documentation
files: doc-logging-cookbook-capitalization.patch
keywords: patch
messages: 262060
nosy: Andrew Szeto, docs at python
priority: normal
severity: normal
status: open
title: silly typo in logging cookbook
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42219/doc-logging-cookbook-capitalization.patch

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

From report at bugs.python.org  Sun Mar 20 06:07:38 2016
From: report at bugs.python.org (Elena Oat)
Date: Sun, 20 Mar 2016 10:07:38 +0000
Subject: [docs] [issue26545] os.walk is limited by python's recursion limit
In-Reply-To: <1457744340.04.0.931517157669.issue26545@psf.upfronthosting.co.za>
Message-ID: <1458468458.25.0.169596565912.issue26545@psf.upfronthosting.co.za>


Elena Oat added the comment:

I've actually tried to test the recursion limit on my Mac OS X. It seems that I cannot create any subdirectories after around 500 subdir depth. I guess it's related to the allowed path length (<1024 chars?).

----------
nosy: +Elena.Oat

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

From report at bugs.python.org  Sun Mar 20 06:50:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Mar 2016 10:50:00 +0000
Subject: [docs] [issue26593] silly typo in logging cookbook
In-Reply-To: <1458458793.09.0.189282246745.issue26593@psf.upfronthosting.co.za>
Message-ID: <20160320104957.13992.65382.615BCF50@psf.io>


Roundup Robot added the comment:

New changeset 8d41ce2cde18 by Berker Peksag in branch '3.5':
Issue #26593: Fix typo in logging HOWTO
https://hg.python.org/cpython/rev/8d41ce2cde18

New changeset 8b85df50d906 by Berker Peksag in branch 'default':
Issue #26593: Fix typo in logging HOWTO
https://hg.python.org/cpython/rev/8b85df50d906

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

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

From report at bugs.python.org  Sun Mar 20 06:50:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 20 Mar 2016 10:50:50 +0000
Subject: [docs] [issue26593] silly typo in logging cookbook
In-Reply-To: <1458458793.09.0.189282246745.issue26593@psf.upfronthosting.co.za>
Message-ID: <1458471050.38.0.859981790928.issue26593@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Andrew.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 20 07:28:45 2016
From: report at bugs.python.org (Manvi B)
Date: Sun, 20 Mar 2016 11:28:45 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458473325.09.0.136595066983.issue26506@psf.upfronthosting.co.za>


Manvi B added the comment:

Modified documentation for the functions bin(), hex() and oct() as mentioned in the comments. Submitted the patch.

----------
keywords: +patch
nosy: +Manvi B
Added file: http://bugs.python.org/file42221/issue26506.diff

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

From report at bugs.python.org  Sun Mar 20 07:32:05 2016
From: report at bugs.python.org (Elena Oat)
Date: Sun, 20 Mar 2016 11:32:05 +0000
Subject: [docs] [issue19164] Update uuid.UUID TypeError exception: integer
 should not be an argument.
In-Reply-To: <1380885490.13.0.480584034262.issue19164@psf.upfronthosting.co.za>
Message-ID: <1458473525.23.0.570072950839.issue19164@psf.upfronthosting.co.za>


Elena Oat added the comment:

I tested the patch and it seems fine. Also ran tests for uuid.py and it they passed.

----------
nosy: +Elena.Oat

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

From report at bugs.python.org  Sun Mar 20 08:38:56 2016
From: report at bugs.python.org (Erwin Berkouwer)
Date: Sun, 20 Mar 2016 12:38:56 +0000
Subject: [docs] [issue26594] Tutorial example IndentationError?
Message-ID: <1458477536.83.0.48504738422.issue26594@psf.upfronthosting.co.za>


New submission from Erwin Berkouwer:

being totally new to Python, I tried actually doing the examples from the beginners guide (real RTFM ;-)

however I fail at the first example, with an error message that I don't understand. please clarify. attached file is screenprint from documentation, below what's on my screen (note I keyed in the example, no copy/paste, but I think correctly)

Also adding spaces or a tab doesn't get rid of the error.


C:\Users\erwin>python
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> the_world_is_flat = True
>>> if the_world_is_flat:
... print("be careful not to fall off!")
  File "<stdin>", line 2
    print("be careful not to fall off!")
        ^
IndentationError: expected an indented block

----------
assignee: docs at python
components: Documentation
files: IndentationError.jpg
messages: 262072
nosy: Erwin Berkouwer, docs at python
priority: normal
severity: normal
status: open
title: Tutorial example IndentationError?
versions: Python 3.5
Added file: http://bugs.python.org/file42223/IndentationError.jpg

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

From report at bugs.python.org  Sun Mar 20 09:28:32 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 20 Mar 2016 13:28:32 +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: <1458480512.89.0.50742483779.issue26546@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
nosy: +ebarry
stage:  -> patch review

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

From report at bugs.python.org  Sun Mar 20 09:46:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Mar 2016 13:46:10 +0000
Subject: [docs] [issue26594] Tutorial example IndentationError?
In-Reply-To: <1458477536.83.0.48504738422.issue26594@psf.upfronthosting.co.za>
Message-ID: <1458481570.56.0.452768562452.issue26594@psf.upfronthosting.co.za>


SilentGhost added the comment:

Erwin, you could clearly see in the screenshot that the print call is indented, i.e. it starts in the 5th column, under letter "h" of the_world_is_flat. In what you've typed here one can clearly see that "p" of print is under "i" of if (the 1st column) and is therefore not indented. Indentation is an important part of Python syntax.

To properly copy this example from documentation into interpreter you could click on button in the top right corner of the code block - it's cut off in your screenshot, but it looks like a python prompt (>>>).

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

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

From report at bugs.python.org  Sun Mar 20 10:46:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 20 Mar 2016 14:46:35 +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: <1458485195.89.0.236902693026.issue26267@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 20 10:48:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Mar 2016 14:48:15 +0000
Subject: [docs] [issue19164] Update uuid.UUID TypeError exception: integer
 should not be an argument.
In-Reply-To: <1380885490.13.0.480584034262.issue19164@psf.upfronthosting.co.za>
Message-ID: <20160320144809.98667.91158.2ED74896@psf.io>


Roundup Robot added the comment:

New changeset f736aea929c2 by Berker Peksag in branch '3.5':
Issue #19164: Improve exception message of uuid.UUID()
https://hg.python.org/cpython/rev/f736aea929c2

New changeset e59b799df6e2 by Berker Peksag in branch 'default':
Issue #19164: Improve exception message of uuid.UUID()
https://hg.python.org/cpython/rev/e59b799df6e2

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

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

From report at bugs.python.org  Sun Mar 20 10:48:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 20 Mar 2016 14:48:58 +0000
Subject: [docs] [issue19164] Update uuid.UUID TypeError exception: integer
 should not be an argument.
In-Reply-To: <1380885490.13.0.480584034262.issue19164@psf.upfronthosting.co.za>
Message-ID: <1458485338.89.0.734906241088.issue19164@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Mar 20 11:01:58 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Mar 2016 15:01:58 +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: <1458486118.16.0.856421387411.issue26267@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 20 13:14:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Mar 2016 17:14:57 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1458473325.09.0.136595066983.issue26506@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwasCJbxyVKi6vHezqXz=1UE-S32EM+6Kkn=Tz1-E_h+vw@mail.gmail.com>


STINNER Victor added the comment:

You misunderstood the whole purpose of my issue! You must not write
hex()[:2] (it's inefficent)! Please remove it from your patch.

----------

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

From report at bugs.python.org  Sun Mar 20 13:23:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Mar 2016 17:23:44 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458494624.56.0.389092859118.issue26506@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The documentation for hex() doesn't look the bests place for examples of using string formatting. I think it is enough to add short references to corresponding formatting codes.

----------

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

From report at bugs.python.org  Sun Mar 20 20:44:32 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Mar 2016 00:44:32 +0000
Subject: [docs] [issue26597] Document how to cite Python
Message-ID: <1458521072.31.0.998709728719.issue26597@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

Add either a FAQ or a new page under "Meta Information" in the documentation for how to formally cite Python in scientific papers or other academic situations.

See thread on Python-Ideas here for justification and further discussion:

https://mail.python.org/pipermail/python-ideas/2016-March/038816.html

----------
assignee: docs at python
components: Documentation
messages: 262096
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Document how to cite Python
type: enhancement

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

From report at bugs.python.org  Sun Mar 20 21:03:04 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Mar 2016 01:03:04 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>
Message-ID: <1458522184.16.0.19563176827.issue15660@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You example says to left justify '1'
>>> format(1, '<2')
'1 '
and then pad with '0' instead of ' '.

----------

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

From report at bugs.python.org  Sun Mar 20 21:06:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Mar 2016 01:06:33 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>
Message-ID: <20160321010630.84260.68763.01F3FE64@psf.io>


Roundup Robot added the comment:

New changeset de669512df97 by Terry Jan Reedy in branch '2.7':
Issue #15660: Further clarify 0 prefix for width specifier in formats.
https://hg.python.org/cpython/rev/de669512df97

New changeset 34cbc5d8a173 by Terry Jan Reedy in branch '3.5':
Issue #15660: Further clarify 0 prefix for width specifier in formats.
https://hg.python.org/cpython/rev/34cbc5d8a173

----------

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

From report at bugs.python.org  Sun Mar 20 21:06:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Mar 2016 01:06:59 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>
Message-ID: <1458522419.11.0.334591084113.issue15660@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 20 21:07:57 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Mar 2016 01:07:57 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1458522477.81.0.25265493703.issue26525@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> terry.reedy

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

From report at bugs.python.org  Sun Mar 20 21:19:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Mar 2016 01:19:17 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <20160321011908.30591.81783.40ADA7C9@psf.io>


Roundup Robot added the comment:

New changeset c7071c9b8c33 by Terry Jan Reedy in branch '3.5':
Issue #26525: Change ord example from nu to more easily recognized Euro sign.
https://hg.python.org/cpython/rev/c7071c9b8c33

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

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

From report at bugs.python.org  Sun Mar 20 21:19:41 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Mar 2016 01:19:41 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1458523181.67.0.435725320268.issue26525@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 20 22:47:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Mar 2016 02:47:58 +0000
Subject: [docs] [issue26597] Document how to cite Python
In-Reply-To: <1458521072.31.0.998709728719.issue26597@psf.upfronthosting.co.za>
Message-ID: <1458528477.98.0.896382458836.issue26597@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Either a new page under 'Meta' or combined with 'Copyright'.

For future reference, sys has multiple information constants and functions.  Indeed, 'copyright' is an alias for sys.copyright, added by the site module.  Sys would, I think, be the best place to put a citation() function, should you propose one.  It would then be indexed, but not intrusive on startup.

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Mar 21 04:33:31 2016
From: report at bugs.python.org (Manvi B)
Date: Mon, 21 Mar 2016 08:33:31 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458549211.83.0.947169567432.issue26506@psf.upfronthosting.co.za>


Manvi B added the comment:

Removed hex()[:2] from the patch.

----------
Added file: http://bugs.python.org/file42227/issue26506.diff

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

From report at bugs.python.org  Mon Mar 21 04:42:38 2016
From: report at bugs.python.org (Manvi B)
Date: Mon, 21 Mar 2016 08:42:38 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458549758.39.0.693673856036.issue26506@psf.upfronthosting.co.za>


Manvi B added the comment:

Modified the patch with '%x' % value.

----------
Added file: http://bugs.python.org/file42228/issue26506.diff

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

From report at bugs.python.org  Mon Mar 21 05:00:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2016 09:00:55 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458550855.3.0.364320158397.issue26506@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy Storchaka:
> The documentation for hex() doesn't look the bests place for examples of using string formatting. I think it is enough to add short references to corresponding formatting codes.

I like Manvi B's patch with many examples. It's hard to read formatting strings, it's hard to compute the result, so full examples are just more obvious.

I don't think that it hurts to add many formatting examples. I expect that most users will combine the result of bin/hex/oct with another string, so suggesting using formatting functions will probably help them to simplify the code.

For example,
   print("x=", hex(x), "y=", hex(y))
can be written:
   print("x=%#x y=%#x" % (x, y))
or
   print("x={:#x} y={:#x}".format(x, y))
or
   print(f"x={x:#x} y={y:#x}")

The first expression using hex() adds spaces after "=", but well, it's just to give a simple example. IMHO formatting strings are more readable.

----------

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

From report at bugs.python.org  Mon Mar 21 05:02:17 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Mar 2016 09:02:17 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458550937.63.0.494399019322.issue26506@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The documentation for hex() doesn't look the bests place for examples
> of using string formatting. I think it is enough to add short
> references to corresponding formatting codes.

I think those examples take too much space compared to the actual docs of the functions.

I can think of 3 possible solutions:

1) keep the examples but condense them so that they don't take so much space:
>>> n = 255
>>> f'{n:#x}', format(n, '#x'), '%#x' % n
('0xff', '0xff', '0xff')
>>> f'{n:x}', format(n, 'x'), '%x' % n
('ff', 'ff', 'ff')
>>> f'{n:X}', format(n, 'X'), '%X' % n
('FF', 'FF', 'FF')

or

>>> '%#x' % 255, '%x' % 255, '%X' % 255
('0xff', 'ff', 'FF')
>>> format(255, '#x'), format(255, 'x'), format(255, 'X')
('0xff', 'ff', 'FF')
>>> f'{255:#x}', f'{255:x}', f'{255:X}'
('0xff', 'ff', 'FF')

(the latter should only go in 3.6 though)

2) add a direct link to https://docs.python.org/3/library/string.html#format-examples where there are already some examples (more can be added if needed);

3) add a single footnote for all 3 functions that includes examples using old/new string formatting and f-strings, mentions the fact that # can be used to omit the prefix and the fact that b/o/x and B/O/X can be used for lowercase and uppercase output.

FWIW I don't think that performances matter too much in this case, but I also dislike hex(value)[2:] and agree it should not be mentioned.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Mar 21 05:23:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2016 09:23:57 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458552237.36.0.764739770991.issue26506@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ezio Melotti added the comment:
> I can think of 3 possible solutions:
>
> 1) keep the examples but condense them so that they don't take so much space:
>>>> n = 255
>>>> f'{n:#x}', format(n, '#x'), '%#x' % n
> ('0xff', '0xff', '0xff')
>>>> f'{n:x}', format(n, 'x'), '%x' % n
> ('ff', 'ff', 'ff')
>>>> f'{n:X}', format(n, 'X'), '%X' % n
> ('FF', 'FF', 'FF')

Hum. It's not easy to read these complex formatting strings when they are written like that.

> or
>
>>>> '%#x' % 255, '%x' % 255, '%X' % 255
> ('0xff', 'ff', 'FF')
>>>> format(255, '#x'), format(255, 'x'), format(255, 'X')
> ('0xff', 'ff', 'FF')
>>>> f'{255:#x}', f'{255:x}', f'{255:X}'
> ('0xff', 'ff', 'FF')

I really prefer when the same kind of the formating strings are written on the same line. I really like this example. Short, obvious, easy to read.

I have a prefererence for an example using a variable name rather than a number literal. It's more common to manipulate variables than number literals.

If you use a variable, please use a variable name longer than "n" to get more readable example. Otherwise, it's not obvious what is in the variable name in "{n:x}": is "n" the variable? is "x" the variable?


In short, I suggest this example:

>>> value = 255
>>> '%#x' % value, '%x' % value, '%X' % value
('0xff', 'ff', 'FF')
>>> format(value, '#x'), format(value, 'x'), format(value, 'X')
('0xff', 'ff', 'FF')
>>> f'{value:#x}', f'{value:x}', f'{value:X}'
('0xff', 'ff', 'FF')


Note: Ezio, do you prefer format(value, 'x) for '{:x}'.format(value)?


> 2) add a direct link to https://docs.python.org/3/library/string.html#format-examples where there are already some examples (more can be added if needed);

IMHO it's ok to add formatting examples to bin/hex/oct. Using your compact example, it's not going to make the doc too long.

----------

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

From report at bugs.python.org  Mon Mar 21 07:11:35 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Mar 2016 11:11:35 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458558695.04.0.919398840856.issue26506@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Note: Ezio, do you prefer format(value, 'x') for '{:x}'.format(value)?

While formatting a single value the former is better/shorter, but the latter is perhaps more common since you usually have something else in the string too.

The latter can also be used to do something like:
>>> '{num:x} {num:X} {num:#x} {num:#X}'.format(num=255)
'ff FF 0xff 0XFF'

----------

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

From victor.stinner at gmail.com  Mon Mar 21 04:55:33 2016
From: victor.stinner at gmail.com (victor.stinner at gmail.com)
Date: Mon, 21 Mar 2016 08:55:33 -0000
Subject: [docs] hex() documentation: mention "%x" % int (issue 26506)
Message-ID: <20160321085533.30212.78264@psf.upfronthosting.co.za>

Reviewers: ,


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

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode87
Doc/library/functions.rst:87: '0b11'
I suggest to use less boring numbers in examples, like 12: 0b1100, it
shows the order of bits (which is not documented): most significant bits
first.

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode94
Doc/library/functions.rst:94: '0b11'
I don't know if this example is needed.

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode98
Doc/library/functions.rst:98: >>> "{0:b}".format(3)
I suggest to omit 0:

"{:b}".format(3)

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode104
Doc/library/functions.rst:104: :meth:`__index__` method that returns an
integer.
I suggest to add examples at the end, after this sentence.

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode674
Doc/library/functions.rst:674: 'ff'
Documenting format() and str.format() seems overkill. I suggest to only
keep one. Since str.format() is more common, I suggest to only keep:
"{:x}".format(255) (without the 0 in the formatting string).

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode675
Doc/library/functions.rst:675: >>> f'{255:x}'
IMHO this one is not a good usage of f-strings, I suggest to remove it.

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode918
Doc/library/functions.rst:918: '0o10'
"%#o" % 8 also exists. You may mention it.

http://bugs.python.org/review/26506/diff/16795/Doc/library/functions.rst#newcode925
Doc/library/functions.rst:925: '10'
To be consistent with bin & hex, I also suggest to only document
str.format here:

>>> "{:o}".format(8)
'10'



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

Affected files:
  Doc/library/functions.rst


diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst
index ef4176a..7cde44d 100644
--- a/Doc/library/functions.rst
+++ b/Doc/library/functions.rst
@@ -80,8 +80,27 @@ are always available.  They are listed here in alphabetical order.
 
 .. function:: bin(x)
 
-   Convert an integer number to a binary string. The result is a valid Python
-   expression.  If *x* is not a Python :class:`int` object, it has to define an
+   Convert an integer number to a binary string prefixed with "0b". 
+   The result is a valid Python expression, for example:
+
+      >>> bin(3)
+      '0b11'
+      >>> bin(-10)
+      '-0b1010'
+
+   It can also be done by using the expression:
+
+      >>> "{0:#b}".format(3)
+      '0b11'
+
+   If prefix "0b" is not desired, you can use either of the following ways:
+
+      >>> "{0:b}".format(3)
+      '11'
+      >>> format(3, 'b')
+      '11'
+
+   If *x* is not a Python :class:`int` object, it has to define an
    :meth:`__index__` method that returns an integer.
 
 
@@ -634,6 +653,28 @@ are always available.  They are listed here in alphabetical order.
       >>> hex(-42)
       '-0x2a'
 
+   It can also be done by using the expression:
+
+      >>> "%#x" % 255
+      '0xff'
+
+   If you want to convert an integer number to an uppercase hexadecimal string
+   prefixed with "0X":
+
+      >>> "%#X" % 255
+      '0XFF'
+
+   If prefix "0x" is not desired, you can use either of the following ways:
+
+      >>> '%x' % 255
+      'ff'
+      >>> format(255, 'x')
+      'ff'
+      >>> "{0:x}".format(255)
+      'ff'
+      >>> f'{255:x}'
+      'ff'
+
    If x is not a Python :class:`int` object, it has to define an __index__()
    method that returns an integer.
 
@@ -865,8 +906,25 @@ are always available.  They are listed here in alphabetical order.
 
 .. function:: oct(x)
 
-   Convert an integer number to an octal string.  The result is a valid Python
-   expression.  If *x* is not a Python :class:`int` object, it has to define an
+   Convert an integer number to an octal string prefixed with "0o".  The result 
+   is a valid Python expression, for example:
+
+      >>> oct(8)
+      '0o10'
+
+   It can also be done by using the expression:
+
+      >>> "{0:#o}".format(8)
+      '0o10'
+
+   If prefix "0o" is not desired, you can use either of the following ways:
+
+      >>> "%o" % 8
+      '10'
+      >>> format(8, 'o')
+      '10'
+
+   If *x* is not a Python :class:`int` object, it has to define an
    :meth:`__index__` method that returns an integer.
 
 



From report at bugs.python.org  Mon Mar 21 08:11:34 2016
From: report at bugs.python.org (Daniel Stone)
Date: Mon, 21 Mar 2016 12:11:34 +0000
Subject: [docs] [issue26602] argparse doc introduction is inappropriately
 targeted
Message-ID: <1458562294.77.0.347454712136.issue26602@psf.upfronthosting.co.za>


New submission from Daniel Stone:

The argparse documentation starts off, after a couple of sentences, by spending several paragraphs (and a couple of sentences) explaining this gem:
import argparse

parser = argparse.ArgumentParser(description='Process some integers.')
parser.add_argument('integers', metavar='N', type=int, nargs='+',
                   help='an integer for the accumulator')
parser.add_argument('--sum', dest='accumulate', action='store_const',
                   const=sum, default=max,
                   help='sum the integers (default: find the max)')

args = parser.parse_args()
print(args.accumulate(args.integers))


While it is undoubtedly impressive, that a sidebar had to be inserted suggesting people in fact refer to other documentation, suggests it may be inappropriate. As an introduction, it is not particularly approachable (especially if you don't catch the nuance of assigning functions to accumulate), and is probably not going to serve the immediate needs of a lot of the audience: the people who click on the first hit for 'python argparse'.

I would suggest relegating this example elsewhere in the documentation, with a much more straightforward/realistic example to lead the documentation.

----------
assignee: docs at python
components: Documentation
messages: 262121
nosy: Daniel Stone, docs at python
priority: normal
severity: normal
status: open
title: argparse doc introduction is inappropriately targeted

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

From report at bugs.python.org  Mon Mar 21 10:07:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 21 Mar 2016 14:07:15 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1458569235.43.0.600527588861.issue24459@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

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

From report at bugs.python.org  Mon Mar 21 12:51:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 21 Mar 2016 16:51:52 +0000
Subject: [docs] [issue26582] asyncio documentation links to wrong
 CancelledError
In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>
Message-ID: <1458579112.01.0.208963224446.issue26582@psf.upfronthosting.co.za>


SilentGhost added the comment:

In fact most of the :exc: reference are pointing explicitly to concurrent.futures.CancelledError (and those that don't probably should). It is interesting that you weren't able to make use of that exception, because in Lib/asyncio/futures.py#L23 it's clearly defined as an alias of the concurrent.futures.CancelledError.

I guess, ultimately, asyncio.CancelleError needs to be documented seeing how widely used it is.

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

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

From report at bugs.python.org  Tue Mar 22 02:56:38 2016
From: report at bugs.python.org (Mateusz)
Date: Tue, 22 Mar 2016 06:56:38 +0000
Subject: [docs] [issue26608] RLock undocumented behavior in case of multiple
 acquire
Message-ID: <1458629798.26.0.210968234517.issue26608@psf.upfronthosting.co.za>


New submission from Mateusz:

The number of acquisitions must be the same as the number of releases or else lock will not be released for other threads leading to deadlock. This is not mentioned in documentation. 

First acquisition returns boolean and further acquisitions return 1. This is also not mentioned in documentation.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 262165
nosy: docs at python, smbrd
priority: normal
severity: normal
status: open
title: RLock undocumented behavior in case of multiple acquire
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 22 03:46:42 2016
From: report at bugs.python.org (Manvi B)
Date: Tue, 22 Mar 2016 07:46:42 +0000
Subject: [docs] [issue26506] hex() documentation: mention "%x" % int
In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>
Message-ID: <1458632802.79.0.158488006589.issue26506@psf.upfronthosting.co.za>


Manvi B added the comment:

Considered the reviews from STINNER Victor (haypo) and comments, the patch is modified.

----------
Added file: http://bugs.python.org/file42242/issue26506.diff

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

From nalan3015 at 126.com  Tue Mar 22 03:27:17 2016
From: nalan3015 at 126.com (=?GBK?B?wqzOxMiq?=)
Date: Tue, 22 Mar 2016 15:27:17 +0800 (CST)
Subject: [docs] report a bug about docs 2
Message-ID: <e5d2a67.b5c7.1539d3878ba.Coremail.nalan3015@126.com>

It is about random doc:
the docs say:

random.uniform(a, b)
Return a random floating point number N such that a <= N <= b for a <= b and b <= N <= a for b < a.


but your examples are:

>>> random.random()        # Random float x, 0.0 <= x < 1.0
0.37444887175646646
>>> random.uniform(1, 10)  # Random float x, 1.0 <= x < 10.0
1.1800146073117523





--

----
Thanks & Best Regards!
??? Adolph Lu
Mobile?+86 15651006559
DockOne volunteer | translator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160322/ee22f64b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-bug.png
Type: image/png
Size: 25678 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20160322/ee22f64b/attachment-0001.png>

From report at bugs.python.org  Tue Mar 22 10:50:16 2016
From: report at bugs.python.org (py.user)
Date: Tue, 22 Mar 2016 14:50:16 +0000
Subject: [docs] [issue15660] Clarify 0 prefix for width specifier in
 str.format doc, 
In-Reply-To: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>
Message-ID: <1458658216.46.0.659727296093.issue15660@psf.upfronthosting.co.za>


py.user added the comment:

Terry J. Reedy (terry.reedy) wrote:
> You example says to left justify '1'

Nope.

The fill character goes before alignment in the specification (grammatics).

>>> format(1, '0<2')
'10'
>>>

This is right. But 02 - is zero padding of a number which can be done only from the left side.

'<02' means "justify to the left zero padded number"

----------

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

From report at bugs.python.org  Tue Mar 22 13:17:36 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 22 Mar 2016 17:17:36 +0000
Subject: [docs] [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1458667056.82.0.563599750334.issue10894@psf.upfronthosting.co.za>


SilentGhost added the comment:

I wonder if the devguide would be a more suitable place for these guidelines. Here is the patch that adds them to stdblibchanges.rst

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42244/issue10894.diff

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

From report at bugs.python.org  Tue Mar 22 20:56:24 2016
From: report at bugs.python.org (Stubz)
Date: Wed, 23 Mar 2016 00:56:24 +0000
Subject: [docs] [issue26613] Descriptor HowTo Guide - Typo
Message-ID: <1458694584.31.0.177347934352.issue26613@psf.upfronthosting.co.za>


New submission from Stubz:

The last line has a typo ... Dict.fromkeys -> dict.fromkeys

I am a newbie, but that was just a pain in the ass ...

Worked my way thru this How to and spent an hour+ trying to sort a circular argument error...

Was this intentional ?
In as much as it was a pain in the ass, I think I got the concept sorted ...


https://docs.python.org/3.5/howto/descriptor.html

Static Methods and Class Methods

This behavior is useful whenever the function only needs to have a class reference and does not care about any underlying data. One use for classmethods is to create alternate class constructors. In Python 2.3, the classmethod dict.fromkeys() creates a new dictionary from a list of keys. The pure Python equivalent is:

class Dict(object):
    . . .
    def fromkeys(klass, iterable, value=None):
        "Emulate dict_fromkeys() in Objects/dictobject.c"
        d = klass()
        for key in iterable:
            d[key] = value
        return d
    fromkeys = classmethod(fromkeys)

Now a new dictionary of unique keys can be constructed like this:

>>>
Dict.fromkeys('abracadabra')

----------
assignee: docs at python
components: Documentation
messages: 262223
nosy: docs at python, stubzpub
priority: normal
severity: normal
status: open
title: Descriptor HowTo Guide - Typo
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 22 21:06:05 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Mar 2016 01:06:05 +0000
Subject: [docs] [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1458695165.2.0.906665095317.issue10894@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Much of this is already in PEP 8 and doesn't need repeating.  Also, the tone is somewhat judgmental, heavy handed, restrictive, and over-broad for my tastes.

The last part seems to imply that we're going to change existing code in a way that may break user code.  Our whole goal is to make migrating to Python 3 easier.  The next to last part may create a pressure to document and promise some things that may be implementation specific details.

I think we should let PEP 8 serve as the primary guideline.  For new code, try to be as clear as possible on public versus private.  For existing code, any changes should be considered on a case by case basis to strike the best balance between useful documentation versus over-specification versus breaking existing code by privatizing that which was unintentionally made public.  

Also, when it comes to documentation, there are many things which are public (such as pickling support, every magic method available, etc) which aren't discussed for every single class.  The reason for this is that it tends to fill the documentation with clutter, making it hard for the more useful information to stand out.

----------

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

From report at bugs.python.org  Tue Mar 22 21:20:25 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Mar 2016 01:20:25 +0000
Subject: [docs] [issue26613] Descriptor HowTo Guide - Typo
In-Reply-To: <1458694584.31.0.177347934352.issue26613@psf.upfronthosting.co.za>
Message-ID: <1458696025.07.0.952034522661.issue26613@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The last line is not a typo, it shows how to call the pure python version of the classmethod described above it.

FWIW, I'm working a revision to this how-to guide that it easier to read.  At the time it was written, it was the *only* documentation for the descriptors in that language and much of it was a direct translation from the underlying C code as an authoritative reference to that code.  It was not really a newbie document (descriptors aren't a newbie topic) and was moved to the how-to guides because it was so popular.

Since you're already "sorted", I'll close this tracker item.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Mar 22 22:49:36 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 23 Mar 2016 02:49:36 +0000
Subject: [docs] [issue26608] RLock undocumented behavior in case of multiple
 acquire
In-Reply-To: <1458629798.26.0.210968234517.issue26608@psf.upfronthosting.co.za>
Message-ID: <1458701376.11.0.696104187632.issue26608@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Per the docs ( https://docs.python.org/3/library/threading.html#rlock-objects ):

"To unlock the lock, a thread calls its release() method. acquire()/release() call pairs may be nested; only the final release() (the release() of the outermost pair) resets the lock to unlocked and allows another thread blocked in acquire() to proceed."

The docs aren't super clear on the return type, but they aren't so overly specified as to make returning either True or 1 incorrect; they use lowercase "true" to describe the return value, which doesn't *have* to mean True, just something that evaluates as truthy.

In 3.5 at least, it looks like both initial and subsequent acquires are all returning True, even when called without passing an argument; this actually violates the docs, which claim that not passing an argument means "There is no return value" (possibly only when there is contended acquisition, the wording is odd), when in fact a no-argument call returns True just like explicitly passing blocking as True.

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

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

From report at bugs.python.org  Tue Mar 22 23:35:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 23 Mar 2016 03:35:42 +0000
Subject: [docs] [issue26615] Missing entry in WRAPPER_ASSIGNMENTS in
 update_wrapper's doc
Message-ID: <1458704141.94.0.68234227835.issue26615@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

WRAPPER_ASSIGNMENTS now contains __qualname__ but the documentation doesn't mention it.

----------
assignee: docs at python
components: Documentation
files: functools_doc.patch
keywords: patch
messages: 262237
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Missing entry in WRAPPER_ASSIGNMENTS in update_wrapper's doc
versions: Python 3.6
Added file: http://bugs.python.org/file42247/functools_doc.patch

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

From report at bugs.python.org  Wed Mar 23 00:18:27 2016
From: report at bugs.python.org (Brian Guo)
Date: Wed, 23 Mar 2016 04:18:27 +0000
Subject: [docs] [issue26602] argparse doc introduction is inappropriately
 targeted
In-Reply-To: <1458562294.77.0.347454712136.issue26602@psf.upfronthosting.co.za>
Message-ID: <1458706707.6.0.30281257858.issue26602@psf.upfronthosting.co.za>


Brian Guo added the comment:

Hi,

I agree with your observation about the unnecessarily complicated documentation. I feel that there is not a real necessity to include an example that uses (metavar='N', nargs='+') or even (const='sum', default='max') inside the parameters of the add_argument method, as they are not explained in the beginning section and simply appear to contribute clutter.

For this reason, I have written an easier document to understand (still keeping the sidebar tutorial, because it is a helpful reference). I use instead a method that accepts a string and returns the first letter. I hope this will add to the clarity of the document.

----------
keywords: +patch
nosy: +BGuo1
Added file: http://bugs.python.org/file42248/bguo.patch

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

From report at bugs.python.org  Wed Mar 23 03:48:54 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Mar 2016 07:48:54 +0000
Subject: [docs] [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1458719334.98.0.12680940371.issue10894@psf.upfronthosting.co.za>


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


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

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

From ANGELIA.SPENCER at adtran.com  Tue Mar 22 15:24:37 2016
From: ANGELIA.SPENCER at adtran.com (ANGELIA SPENCER)
Date: Tue, 22 Mar 2016 19:24:37 +0000
Subject: [docs] Bug Documentation
Message-ID: <4672A5A27643AF47BBB4F9841B750C1DE79EE0CB@ex-mb1.corp.adtran.com>


20.14.2 telnet Example:
A simple example illustrating typical use:
import getpass
import sys
import telnetlib

HOST = "localhost"
user = raw_input("Enter your remote account: ")
password = getpass.getpass()

tn = telnetlib.Telnet(HOST)

tn.read_until("login: ")
tn.write(user + "\n")
if password:
    tn.read_until("Password: ")
    tn.write(password + "\n")

tn.write("ls\n")
tn.write("exit\n")

print tn.read_all()



>>> password = getpass.getpass()

Warning (from warnings module):
  File "C:\Python27\lib\getpass.py", line 92
    return fallback_getpass(prompt, stream)
GetPassWarning: Can not control echo on the terminal.
Warning: Password input may be echoed.
Password: PASSWORD

ANGELIA SPENCER
DVT Engineer
256-963-6931

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160322/e6de0e5e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2950 bytes
Desc: image001.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20160322/e6de0e5e/attachment-0001.jpg>

From tabishiqubal70 at gmail.com  Tue Mar 22 08:37:12 2016
From: tabishiqubal70 at gmail.com (Tabish Iqbal)
Date: Tue, 22 Mar 2016 18:07:12 +0530
Subject: [docs] Translation
Message-ID: <CAKO9J7ZHeFKfWayNkh1Lq3Cud8iFO6MBjkBsQy4mskPNAxczKQ@mail.gmail.com>

Hello,
My name is Tashif. I want to translate the python documentation in Hindi
and give it away on my blog do you permit it? If yes, Tell me the whole
condition.

Thanks.....
And please reply soon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160322/4881843d/attachment.html>

From report at bugs.python.org  Wed Mar 23 09:17:19 2016
From: report at bugs.python.org (Stubz)
Date: Wed, 23 Mar 2016 13:17:19 +0000
Subject: [docs] [issue26613] Descriptor HowTo Guide - Typo
In-Reply-To: <1458694584.31.0.177347934352.issue26613@psf.upfronthosting.co.za>
Message-ID: <1458739039.06.0.145546723679.issue26613@psf.upfronthosting.co.za>


Stubz added the comment:

Thanx mate, I am sorted ...

Q tho ...

It turns out my issue was with the class Dict and what I called a typo in the call to dict.fromkeys ...

In order to make it 'go', I had to use the lower case letter, how is that not a typo ?

The part that hung me up was the naming of class Dict and the call to dict.fromkeys, with no variable assigned to it ... 

It makes better sense now, but ... a class Dict used as a example of dictobject, to demonstrate the descriptors use of the dictobject methods, from a call to Dictobject, that returns error object not iterable ...

I don't care what Lvl you are, that's just confusing ...

----------

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

From report at bugs.python.org  Wed Mar 23 10:51:40 2016
From: report at bugs.python.org (Shahar Golan)
Date: Wed, 23 Mar 2016 14:51:40 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1458744699.71.0.734446963758.issue9694@psf.upfronthosting.co.za>


Shahar Golan added the comment:

This is not just a section issue. Please note that using the ArgumentDefaultHelpFormatter:

  argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultHelpFormatter)

The help will also show (default=None) for these required arguments.

----------
components:  -Documentation
nosy: +shaharg
versions:  -Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 23 10:57:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Mar 2016 14:57:47 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1458745067.0.0.0236938082111.issue26525@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Reversed to ord() function chr() still uses '?' as an example. I think both functions should use the same example.

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

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

From report at bugs.python.org  Wed Mar 23 13:40:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 23 Mar 2016 17:40:53 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <20160323174043.40395.78831.C2A99D5C@psf.io>


Roundup Robot added the comment:

New changeset f3bd94c57cd8 by Terry Jan Reedy in branch '3.5':
Issue #26525: Change chr example to match change in ord example.
https://hg.python.org/cpython/rev/f3bd94c57cd8

----------

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

From report at bugs.python.org  Wed Mar 23 13:42:15 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 23 Mar 2016 17:42:15 +0000
Subject: [docs] [issue26525] Documentation of ord(c) easy to misread
In-Reply-To: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>
Message-ID: <1458754935.93.0.962460365294.issue26525@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Agreed.  Good catch.

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

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

From report at bugs.python.org  Wed Mar 23 15:21:11 2016
From: report at bugs.python.org (paul j3)
Date: Wed, 23 Mar 2016 19:21:11 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1458760870.93.0.510524470784.issue9694@psf.upfronthosting.co.za>


paul j3 added the comment:

This ArgumentDefaultHelpFormatter issue should probably be raised in its own issue.  It applies to 'required' optionals, but any patch would be independent of the issues discussed here.

This class defines a method that adds the '%(default)' string to the help in certain situations.  It already skips required positionals.  So adding a test for 'action.required' should be easy.

    def _get_help_string(self, action):
        help = action.help
        if '%(default)' not in action.help:
            if action.default is not SUPPRESS:
                defaulting_nargs = [OPTIONAL, ZERO_OR_MORE]
                if action.option_strings or action.nargs in defaulting_nargs:
                    help += ' (default: %(default)s)'
        return help

There are 2 easy user fixes.

- a custom HelpFormatter class that implements this fix.  

- 'default=argparse.SUPPRESS' for arguments where you do not want to see the default.  This SUPPRESS is checked else where in the code, but for a required argument I don't think that matters (but it needs testing).

----------

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

From report at bugs.python.org  Wed Mar 23 16:54:27 2016
From: report at bugs.python.org (Buraddin Ibn-Karlo)
Date: Wed, 23 Mar 2016 20:54:27 +0000
Subject: [docs] [issue26629] Need an ability to build standard DLLs with
 distutils
Message-ID: <1458766467.89.0.930968148514.issue26629@psf.upfronthosting.co.za>


New submission from Buraddin Ibn-Karlo:

I want to make a a dynamic library to run its function with ctypes.

Also I want to build the library from sources with distutils (the C++ sources are distributed with my Python code).

But alas! Our distutils fails, if the library doesn't have initialization function (something like init_<module_name>). Even if the module does not need any initialization.

I did a quick and dirty solution: added a dummy function:
    void init_<module_name>(){}

It somehow works, but I don't think that it is a good idea.

Cannot you add the possibility to tell distutils, that this extention module is just a simple DLL, that will be used via ctypes (or somehow else) and it does not need any extra init script?

Also, cannot you add an extra section to ctypes documentation? With a description how to build such extensions via distutils?

----------
assignee: docs at python
components: Build, Documentation, Extension Modules, Windows, ctypes
messages: 262308
nosy: Buraddin Ibn-Karlo, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Need an ability to build standard DLLs with distutils
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 23 17:31:41 2016
From: report at bugs.python.org (paul j3)
Date: Wed, 23 Mar 2016 21:31:41 +0000
Subject: [docs] [issue26602] argparse doc introduction is inappropriately
 targeted
In-Reply-To: <1458562294.77.0.347454712136.issue26602@psf.upfronthosting.co.za>
Message-ID: <1458768701.65.0.131695568245.issue26602@psf.upfronthosting.co.za>


paul j3 added the comment:

By text and location the sidebar does not apply specifically to this example.  It applies to the whole page, 'This page contains the API reference information.'

Documentation for argparse is indeed a problem - both because of its complexity and how it is used.  Many other reference modules focus on the classes and their methods.  This is organized about one class, the parser object, and a couple of its methods.  It's really more of an advanced user's tutorial, making most sense to users who already have use optparse and getopt.  For them that initial example is appropriate, selling them on the power of this parser.

For beginners I'd focus on the tutorial and its examples.  Example or not this reference section can be overwhelming to beginning Python users.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Wed Mar 23 19:06:50 2016
From: report at bugs.python.org (Jared Deckard)
Date: Wed, 23 Mar 2016 23:06:50 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
 the actions of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1458774410.78.0.628119248329.issue22401@psf.upfronthosting.co.za>


Jared Deckard added the comment:

This behavior is preventing me from using more than one parent parser.

My use case is a convenience subcommand that performs two existing subcommands, therefore logically its subparser is required to support the arguments of both subparsers.

The only conflict is the "help" argument, which is annoying, but setting the conflict handler to "resolve" on the child subparser should just ignore the first parent's "help" argument in favor of the second parent.

Instead the "resolve" conflict handler breaks the first parent and causes it to output the help info no matter what arguments are given to it.

I am forced to only include one parent and manually duplicate the arguments for any additional parents.

----------
components:  -Documentation, Tests
nosy: +deckar01
versions: +Python 2.7 -Python 3.5

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

From report at bugs.python.org  Wed Mar 23 20:31:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 24 Mar 2016 00:31:41 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1458779501.69.0.959696176989.issue9694@psf.upfronthosting.co.za>


Martin Panter added the comment:

Still applicable to Python 3 AFAIK

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

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

From report at bugs.python.org  Wed Mar 23 21:57:09 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 24 Mar 2016 01:57:09 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
 the actions of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1458784628.89.0.137151208464.issue22401@psf.upfronthosting.co.za>


paul j3 added the comment:

Is this the kind of scenario that you have problems with?

    parser = argparse.ArgumentParser()
    sp = parser.add_subparsers(dest='cmd')
    p1 = sp.add_parser('cmd1')
    p1.add_argument('-f')

    p2 = sp.add_parser('cmd2')
    p2.add_argument('-b')

    p3 = sp.add_parser('cmd3', parents=[p1,p2],add_help=False, conflict_handler='resolve')
    p3.add_argument('-c')

The problem is, apparently, that 'resolve' removes the '-h' option_string from the 1st subparser (but does not delete the whole action).  A kludgy fix is to add the '-h' back in (after p3 is created):

    p1._actions[0].option_strings=['-h']

'p1._actions' is the list of actions (arguments) for subparser p1.  Usually help is the first action (if isn't in p3 because of the parents resolve action).

I may work out a custom conflict handler function, but for now this appears to solve the issue.  I don't know if the patch I proposed solves your issue or not.

----------

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

From report at bugs.python.org  Wed Mar 23 23:03:26 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 24 Mar 2016 03:03:26 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1458788606.77.0.792929990234.issue9694@psf.upfronthosting.co.za>


paul j3 added the comment:

I can see changing the group title from 'optional arguments' to 'options' or 'optionals'

    parser._optionals.title
    'optional arguments'

But I don't think there's a need to change references in the code or its comments from 'optionals' to 'options'.  I like the parallelism between 'optionals' and 'positionals'.  The terms are well defined in the code.  During parsing, the 'required' attribute is only used at the end to check for missing arguments.

In Stackoverflow questions I'm tended to talk about 'flagged arguments'.

I still favor encouraging users to define their argument group(s), and making it easier to modify the titles of the two predefined groups.  I don't see enough of a consensus on alternative titles to make more sweeping changes.

----------

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

From report at bugs.python.org  Thu Mar 24 12:46:19 2016
From: report at bugs.python.org (Jared Deckard)
Date: Thu, 24 Mar 2016 16:46:19 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
 the actions of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1458837979.58.0.21880884415.issue22401@psf.upfronthosting.co.za>


Jared Deckard added the comment:

That is correct. (Thank you for whipping up a repro script from my description).

I appreciate the work around, but it is nearly as verbose as manually duplicating the parameters on the child and I would have to type up a large comment block to educate future developers on the hack.

Is there some documentation I am missing or is the "resolve" conflict handler broken?

> The parents= argument takes a list of ArgumentParser objects, collects all the positional and optional actions from them, and adds these actions to the ArgumentParser object being constructed.
https://docs.python.org/3.6/library/argparse.html#parents

It would be nice if the "error" conflict handler ignored conflicts when the actions are identical.

It should be expected that the "resolve" conflict handler would not modify the parents. It is exhibiting undocumented and undesirable side effect, which indicates to me that it is a bug not a missing feature.

As for the patch, I'm not sure why you would ever want "action_copy" to be False. It seems like creating copies to insulate the originals ignores the underlying issue that these parents are being mutated when the operation implies a union of properties with no side effects.

I don't think the fix for this should be behind an optional flag, I think the fix is to update "resolve" to take into consideration multiple parents like the custom conflict handler in your sample.

----------

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

From report at bugs.python.org  Thu Mar 24 12:48:34 2016
From: report at bugs.python.org (Jared Deckard)
Date: Thu, 24 Mar 2016 16:48:34 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
 the actions of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1458838114.2.0.698891438867.issue22401@psf.upfronthosting.co.za>


Jared Deckard added the comment:

Adding back components and version data I unintentionally removed in http://bugs.python.org/msg262314

----------
components: +Documentation, Tests
versions: +Python 3.5

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

From report at bugs.python.org  Thu Mar 24 16:16:19 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 24 Mar 2016 20:16:19 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
 the actions of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1458850579.12.0.667719402728.issue22401@psf.upfronthosting.co.za>


paul j3 added the comment:

Neither 'parents' or 'resolve' are documented in any detail.  Most of what I know comes from reading the code.

'parents' are, I think, most useful when importing a parser from some other module.  It lets you add arguments to your own parser without digging into the other module's code.  And 'resolve' lets you overwrite arguments.  

Copying arguments by reference is the easiest thing to do in Python, and apparently no one asked, 'what if the user wants to use the parent independently?'

Note I had to add a 'copy' method, because nothing else in 'argparse' needs it.  And no one has written code to check whether two Actions are the same (other than the obvious one of checking object ids).  Again, no need.

Copy and paste and utility functions are great ways of defining multiple arguments when mechanisms like 'parents' prove to be too clumsy.  Look at `test_argparse.py` for examples of utility code that streamlines parser definition.  Each test case requires a new parser (or more).

----------

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

From report at bugs.python.org  Thu Mar 24 18:39:05 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 24 Mar 2016 22:39:05 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1458859145.77.0.309110828854.issue8557@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

Here's the workaround I'm opting for:

if sys.platform =='win32':
    distutils.spawn.find_executable(cmd[0]) + cmd[1:]

----------
nosy: +Anthony Sottile

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

From report at bugs.python.org  Fri Mar 25 00:43:26 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 25 Mar 2016 04:43:26 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1458881005.98.0.961092238191.issue8557@psf.upfronthosting.co.za>


Eryk Sun added the comment:

As is documented for CreateProcess [1], the search path always includes the following directories:

    * The directory from which the application loaded.
    * The current directory for the parent process.
    * The Windows system directory. Use the
      GetSystemDirectory function to get the path of
      this directory.
    * The 16-bit Windows system directory. There is no
      function that obtains the path of this directory,
      but it is searched. The name of this directory is
      System.
    * The Windows directory. Use the GetWindowsDirectory
      function to get the path of this directory.
    * The directories that are listed in the PATH
      environment variable.

The value of PATH comes from the calling process environment, not from the environment passed in the lpEnvironment parameter. If you need to search some other list of paths, you can use shutil.which to find the fully qualified path of the target executable.

Note that in Vista+ you can remove the current directory from the search list by defining the environment variable "NoDefaultCurrentDirectoryInExePath" [2]. 

The following examples show the minimum search path that CreateProcess uses when PATH isn't defined.

    >>> 'PATH' in os.environ
    False

    >>> subprocess.call('python -Sc "import sys; print(sys.prefix)"')
    Breakpoint 0 hit
    KERNELBASE!SearchPathW:
    00007ff9`cf4b5860 488bc4          mov     rax,rsp
    0:000> du @rcx
    0000006c`a7074410  "C:\Program Files\Python35;.;C:\W"
    0000006c`a7074450  "indows\SYSTEM32\;C:\Windows\syst"
    0000006c`a7074490  "em;C:\Windows"
    0:000> g
    C:\Program Files\Python35
    0

    >>> os.environ['NoDefaultCurrentDirectoryInExePath'] = '1'

    >>> subprocess.call('python -Sc "import sys; print(sys.prefix)"')
    Breakpoint 0 hit
    KERNELBASE!SearchPathW:
    00007ff9`cf4b5860 488bc4          mov     rax,rsp
    0:000> du @rcx
    0000006c`a6560710  "C:\Program Files\Python35;C:\Win"
    0000006c`a6560750  "dows\SYSTEM32\;C:\Windows\system"
    0000006c`a6560790  ";C:\Windows"
    0:000> g
    C:\Program Files\Python35
    0

Note that in the 2nd case the current directory ('.') is no longer present between the application directory ("C:\Program Files\Python35") and the system directory ("C:\Windows\SYSTEM32\").

CreateProcess executes PE executables and batch files (run via the %ComSpec% interpreter). It automatically appends the .exe extension when searching for an executable. It does this via the lpExtension parameter of SearchPath [3]. 

Some .com files are PE executables (e.g. chcp.com). Otherwise it's not really usefully to loop over the PATHEXT extensions unless you're using shell=True, since most are filetypes that CreateProcess doesn't support [4]. 

[1]: https://msdn.microsoft.com/en-us/library/ms682425
[2]: https://msdn.microsoft.com/en-us/library/ms684269
[3]: https://msdn.microsoft.com/en-us/library/aa365527
[4]: If Microsoft's Windows team cared at all about cross-platform
     idioms they'd add shebang support to CreateProcess, which
     would make all scripts, not just batch files, directly
     executable without requiring ShellExecuteEx and registered
     filetypes. ShellExecuteEx doesn't support a lot of useful
     creation flags that are only available by calling
     CreateProcess directly, and it also doesn't check ACLs to
     prevent executing a file. So scripts are second class
     citizens in Windows, which is why Python has to embed 
     scripts in .exe wrappers.

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

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

From report at bugs.python.org  Fri Mar 25 00:49:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Mar 2016 04:49:42 +0000
Subject: [docs] [issue26638] Avoid warnings about missing CLI options when
 building documentation
Message-ID: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>


New submission from Martin Panter:

Defeat many warnings and related fixes building documentation

* Mask various CLI options with exclamation marks (!)
* Correct link to CLI section in zipapp
* Make CLI section label in timeit less ambiguous

The following warnings from unittest remain. Ideally they should be linked to the Python CLI documentation, but this does not seem possible because the ?unittest? documentation defines its own CLI options.

Doc/library/unittest.rst:1965: WARNING: unknown option: -Wd
Doc/library/unittest.rst:1965: WARNING: unknown option: -Wa
Doc/library/unittest.rst:2051: WARNING: unknown option: -W

----------
assignee: docs at python
components: Documentation
files: doc-warnings.patch
keywords: patch
messages: 262401
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid warnings about missing CLI options when building documentation
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42282/doc-warnings.patch

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

From amirmalik.007 at gmail.com  Fri Mar 25 01:54:00 2016
From: amirmalik.007 at gmail.com (amir malik)
Date: Fri, 25 Mar 2016 11:24:00 +0530
Subject: [docs] Correction in PYTHON 3 Doc tutorial.pdf
Message-ID: <CAF9VtKK9bxas5FW2DpWWYTarJGe6WPzF5tcdOKpVk2xhSUwYdA@mail.gmail.com>

Hi team,

I downloaded the doc from below URL:
https://docs.python.org/3/download.html

PDF (A4 paper size) Download
<https://docs.python.org/3/archives/python-3.5.1-docs-pdf-a4.zip> (ca. 8 MB)

I downloaded the packed as .zip file & unzipped it and started with
docs-pdf/tutorial.pdf

3.1.3 Lists:

At page No: 12
letters[2:5] = ['C', 'D', 'E']

should be corrected to letters[2:4] = ['C', 'D', 'E']

Thanks,
Amir Malik,
Mobile: +91-9971509933
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160325/88a1dadb/attachment.html>

From zachary.ware+pydocs at gmail.com  Fri Mar 25 02:18:28 2016
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 25 Mar 2016 01:18:28 -0500
Subject: [docs] Correction in PYTHON 3 Doc tutorial.pdf
In-Reply-To: <CAF9VtKK9bxas5FW2DpWWYTarJGe6WPzF5tcdOKpVk2xhSUwYdA@mail.gmail.com>
References: <CAF9VtKK9bxas5FW2DpWWYTarJGe6WPzF5tcdOKpVk2xhSUwYdA@mail.gmail.com>
Message-ID: <CAKJDb-N8qrhp16pzmQEA-gaeX7Dj1keia6FXqTUABW-aFPKgAg@mail.gmail.com>

Hi Amir,

On Fri, Mar 25, 2016 at 12:54 AM, amir malik <amirmalik.007 at gmail.com> wrote:
> Hi team,
>
> I downloaded the doc from below URL:
> https://docs.python.org/3/download.html
>
> PDF (A4 paper size)Download (ca. 8 MB)
>
> I downloaded the packed as .zip file & unzipped it and started with
> docs-pdf/tutorial.pdf
>
> 3.1.3 Lists:
>
> At page No: 12

More simply, this is at
https://docs.python.org/3/tutorial/introduction.html#lists

> letters[2:5] = ['C', 'D', 'E']
>
> should be corrected to letters[2:4] = ['C', 'D', 'E']

This is actually correct as written.  Try it!

   >>> letters = ['a', 'b', 'c', 'd', 'e', 'f', 'g']
   >>> letters[2:5]
   ['c', 'd', 'e']
   >>> letters[2:5] = ['C', 'D', 'E']
   >>> letters
   ['a', 'b', 'C', 'D', 'E', 'f', 'g']
   >>> letters[2:4] = ['c', 'd', 'e']
   >>> letters
   ['a', 'b', 'c', 'd', 'e', 'E', 'f', 'g']

Remember that in Python, slicing ([2:5]) means "start at position 2,
and give me everything up to (but not including) 5", which yields the
values at indexes 2, 3, and 4.

Thanks for the report anyway, we do appreciate it.

Regards,
-- 
Zach

From report at bugs.python.org  Fri Mar 25 13:33:56 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Mar 2016 17:33:56 +0000
Subject: [docs] [issue26629] Need an ability to build standard DLLs with
 distutils
In-Reply-To: <1458766467.89.0.930968148514.issue26629@psf.upfronthosting.co.za>
Message-ID: <1458927236.14.0.715075869102.issue26629@psf.upfronthosting.co.za>


Steve Dower added the comment:

(Obligatory recommendation that you use Cython rather than ctypes, especially if you're going to require your users to have a compiler handy - in general this isn't recommended on Windows at all; make sure you distribute wheels if you want to make your users' lives easiest.)

I haven't tested this, but I believe you want to specify your libraries with the `libraries` parameter, not the `extensions` parameter:

LIBRARIES = [
    ('my_lib', {'sources': ['my_lib.c'], 'include_dirs': ['dirs', 'if', 'you', 'want'], 'macros': ['DEFINES', 'IF', 'YOU', 'WANT']})
]

setup(
    ...
    libraries=LIBRARIES,
    ...
)

Then you need to ensure build_clib is run to produce it. I'd imagine that will just happen, but I could be wrong.

Again, I haven't tried this myself, but it seems to be the right way to build a regular library.

----------

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

From report at bugs.python.org  Fri Mar 25 13:34:51 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Mar 2016 17:34:51 +0000
Subject: [docs] [issue26629] Need an ability to build standard DLLs with
 distutils
In-Reply-To: <1458766467.89.0.930968148514.issue26629@psf.upfronthosting.co.za>
Message-ID: <1458927291.53.0.324595679141.issue26629@psf.upfronthosting.co.za>


Steve Dower added the comment:

Oh, and just saw that you're apparently asking about 2.7. I was referring to the 3.5 sources for distutils, so some things may be different in 2.7. But I doubt distutils has changed that much since then.

----------

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

From report at bugs.python.org  Sun Mar 27 13:36:07 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 27 Mar 2016 17:36:07 +0000
Subject: [docs] [issue15117] Please document top-level sqlite3 module
 variables
In-Reply-To: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za>
Message-ID: <1459100167.45.0.0227295169643.issue15117@psf.upfronthosting.co.za>


Berker Peksag added the comment:

*_version_* attributes OP mentioned have already been documented in b8b26feb3e1a.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar 27 15:37:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Mar 2016 19:37:49 +0000
Subject: [docs] [issue23758] Improve documenation about num_params in
 sqlite3 create_function and create_aggregate
In-Reply-To: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>
Message-ID: <20160327193746.131008.89790.A1685085@psf.io>


Roundup Robot added the comment:

New changeset 02efd708c5c0 by Berker Peksag in branch '3.5':
Issue #23758: Improve num_params docs of create_{function,aggregate} functions
https://hg.python.org/cpython/rev/02efd708c5c0

New changeset 5be12f20d8f2 by Berker Peksag in branch 'default':
Issue #23758: Improve num_params docs of create_{function,aggregate} functions
https://hg.python.org/cpython/rev/5be12f20d8f2

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

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

From report at bugs.python.org  Sun Mar 27 15:39:33 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 27 Mar 2016 19:39:33 +0000
Subject: [docs] [issue23758] Improve documenation about num_params in
 sqlite3 create_function and create_aggregate
In-Reply-To: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>
Message-ID: <1459107573.13.0.344643630995.issue23758@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thank you C?dric. I also added tests to verify the behavior of num_params=-1.

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

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

From report at bugs.python.org  Sun Mar 27 19:49:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Mar 2016 23:49:08 +0000
Subject: [docs] [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1459122548.06.0.942585160811.issue22558@psf.upfronthosting.co.za>


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


----------
title: Missing hint to source code - complete -> Missing doc links to source code

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

From report at bugs.python.org  Mon Mar 28 00:54:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 28 Mar 2016 04:54:16 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1459140856.08.0.814063979344.issue9694@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am willing to drop most of the code and comment changes if that moves us closer to consensus. Paul: would you accept changing the heading ?optional arguments? to ?options? in 3.6?

I thought we were close to consensus to use ?options?, but maybe that is my own bias showing. Re-reading through this thread, here is a summary of the people that seem to prefer renaming the ?optional arguments? heading:

Steven: ?flag arguments?, but concerned about affecting existing help messages
David: options, switches
Eric: replace adjective ?optional? but leave ?. . . arguments?
Ben (OP): options
Martin Panter: options, flags, switches, or non-positional arguments
Oliver: switches
Terry: keyword arguments
Ryan: options, or other suggestions

Martin d'Anjou and Raymond seem to prefer splitting out a third group, ?required arguments?, although it is not clear how that would tie in with the ?positional arguments? group.

I think making it easier to modify the headings is worthwhile only if we deprecated the old heading in favour of using a new default name in the future. To me the problem is the default behaviour, not that argparse is inflexible.

Another option might be to fix Issue 10529 (explain using gettext with argparse), and then use that to translate the "optional arguments" string. But I don?t know how to do this.

Another thought is if we added a notice to Porting to Python 3.6 in What?s New, that might ease concerns about changing the heading.

----------

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

From report at bugs.python.org  Mon Mar 28 02:17:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Mar 2016 06:17:15 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <20160328061712.21078.65197.9CC72AB3@psf.io>


Roundup Robot added the comment:

New changeset 566fe3564684 by Raymond Hettinger in branch '3.5':
Issue #25314: store_true and store_false also create appropriate defaults.
https://hg.python.org/cpython/rev/566fe3564684

New changeset 9fdeca5fdbf0 by Martin Panter in branch 'default':
Issue #25314: Merge argparse doc from 3.5
https://hg.python.org/cpython/rev/9fdeca5fdbf0

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

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

From report at bugs.python.org  Mon Mar 28 02:36:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 28 Mar 2016 06:36:47 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1459147007.16.0.809262083244.issue25314@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the record, porting the change was rather easy (hg graft + tweak + hg commit --amend). With that applied, I think it eliminates the need for the store_true/false half of Julien?s patch.

Is the store_const half of Julien?s patch ready to commit?

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

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

From report at bugs.python.org  Mon Mar 28 11:21:24 2016
From: report at bugs.python.org (Sworddragon)
Date: Mon, 28 Mar 2016 15:21:24 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
Message-ID: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>


New submission from Sworddragon:

The documentation for re.compile says "Compile a regular expression pattern into a regular expression object, which can be used for matching using its match() and search() methods, described below." which implies that match() and search() are the only methods for it while there are a few more. Maybe this sentence should be worded more generic or at least complete the list.

----------
assignee: docs at python
components: Documentation
messages: 262571
nosy: Sworddragon, docs at python
priority: normal
severity: normal
status: open
title: Documentation for re.compile is a bit outdated
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 29 03:14:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 29 Mar 2016 07:14:26 +0000
Subject: [docs] [issue26638] Avoid warnings about missing CLI options when
 building documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <1459235665.89.0.399030184608.issue26638@psf.upfronthosting.co.za>


Martin Panter added the comment:

FTR the warnings that I am fixing were apparently enabled in Sphinx 1.3.4, reverted in 1.3.6, and added in 1.4.

----------

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

From xhzheng at physics.mcgill.ca  Sun Mar 27 16:54:40 2016
From: xhzheng at physics.mcgill.ca (Xiaohong Zheng)
Date: Sun, 27 Mar 2016 15:54:40 -0500
Subject: [docs] About PySCALAPACK
Message-ID: <2016032715543871232817@physics.mcgill.ca>

Hi,

Very nice to know PySCALAPACK in PyACTS.

It seems that the documentation and installation guide of pyACTS are both in Spanish. I do not understand a single word. Could you tell me whether you have an English version of them or not. I need to use PySCALAPACK for doing some matrix operations in Python. Thank you very much.

Sincerely,
Xiaohong Zheng (McGill University, Canada)


xhzheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160327/993bdae3/attachment.html>

From report at bugs.python.org  Tue Mar 29 10:24:46 2016
From: report at bugs.python.org (Axel Luttgens)
Date: Tue, 29 Mar 2016 14:24:46 +0000
Subject: [docs] [issue26665] pip is not bootstrapped by default
Message-ID: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za>


New submission from Axel Luttgens:

Relevant page:

????https://docs.python.org/2/library/ensurepip.html

One may read:

????In most cases, end users of Python shouldn?t need to invoke
????this module directly (as pip should be bootstrapped by default),
????but it may be needed if installing pip was skipped when
????installing Python (or when creating a virtual environment) or
????after explicitly uninstalling pip.

As far as I correctly read the configure file that comes with the 2.7.11 tarball, the default is to behave as if --with-ensurepip=no had been passed.

As a result, that sentence fragment:

????(as pip should be bootstrapped by default)

may appear somewhat ambiguous for those compiling Python themselves.

Perhaps could this one avoid some head scratching:

????(as packagers are expected to have bootstrapped pip)

HTH,
Axel

----------
assignee: docs at python
components: Documentation
messages: 262610
nosy: Axel, docs at python
priority: normal
severity: normal
status: open
title: pip is not bootstrapped by default
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 29 10:26:34 2016
From: report at bugs.python.org (Axel Luttgens)
Date: Tue, 29 Mar 2016 14:26:34 +0000
Subject: [docs] [issue26665] pip is not bootstrapped by default on 2.7
In-Reply-To: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za>
Message-ID: <1459261594.85.0.821430034955.issue26665@psf.upfronthosting.co.za>


Changes by Axel Luttgens <axel.luttgens at skynet.be>:


----------
title: pip is not bootstrapped by default -> pip is not bootstrapped by default on 2.7

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

From report at bugs.python.org  Wed Mar 30 07:19:11 2016
From: report at bugs.python.org (Axel Luttgens)
Date: Wed, 30 Mar 2016 11:19:11 +0000
Subject: [docs] [issue26672] regrtest missing in the module name
Message-ID: <1459336751.45.0.914074281653.issue26672@psf.upfronthosting.co.za>


New submission from Axel Luttgens:

Relevant page:

????https://docs.python.org/2/library/test.html

One may read (section 25.5.2):

????Specifying all as the value for the -u option enables all
????possible resources: python -m test -uall.

I guess this should be:

????Specifying all as the value for the -u option enables all
????possible resources: python -m test.regrtest -uall.

HTH,
Axel

----------
assignee: docs at python
components: Documentation
messages: 262661
nosy: Axel, docs at python
priority: normal
severity: normal
status: open
title: regrtest missing in the module name
type: enhancement
versions: Python 2.7

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

From mcole8 at binghamton.edu  Tue Mar 29 19:31:02 2016
From: mcole8 at binghamton.edu (Matthew Cole)
Date: Tue, 29 Mar 2016 19:31:02 -0400
Subject: [docs] Edits to Python 3.5.1: 20.8. xml.dom.pulldom
Message-ID: <7CA54A96-9AB6-4323-88C9-1611D1DF2D63@binghamton.edu>

Hello Documentation Maintainer,

1) Typo: 

In the code example for expandNode(node) in section 20.8.1, the following code appears:

xml = '<html><title>Foo</title> <p>Some text <div>and more</div></p> </html>?
doc = pulldom.parseString(xml)
for event, node in doc:
	if event == pulldom.START_ELEMENT and node.tagName == 'p':
		# Following statement only prints '<p/>'
		print(node.toxml())
		doc.exandNode(node)
		# Following statement prints node with all its children '<p>Some text <div>and more</div></p>'
		print(node.toxml())

The line reading doc.exandNode(node) should read doc.expandNode(node) instead.

2) Recommendation:

Also in section 20.8.1, in an above code sample from section 20.8, the import statement is shown:

from xml.dom import pulldom

The code sample in section 20.8.1 only works if you include that import statement, so may I recommend adding it?

Thanks for your hard work!

Regards,
Matthew Cole
Binghamton University
New York, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160329/d94db648/attachment.html>

From berker.peksag at gmail.com  Wed Mar 30 09:31:32 2016
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 30 Mar 2016 16:31:32 +0300
Subject: [docs] Edits to Python 3.5.1: 20.8. xml.dom.pulldom
In-Reply-To: <7CA54A96-9AB6-4323-88C9-1611D1DF2D63@binghamton.edu>
References: <7CA54A96-9AB6-4323-88C9-1611D1DF2D63@binghamton.edu>
Message-ID: <CAF4280+GCcEoNGFcqacujMz+Oezabta=dLRN+EzGic6rW_mQ4g@mail.gmail.com>

On Wed, Mar 30, 2016 at 2:31 AM, Matthew Cole <mcole8 at binghamton.edu> wrote:
> Hello Documentation Maintainer,
>
> 1) Typo:
>
> In the code example for expandNode(node) in section 20.8.1, the following
> code appears:
>
> xml = '<html><title>Foo</title> <p>Some text <div>and more</div></p>
> </html>?
> doc = pulldom.parseString(xml)
> for event, node in doc:
> if event == pulldom.START_ELEMENT and node.tagName == 'p':
> # Following statement only prints '<p/>'
> print(node.toxml())
> doc.exandNode(node)
> # Following statement prints node with all its children '<p>Some text
> <div>and more</div></p>'
> print(node.toxml())
>
> The line reading doc.exandNode(node) should read doc.expandNode(node)
> instead.
>
> 2) Recommendation:
>
> Also in section 20.8.1, in an above code sample from section 20.8, the
> import statement is shown:
>
> from xml.dom import pulldom
>
> The code sample in section 20.8.1 only works if you include that import
> statement, so may I recommend adding it?

Hi Matthew,

Thank your for your report. I've addressed both of your suggestions in
https://hg.python.org/cpython/rev/a38c6e6084cb

--Berker

From mail at timgolden.me.uk  Thu Mar 31 07:01:33 2016
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 31 Mar 2016 12:01:33 +0100
Subject: [docs] About PySCALAPACK
In-Reply-To: <2016032715543871232817@physics.mcgill.ca>
References: <2016032715543871232817@physics.mcgill.ca>
Message-ID: <56FD038D.70100@timgolden.me.uk>

On 27/03/2016 21:54, Xiaohong Zheng wrote:
> Hi,
> 
> Very nice to know PySCALAPACK in PyACTS.
> 
> It seems that the documentation and installation guide of pyACTS are
> both in Spanish. I do not understand a single word. Could you tell me
> whether you have an English version of them or not. I need to use
> PySCALAPACK for doing some matrix operations in Python. Thank you very much.


Xiaohong Zheng,

I'm afraid that neither of those packages are managed by the core Python
documentation team; you'll have to find a support forum which has people
who know those packages. I imagine something around the SciPy community
would include such people.

TJG

From report at bugs.python.org  Thu Mar 31 13:36:39 2016
From: report at bugs.python.org (Andy Maier)
Date: Thu, 31 Mar 2016 17:36:39 +0000
Subject: [docs] [issue26678] Incorrect linking to elements in datetime
 package
Message-ID: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>


New submission from Andy Maier:

Hi, I did search for these in the open bugs, but did not find any matching bug.

I have a project that revealed that some of its InterSphinx links to existing classes/types or methods to not resolve their targets, or to resolve to a target that is not the right one (IMO).

This issue here describes everything I found in the datetime package.

Line numbers in this issue apply to the datetime.rst file as of commit 96a98bcaac70 (https://hg.python.org/cpython/file/96a98bcaac70/Doc/library/datetime.rst).

* class datetime.tzinfo:

  An intersphinx link to it gets resolved but targets the short description of the class in the intro (line 106 of datetime.rst), and I did not find a way to target the full description (line 1552), which is really what this should be resolved to (IMO).

  I suspect that this has to do with the fact that this class has only one anchor on its short description on line 106, while companion classes such as datetime.datetime have two anchors (lines 91 and 681) where the last one wins (and happens to be the long description). However, see the next item.

* class datetime.timezone:

  Same issue as for class datetime.tzinfo; links get resolved but land on the short intro. However, this time there are two anchors (lines 113 and 1795). So maybe my suspicion above is rather speculation...

* method datetime.tzinfo.utcoffset:

  An intersphinx link to it does not get resolved. On line 1579 in datetime.rst, there is a `.. method:: tzinfo.utcoffset(dt)` but at least these intersphinx links did not get resolved:

      :func:`py:tzinfo.utcoffset`
      :func:`py:datetime.tzinfo.utcoffset`

  Do method anchors need the anchor for their defining class close by to work? Which because if the first issue above, would be the short version of it, way above. (Again speculation)

* Same for method datetime.tzinfo.dst

----------
assignee: docs at python
components: Documentation
messages: 262698
nosy: andymaier, docs at python
priority: normal
severity: normal
status: open
title: Incorrect linking to elements in datetime package
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 31 15:33:42 2016
From: report at bugs.python.org (Robert Bachmann)
Date: Thu, 31 Mar 2016 19:33:42 +0000
Subject: [docs] [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE
 inverted
Message-ID: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za>


New submission from Robert Bachmann:

The table on <https://docs.python.org/3/library/curses.html>
lists:
__________________________
Page Up 	KEY_NPAGE
Page Down 	KEY_PPAGE
__________________________

it should be vice versa.

----------
assignee: docs at python
components: Documentation
files: curses.patch
keywords: patch
messages: 262701
nosy: Robert Bachmann, docs at python
priority: normal
severity: normal
status: open
title: curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42334/curses.patch

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

From report at bugs.python.org  Thu Mar 31 18:24:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 31 Mar 2016 22:24:18 +0000
Subject: [docs] [issue26678] Incorrect linking to elements in datetime
 package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459463058.36.0.941112305855.issue26678@psf.upfronthosting.co.za>


Martin Panter added the comment:

Currently the ?datetime? documentation has quick descriptions of classes marked up with ?.. class::? in the introduction, and then dedicated sections with more details. Many other parts of Python?s documentation have a similar structure.

IMO it is better to include the ?.. class::? markup closer to the list of methods, and then each method can be indented underneath it. See my changes to the ?socketserver? documentation (Issue 15608, compare 3.4 vs 3.5) where I indented a whole lot of methods under class definitions. I suspect the reason why things are not like this is just that it is leftover from a conversion from an earlier markup format.

The earlier class introductions are also marked up with :noindex:, which would explain which become link targets.

Dunno about your intersphinx stuff though. Is that linking to the Python documentation from external projects?

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

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

From report at bugs.python.org  Thu Mar 31 21:31:32 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Apr 2016 01:31:32 +0000
Subject: [docs] [issue26683] Questionable terminology for describing what
 locals() does
Message-ID: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The docs for locals() say that inside a function that local variables and free variables are included:  https://docs.python.org/3/library/functions.html#locals

Elsewhere we use the terms "cell variables" or "nonlocals".   Mathematically, the word "free" means unbound, so that isn't applicable here and isn't the usual way of describing variables in the enclosing scope.

>>> def f(x):
        def g(y):
            z = x + y
            print(locals())
        return g

>>> f(10)(20)
{'x': 10, 'y': 20, 'z': 30}

Also, I'm not sure why "x" and "y" are included in the definition for locals().  That seems strange given that "x" and "y" are not local to "g" and that "x += 1" would fail with an UnboundLocalError.

----------
assignee: docs at python
components: Documentation
messages: 262713
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Questionable terminology for describing what locals() does
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 31 23:36:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 03:36:16 +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: <1459481776.11.0.164121959283.issue26683@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding ?free variables?, in Issue 17546 I proposed the wording ?. . . also includes non-local, non-global names?.

In your code example, I would consider y to be 100 percent local to the g() function. It is a function parameter, and ?y += 1? should work. I agree x is not a true local, it is a ?non-local non-global?. A national variable maybe :)

For functions, considering that you shouldn?t modify the dictionary (original concern in Issue 17546), I do agree the behaviour is a bit strange and inconsistent. It might have made more sense to either only return true locals, or return a complete namespace of locals, non-locals, globals, and builtins. It seems there is no way to get a similar list of non-local non-globals in a class scope.

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

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

From jeog.dev at gmail.com  Thu Mar 31 11:44:22 2016
From: jeog.dev at gmail.com (J.E. Ogden)
Date: Thu, 31 Mar 2016 11:44:22 -0400
Subject: [docs] Submitting an article/paper on CPython's Private Heap
Message-ID: <CAK-_zEvAT4Un48updiZp5PStiTmdqe073pXN38RRecZaLp=eFQ@mail.gmail.com>

Recently I had to dig into cpython's private memory heap (there wasn't much
current, detailed information I could find outside of the the source) and
decided to put what I learned into an article/paper on the topic.

I was wondering: a) where's the appropriate place to contribute it, and b)
could someone with cpython development experience proof/review it?

(Because it has a number of diagrams, formated text, footnotes etc. it's
currently only presentable in pdf format.)

thanks,
jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160331/e875f84a/attachment.html>

From royneeharika at gmail.com  Thu Mar 31 14:11:00 2016
From: royneeharika at gmail.com (Neeharika Roy)
Date: Thu, 31 Mar 2016 14:11:00 -0400
Subject: [docs] Subprocess Startup Error
Message-ID: <CAL9v_HCj5RcO271CCj69XFrVzt6ihnsRRvA_bMJfjZxGULyW-A@mail.gmail.com>

Hi, I was programming normally until suddenly it started showing me the
'Subprocess Startup Error". I disabled my firewall like it suggested and it
still didn't work.

Please respond back for a solution.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160331/016617de/attachment.html>