From report at bugs.python.org  Wed Apr  1 00:20:24 2015
From: report at bugs.python.org (paul j3)
Date: Tue, 31 Mar 2015 22:20:24 +0000
Subject: [docs] [issue23814] argparse: Parser level defaults do not always
	override	argument level defaults
In-Reply-To: <1427740847.33.0.866518706982.issue23814@psf.upfronthosting.co.za>
Message-ID: <1427840423.94.0.661205419068.issue23814@psf.upfronthosting.co.za>


paul j3 added the comment:

The handling of defaults is a bit complicated.

Note that `set_defaults` both sets a `_defaults` attribute, and any actions with a matching `dest`.  So it could change the `default` of 0, 1 or more actions.

    def set_defaults(self, **kwargs):
        self._defaults.update(kwargs)

        # if these defaults match any existing arguments, replace
        # the previous default on the object with the new one
        for action in self._actions:
            if action.dest in kwargs:
                action.default = kwargs[action.dest]


`add_argument` gets `default` from the default parameter (kwarg), the container's `_defaults` or the parser `.argument_default`.  The earliest in that list has priority.

Finally, at the start of `parse_known_args`, each action's `default` is added to the namespace (IF it isn't already there), and values from `_defaults` are also add (also IF not already present).  So here the priority is user supplied `namespace`, action `default`, parser `_defaults`.

And finally, at the end of `_parse_known_args`, any string values in the namespace that match their action default are passed through `get_values`, which may convert them via the 'type'.

I've skimmed over a couple of things:

- defaults defined by the Action class (e.g. 'store_true' sets a False default)

- how parent's `_defaults` are copied

- when `_defaults` affects that final `get_values` action.

- the relative priority of parser and subparsers _defaults (a current bug issue).

So as you observed, `set_defaults` can change a previously defined argument's `default`, but it does not have priority over parameters supplied to new arguments.

In my opinion, `set_default` is most useful as a way of setting Namespace values that do not have their own argument.  The documentation has an example where each subparser sets its own 'func' attribute.

    parser_foo.set_defaults(func=foo)

Maybe the documentation could be refined, though it might be tricky to do so without adding further confusion.

Changing the priorities is probably not a good idea.  The recent bug issues about parser and subparser `set_defaults` a cautionary tale.  Even the earlier change in how 'get_values' is applied to defaults has potential pitfalls.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Wed Apr  1 03:21:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Apr 2015 01:21:32 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <20150401012128.1919.92809@psf.io>


Roundup Robot added the comment:

New changeset 6244a5dbaf84 by Benjamin Peterson in branch '3.4':
document what exactly str.splitlines() splits on (closes #12855)
https://hg.python.org/cpython/rev/6244a5dbaf84

New changeset 87af6deb5d26 by Benjamin Peterson in branch 'default':
merge 3.4 (#12855)
https://hg.python.org/cpython/rev/87af6deb5d26

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

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

From report at bugs.python.org  Wed Apr  1 06:34:09 2015
From: report at bugs.python.org (Davin Potts)
Date: Wed, 01 Apr 2015 04:34:09 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427862849.47.0.742602960391.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

@berker: I would have said this should not be marked an enhancement as the proposed solution (in the patch) is to correct the errors in the documentation to accurately describe the current implemented behavior.  Does that make sense?

Whatever label we give it, do you think my logic (described in my comments on this issue) for why it is best to fix it this way makes sense to you?

----------

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

From report at bugs.python.org  Wed Apr  1 13:33:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 01 Apr 2015 11:33:05 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427887985.65.0.322156397009.issue23756@psf.upfronthosting.co.za>


Martin Panter added the comment:

After doing a bit of reading and experimenting, I think we should at least restrict bytes-like objects to ?C-contiguous?. Any looser definition risks memoryview(byteslike).tobytes() returning the bytes in a different order than their true in-memory order. Fortran-style contiguous arrays aren?t enough:

>>> import _testbuffer, sys
>>> fortran = memoryview(_testbuffer.ndarray([11, 12, 21, 22], format="B", flags=0, shape=[2, 2], strides=[1, 2], offset=0))
>>> fortran.f_contiguous
True
>>> fortran.c_contiguous
False
>>> fortran.tolist()
[[11, 21], [12, 22]]
>>> tuple(bytes(fortran))
(11, 21, 12, 22)
>>> sys.stdout.buffer.write(fortran)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous

So I am proposing a patch which:

* Restricts the bytes-like object definition to C-contiguous buffers
* Explains what I think is actually meant by ?contiguous? in the C API buffer protocol page. Turns out it is generally a more strict definition than I originally assumed.
* Explains why memoryview.tobytes() is out of order for non C-contiguous buffers
* Has a couple other fixes taking into acount memoryview.tolist() doesn?t work for zero dimensions, and is nested for more than one dimension

----------
keywords: +patch
Added file: http://bugs.python.org/file38780/c-contig.patch

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

From storchaka at gmail.com  Wed Apr  1 13:42:57 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Wed, 01 Apr 2015 11:42:57 -0000
Subject: [docs] Tighten definition of bytes-like objects (issue 23756)
Message-ID: <20150401114257.18760.71060@psf.upfronthosting.co.za>


http://bugs.python.org/review/23756/diff/14408/Doc/c-api/buffer.rst
File Doc/c-api/buffer.rst (right):

http://bugs.python.org/review/23756/diff/14408/Doc/c-api/buffer.rst#newcode294
Doc/c-api/buffer.rst:294: buffers (with a single element) are considered
both C- and
May be one-dimensional too?

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

http://bugs.python.org/review/23756/diff/14408/Doc/glossary.rst#newcode91
Doc/glossary.rst:91: :class:`bytearray` or :class:`memoryview`. 
Bytes-like objects can
May be worth to mention array.array (is it always C-contiguous?)?

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

From report at bugs.python.org  Wed Apr  1 13:44:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Apr 2015 11:44:28 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427888668.13.0.771599570118.issue23756@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

+1 for the idea overall and the patch LGTM.

----------

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

From report at bugs.python.org  Wed Apr  1 14:35:07 2015
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 01 Apr 2015 12:35:07 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427891706.93.0.27620865359.issue23756@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I have a somewhat general concern: In the last year or so, issues seem
to expand far beyond the scope that's indicated by the issue title.

For example, I don't particularly care about the definition of
"bytes-like", but the patch contains changes to areas I *do* care
about.

I don't think all of the changes are an improvement: What is
the "flattened length", why does C-contiguous have to be explained?

----------
nosy: +skrah

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

From report at bugs.python.org  Wed Apr  1 15:46:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Apr 2015 13:46:40 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427896000.53.0.812595438979.issue23484@psf.upfronthosting.co.za>


R. David Murray added the comment:

behavior vs enhancment for doc changes is really pretty meaningless/arbitrary, IMO.

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

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

From report at bugs.python.org  Wed Apr  1 16:01:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Apr 2015 14:01:45 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427896905.09.0.892062765857.issue23756@psf.upfronthosting.co.za>


R. David Murray added the comment:

I found the explanation of C-contiguous vs Fortran-contiguous helpful (and I've programmed in both of those languages, though granted not much :).  However, based on that it is not obvious to me why having a fortran-contiguous buffer prevents it from being used in the bytes-like object contexts (though granted the order might be surprising to someone who is not thinking about the memory ordering and just assuming C).

I don't have much of an opinion on the other non-glossary-entry changes, but at a quick read I'm not sure how much clarity they add, if any.

----------

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

From report at bugs.python.org  Wed Apr  1 16:05:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Apr 2015 14:05:23 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427897123.8.0.438778786875.issue23756@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, and about the general concern: I agree that this issue was apparently about the glossary entry, so making other changes is suspect and at a minimum requires adding relevant people from the experts list to nosy to get proper review of other proposed changes.

----------

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

From report at bugs.python.org  Wed Apr  1 16:24:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Apr 2015 14:24:00 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427898240.35.0.622116650114.issue23756@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What people are needed? The patch looks as great improvement to me.

----------

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

From report at bugs.python.org  Wed Apr  1 16:43:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Apr 2015 14:43:23 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427899403.71.0.549792246507.issue23756@psf.upfronthosting.co.za>


R. David Murray added the comment:

Stefan, since he's the current maintainer of the memoryview implementation.  Fortunately he spotted the issue :)  Maybe Antoine, too; he's done work in this area.  I'll add him.

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

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

From report at bugs.python.org  Wed Apr  1 17:06:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Apr 2015 15:06:10 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427900770.11.0.0136028589775.issue23756@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue23376.

----------

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

From report at bugs.python.org  Wed Apr  1 17:31:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Apr 2015 15:31:05 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427902265.6.0.44528229016.issue23484@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I use "enhancement" for non-trivial documentation patches.

Also, quoting from https://docs.python.org/devguide/triaging.html#type

"Also used for improvements in the documentation and test suite and for other refactorings."

In this case, your patch fixes a documentation issue and improving current documentation by documenting {Lock,RLock}.acquire() and release() methods properly (documentation improvements can go into bugfix branches).

----------

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

From berker.peksag at gmail.com  Wed Apr  1 17:36:10 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Wed, 01 Apr 2015 15:36:10 -0000
Subject: [docs] SemLock acquire() keyword arg 'blocking' is invalid (issue
	23484)
Message-ID: <20150401153610.18760.46021@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23484/diff/14347/Doc/library/multiprocessing.rst#newcode1199
Doc/library/multiprocessing.rst:1199: .. versionchanged:: 2.7
If the timeout parameter was added in 2.7 and 3.0, we can remove this
directive on 3.4 and default branches since it's there for the beginning
of Python 3.

On the other hand, for example, if it was added in 2.7 and 3.2, we
should change it to .. versionchanged:: 3.2 in Python 3 documentation.

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

From Imtiaz.Ahmed at nomura.com  Wed Apr  1 17:42:57 2015
From: Imtiaz.Ahmed at nomura.com (Imtiaz.Ahmed at nomura.com)
Date: Wed, 1 Apr 2015 15:42:57 +0000
Subject: [docs] Issue with method subprocess.check_output(args, *, input=None,
 stdin=None, stderr=None, shell=False, universal_newlines=False,
 timeout=None)
Message-ID: <CC4F24F59A61534294B3ED61FE59CAAA052F88F6@LONWS1033B09.EUROPE.NOM>

Hi

I think I have found an issue with the method:

subprocess.check_output(args, *, input=None, stdin=None, stderr=None, shell=False, universal_newlines=False, timeout=None)

I tried this method twice with slight change one is working but the other not.

1st which is working

import subprocess as sub
temp_str=["ls", "-d","/home/xyz_dev_39/xyzB3BenchDec"]

output = sub.check_output(temp_str,shell=False,stderr=sub.STDOUT,universal_newlines=False)

result is : /home/prism_dev_39/xyzB3BenchDec

2nd which is not working


import subprocess as sub

str = /home/xyz_dev_*/xyzB3Bench*
temp_str=["ls", "-d",str]

output = sub.check_output(temp_str,shell=False,stderr=sub.STDOUT,universal_newlines=False)


result is Error: No such file or Directory


When I tried above cmd(ls ?d /home/prism_dev_*/xyzB3Bench* ) manually on unix machine I am getting the result as 1st which is /home/xyz_dev_39/xyzB3BenchDec


Could you please check and let me know where or what is incorrect in second approach?

Regards
Imtiaz



This e-mail (including any attachments) is private and confidential, may contain proprietary or privileged information and is intended for the named recipient(s) only. Unintended recipients are strictly prohibited from taking action on the basis of information in this e-mail and must contact the sender immediately, delete this e-mail (and all attachments) and destroy any hard copies. Nomura will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in, this e-mail. If verification is sought please request a hard copy. Any reference to the terms of executed transactions should be treated as preliminary only and subject to formal written confirmation by Nomura. Nomura reserves the right to retain, monitor and intercept e-mail communications through its networks (subject to and in accordance with applicable laws). No confidentiality or privilege is waived or lost by Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is a reference to any entity in the Nomura Holdings, Inc. group. Please read our Electronic Communications Legal Notice which forms part of this e-mail: http://www.Nomura.com/email_disclaimer.htm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150401/8a10865c/attachment-0001.html>

From report at bugs.python.org  Wed Apr  1 20:32:18 2015
From: report at bugs.python.org (John Nagle)
Date: Wed, 01 Apr 2015 18:32:18 +0000
Subject: [docs] [issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts
Message-ID: <1427913138.81.0.946174755254.issue23843@psf.upfronthosting.co.za>


New submission from John Nagle:

ssl.wrap_socket() always uses the SSL certificate associated with the raw IP address, rather than using the server_host feature of TLS. Even when wrap_socket is used before calling "connect(port, host)", the "host" parameter isn't used by TLS.

To get proper TLS behavior (which only works in recent Python versions), it's necessary to create an SSLContext, then use

context.wrap_socket(sock, server_hostname="example.com")

This behavior is backwards-compatible (the SSL module didn't talk TLS until very recently) but confusing.  The documentation does not reflect this difference.  There's a lot of old code and online advice which suggests using ssl.wrap_socket().  It works until you hit a virtual host with TLS support. Then you get the wrong server cert and an unexpected "wrong host" SSL error.

Possible fixes:

1. Deprecate ssl.wrap_socket(), and modify the documentation to tell users to always use context.wrap_socket().

2. Add a "server_hostname" parameter to ssl.wrap_socket().  It doesn't accept that parameter; only context.wrap_socket() does.  Modify documentation accordingly.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 239834
nosy: docs at python, nagle
priority: normal
severity: normal
status: open
title: ssl.wrap_socket doesn't handle virtual TLS hosts
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr  1 23:37:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 01 Apr 2015 21:37:21 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427924240.96.0.560182650627.issue23756@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will to pull the stdtypes.rst changes out into a separate patch and issue, if that will make review easier. I think they are an improvement because the previous version was incorrect and misleading, but they are probably not necessary for people to understand what a C-contiguous bytes-like object is.

I don?t think ?flattened length? is explicitly defined anywhere, but it is already used in the memoryview() documentation and elsewhere. I took it to mean the number of elements in the nested list, if you ignore the fact that it is nested; i.e. ignore the extra "[" and "]" delimiters in the repr(), and just count the other values inside them.

The reason for defining C-contiguous was that I originally understood ?contiguous? to be much more general than what seems to be meant. I assumed both memoryview(contiguous)[::-1] and a 2?2?2 array with stride=[4, 1, 2] would be contiguous, although neither have the C or Fortran array layout.

I think we need to define C-contiguous well enough for people to understand which standard Python objects are bytes-like objects. Maybe not Fortran-contiguous, because it doesn?t seem relevant to standard Python objects. Considering Serhiy asked if array.array() is always C-contiguous, I may not have done enough to explain that. (I think the answer is always yes.)

David: If a Fortran array was allowed in a bytes-like context without memory copying, the order of the array elements would differ from the order returned by the meoryview.tobytes() method, which essentially is defined to copy them out in C-array or flattend-tolist() order.

----------

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

From report at bugs.python.org  Thu Apr  2 02:05:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 02 Apr 2015 00:05:06 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1427933106.54.0.730178038115.issue22671@psf.upfronthosting.co.za>


Martin Panter added the comment:

read-defaults.v3.patch:
* Split off test_RawIOBase_readall()
* Changed BufferedIOBase tests to matrix of tuples
* Added tests for empty buffer
* Test that unused part of buffer remains untouched

----------
Added file: http://bugs.python.org/file38798/read-defaults.v3.patch

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

From report at bugs.python.org  Thu Apr  2 02:52:16 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Apr 2015 00:52:16 +0000
Subject: [docs] [issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts
In-Reply-To: <1427913138.81.0.946174755254.issue23843@psf.upfronthosting.co.za>
Message-ID: <1427935936.06.0.694167202105.issue23843@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Not sure why you're using wrap_socket() directly. Most of the time you should be using a higher-level library instead (for example a HTTP(S) library).

In any case, the doc already mentions that "Starting from Python 3.2, it can be more flexible to use SSLContext.wrap_socket() instead".

I leave this open in case other people feel positively about it.

----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou

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

From report at bugs.python.org  Thu Apr  2 03:32:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 02 Apr 2015 01:32:52 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427938371.64.0.121359072322.issue23738@psf.upfronthosting.co.za>


Martin Panter added the comment:

pos-defaults.v2.patch includes the results of ?make clinic? to fix the doc strings.

Is there a consensus to use PEP 457?s slash ?/? notation? At one point I think I saw Serhiy was concerned that it might be confusing.

----------
Added file: http://bugs.python.org/file38800/pos-defaults.v2.patch

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

From report at bugs.python.org  Thu Apr  2 10:03:25 2015
From: report at bugs.python.org (John Nagle)
Date: Thu, 02 Apr 2015 08:03:25 +0000
Subject: [docs] [issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts
In-Reply-To: <1427913138.81.0.946174755254.issue23843@psf.upfronthosting.co.za>
Message-ID: <1427961805.42.0.87068424722.issue23843@psf.upfronthosting.co.za>


John Nagle added the comment:

I'm using wrap_socket because I want to read the details of a server's SSL certificate.  

"Starting from Python 3.2, it can be more flexible to use SSLContext.wrap_socket() instead" does not convey that ssl.wrap_socket() will fail to connect to some servers because it will silently check the wrong certificate.

----------

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

From report at bugs.python.org  Thu Apr  2 12:10:12 2015
From: report at bugs.python.org (Giacomo Alzetta)
Date: Thu, 02 Apr 2015 10:10:12 +0000
Subject: [docs] [issue23850] Missing documentation for
	Py_TPFLAGS_HAVE_NEWBUFFER
In-Reply-To: <1427969373.72.0.801261679654.issue23850@psf.upfronthosting.co.za>
Message-ID: <1427969412.22.0.609093980762.issue23850@psf.upfronthosting.co.za>


Changes by Giacomo Alzetta <giacomo.alzetta at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> enhancement
versions: +Python 2.7

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

From report at bugs.python.org  Thu Apr  2 12:42:47 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Apr 2015 10:42:47 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427971367.65.0.0461979503515.issue23756@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
assignee: docs at python -> skrah

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

From report at bugs.python.org  Thu Apr  2 13:10:07 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Apr 2015 11:10:07 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427973007.84.0.26304379148.issue23756@psf.upfronthosting.co.za>


Stefan Krah added the comment:

If you think that the previous version was "incorrect and misleading",
the bar for changes to be accepted seems pretty high for me.

"grep -r" doesn't seem to find "flattened length" in Doc/*.

"An object that supports the :ref:`bufferobject` and is C-contiguous, like :class:`bytes`, :class:`bytearray` or :class:`memoryview`."


This implies that all memoryviews are C-contiguous.

----------

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

From report at bugs.python.org  Thu Apr  2 16:57:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Apr 2015 14:57:07 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427986627.6.0.349481940994.issue23756@psf.upfronthosting.co.za>


R. David Murray added the comment:

> If a Fortran array was allowed in a bytes-like context without memory copying, the order of the array elements would differ from the order returned by the meoryview.tobytes() method, which essentially is defined to copy them out in C-array or flattend-tolist() order.

I'm still not seeing how this would cause such an object to throw an error if used in a bytes-like context.  I presume by the above that you mean that the results of passing the object directly to a bytes like context differs from the results of calling .tobytes() on it and passing *that* to the bytes like context.  That's not what your suggested documentation change says, though.

----------

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

From report at bugs.python.org  Thu Apr  2 17:49:49 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 02 Apr 2015 15:49:49 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427989789.03.0.165328084455.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

@berker:  Sadly, I've read those descriptions in triaging.html more than once and that part apparently did not stick in my head.  Hopefully it will now -- thanks.

@r.david:  Ok, cool -- I had been mentally associating more significance to one versus the other but that helps to understand.

As Berker correctly suspected, I would not have expected something labelled "Enhancement" to be allowed into the 2.7 branch so the explanation definitely helps.

----------

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

From python at discontinuity.net  Thu Apr  2 18:00:10 2015
From: python at discontinuity.net (python at discontinuity.net)
Date: Thu, 02 Apr 2015 16:00:10 -0000
Subject: [docs] SemLock acquire() keyword arg 'blocking' is invalid
	(issue 23484)
Message-ID: <20150402160010.18760.7163@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23484/diff/14347/Doc/library/multiprocessing.rst#newcode1199
Doc/library/multiprocessing.rst:1199: .. versionchanged:: 2.7
On 2015/04/01 17:36:10, berkerpeksag wrote:
> If the timeout parameter was added in 2.7 and 3.0, we can remove this
directive
> on 3.4 and default branches since it's there for the beginning of
Python 3.
> 
> On the other hand, for example, if it was added in 2.7 and 3.2, we
should change
> it to .. versionchanged:: 3.2 in Python 3 documentation.

Makes sense -- I will double-check when it got added to Python 3 and
make that change.

My thinking was that bringing attention to this, even if it has been
there for a while, is a good thing because this is the first time it's
been reflected in the documentation.  But if your immediate reaction is
that this looks weird (coming from 2.7 or 3.0), then my idea was the
wrong way to go.

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

From report at bugs.python.org  Fri Apr  3 13:37:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 03 Apr 2015 11:37:55 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1428061075.23.0.897847253217.issue23756@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m sorry Stefan, I now realize my changes for len(view) were indeed wrong, and the original was much more correct. I still think the tobytes() and maybe tolist() documentation could be improved, but that is a separate issue to the bytes-like definition.

I am posting c-contig.v2.patch. Hopefully you will find it is truer to my original scope :)

* Removed changes to stdtypes.rst
* Scaled back changes in buffer.rst to only explain ?C-contiguous?
* Tweaked glossary definition. Not all memoryview() objects are applicable.

David: The result of passing a Fortran array directly in a bytes-like context is typically BufferError. If this were relaxed, then we would get the inconsistency with tobytes().

>>> import _testbuffer, sys
>>> layout = [11, 21, 12, 22]
>>> fortran_array = _testbuffer.ndarray(layout, format="B", flags=0, shape=[2, 2], strides=[1, 2], offset=0)
>>> sys.stdout.buffer.write(fortran_array)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: ndarray is not C-contiguous
>>> list(memoryview(fortran_array).tobytes())  # C-contiguous order!
[11, 12, 21, 22]

----------
Added file: http://bugs.python.org/file38815/c-contig.v2.patch

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

From report at bugs.python.org  Sat Apr  4 12:57:47 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 04 Apr 2015 10:57:47 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
Message-ID: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The collections.abc documentation implies that *any* of the container ABCs can be used in an issubclass test against a class that implements all abstract methods:

> These ABCs allow us to ask classes or instances if they provide particular functionality [...]

In reality this only applies to the "One Trick Ponies" (term from PEP 3119, things like Container and Iterable, those classes with one or two methods). It fails for the compound container ABCs:

>>> from collections.abc import Sequence, Container, Sized
>>> class MySequence(object):
...     def __contains__(self, item): pass
...     def __len__(self): pass
...     def __iter__(self): pass
...     def __getitem__(self, index): pass
...     def __len__(self): pass
... 
>>> issubclass(MySequence, Container)
True
>>> issubclass(MySequence, Sized)
True
>>> issubclass(MySequence, Sequence)
False

That's because the One Trick Ponies implement a __subclasshook__ method that is locked to the specific class and returns NotImplemented for subclasses; for instance, the Iterable.__subclasshook__ implementation is:

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Iterable:
            if any("__iter__" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

The compound container classes build on top of the One Trick Ponies, so the class test will fail, NotImplemented is returned and the normal ABC tests for base classes that have been explicitly registered continues, but this won't include unregistered complete implementations.

Either the compound classes need their own __subclasshook__ implementations, or the documentation needs to be updated to make it clear that without explicit registrations the issubclass() (and isinstance()) tests only apply to the One Trick Ponies.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 240060
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: issubclass without registration only works for "one-trick pony" collections ABCs.

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

From report at bugs.python.org  Sat Apr  4 12:59:26 2015
From: report at bugs.python.org (Jon Clements)
Date: Sat, 04 Apr 2015 10:59:26 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428145166.65.0.0460414197054.issue23864@psf.upfronthosting.co.za>


Changes by Jon Clements <joncle at googlemail.com>:


----------
nosy: +joncle

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

From report at bugs.python.org  Sat Apr  4 13:04:53 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 04 Apr 2015 11:04:53 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428145493.4.0.271488472983.issue23864@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

I should have added the mixin methods for the Sequence implementation; the more complete demonstration is:

>>> from collections.abc import Sequence, Container, Sized
>>> class MySequence(object):
...     def __contains__(self, item): pass
...     def __len__(self): pass
...     def __iter__(self): pass
...     def __getitem__(self, index): pass
...     def __len__(self): pass
...     def __reversed__(self): pass
...     def index(self, item): pass
...     def count(self, item): pass
... 
>>> issubclass(MySequence, Container)
True
>>> issubclass(MySequence, Sized)
True
>>> issubclass(MySequence, Sequence)
False

----------

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

From report at bugs.python.org  Sat Apr  4 13:30:16 2015
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 04 Apr 2015 11:30:16 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428147016.7.0.0235755365437.issue23864@psf.upfronthosting.co.za>


Antti Haapala added the comment:

This does apply to all versions of Python from 2.6 up. Registering does work of course.

I believe the reason for not having the __subclasshook__ is the following sentence in PEP 3119: "ABCs are intended to solve problems that don't have a good solution at all in Python 2, such as distinguishing between mappings and sequences."

This used to be worse in <3.3 because there if you ever inherit from `Sequence` you will always end up having `__dict__`, even if you just want `__slots__`.

(By the way, if Py2 documentation is fixed, it should also say that these ABCs are new as of 2.6, not since 2.4 like the rest of the collections module).

----------
nosy: +ztane

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

From report at bugs.python.org  Sun Apr  5 00:51:35 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 04 Apr 2015 22:51:35 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428187895.08.0.392287426434.issue23864@psf.upfronthosting.co.za>


eryksun added the comment:

Probably I'm overlooking something, but why isn't this hook defined cooperatively, with a terminating base class method that returns True? If the call chain progresses to the base, then all of the interfaces have been satisfied. Otherwise one of the bases returns NotImplemented. If it's implemented cooperatively, then the `cls is Iterable` check can be removed, because it returns super().__subclasshook__(C) instead of True.

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

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

From report at bugs.python.org  Mon Apr  6 06:48:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 06 Apr 2015 04:48:01 +0000
Subject: [docs] [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1428295681.38.0.742949650819.issue18553@psf.upfronthosting.co.za>


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


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

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

From daryl5765 at gmail.com  Sat Apr  4 21:28:49 2015
From: daryl5765 at gmail.com (Daryl Klakouski)
Date: Sat, 4 Apr 2015 15:28:49 -0400
Subject: [docs] Typo in Python Documentation
Message-ID: <CAC1ox_ysS==4gkWn8RJeinviqhiu80cxnVDgS45cX21k6fUmXg@mail.gmail.com>

Hi,

In the Python 3 documentation, section 4.7.1, in the bit about
str.zfill(width)
(https://docs.python.org/3/library/stdtypes.html#str.zfill), there is
a missing close parenthesis in the second sentence, at "( ' + ' / ' -
' ".

From mail at timgolden.me.uk  Mon Apr  6 12:12:13 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 06 Apr 2015 11:12:13 +0100
Subject: [docs] Typo in Python Documentation
In-Reply-To: <CAC1ox_ysS==4gkWn8RJeinviqhiu80cxnVDgS45cX21k6fUmXg@mail.gmail.com>
References: <CAC1ox_ysS==4gkWn8RJeinviqhiu80cxnVDgS45cX21k6fUmXg@mail.gmail.com>
Message-ID: <55225BFD.7090205@timgolden.me.uk>

Fixed in the source, thanks. Should show up after the next scheduled build.

TJG

On 04/04/2015 20:28, Daryl Klakouski wrote:
> Hi,
>
> In the Python 3 documentation, section 4.7.1, in the bit about
> str.zfill(width)
> (https://docs.python.org/3/library/stdtypes.html#str.zfill), there is
> a missing close parenthesis in the second sentence, at "( ' + ' / ' -
> ' ".
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>

From python at 2sn.net  Mon Apr  6 13:20:13 2015
From: python at 2sn.net (Alexander Heger)
Date: Mon, 6 Apr 2015 21:20:13 +1000
Subject: [docs] bug in
 https://docs.python.org/3.4/reference/expressions.html#grammar-token-expression_nocond
 ?
Message-ID: <CAN3CYHys61dXrsmUTahE+4CGOa-tgbAGqCvP4gmpqZhNJTyQ9g@mail.gmail.com>

In "6.11. Conditional expressions" the first line reads:
"""
conditional_expression ::=  or_test ["if" or_test "else" expression]
"""

I think this should be

"""
conditional_expression ::=  expression ["if" or_test "else" expression]
"""

and maybe the third line,
"""
expression_nocond      ::=  or_test | lambda_expr_nocond
"""
should also replace "or_test" by somethings else?  A truly
conditionless expression or something in parentheses if containing a
condition?

-Alexander

From alfred at 54.org  Tue Apr  7 09:31:17 2015
From: alfred at 54.org (Alfred Morgan)
Date: Tue, 7 Apr 2015 00:31:17 -0700
Subject: [docs] Please update your ElementTree Python 2.7 docs
Message-ID: <CAJzjx=2bK7+XMgCZEYp9vZd1W-G-ooRtPid8yAxAQbjkGupL+g@mail.gmail.com>

Your 2.7 source code and your 2.7 docs are out of sync. In the source there
are many methods that have the `namespaces` argument and it doesn't show up
documented at all in your docs other than one example that uses this
undocumented argument.

example:

"findall(*match*)" in the docs:

https://docs.python.org/2.7/library/xml.etree.elementtree.html

"def findall(self, path, namespaces=None):" in the source code:

https://hg.python.org/cpython/file/2.7/Lib/xml/etree/ElementTree.py

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

From deusyss at yahoo.fr  Tue Apr  7 12:18:49 2015
From: deusyss at yahoo.fr (=?iso-8859-1?Q?Galod=E9_Alexandre?=)
Date: Tue, 7 Apr 2015 11:18:49 +0100
Subject: [docs] French traduction permission
Message-ID: <1428401929.2583.YahooMailBasic@web133002.mail.ir2.yahoo.com>

Hi,

I'm a french Python expert, belonging to "Developpez.com" website team. I'm writing to you because i'd like to make a french traduction, host on our website, from your page (https://docs.python.org/3/library/venv.html).

Before to traduct it, i'd like to have your permission. Of course, source will be indicate, as well authors.

Thanks for your attention

Bests regards

Alexandre Galod?

From keith.briggs at bt.com  Wed Apr  8 17:01:02 2015
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Wed, 8 Apr 2015 15:01:02 +0000
Subject: [docs]
	https://docs.python.org/3/library/telnetlib.html#module-telnetlib
Message-ID: <be4f6446fc8f4618a833022d52d25e16@rew09926dag05a.domain1.systemhost.net>

This sentence makes no sense:

Alternatively, the host name and optional port number can be passed to the constructor, to, in which case the connection to the server will be established before the constructor returns.

Should it be:

Alternatively, the host name and optional port number can be passed to the constructor too, in which case the connection to the server will be established before the constructor returns.

?
Keith


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

From mail at timgolden.me.uk  Wed Apr  8 17:54:40 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Wed, 08 Apr 2015 16:54:40 +0100
Subject: [docs]
	https://docs.python.org/3/library/telnetlib.html#module-telnetlib
In-Reply-To: <be4f6446fc8f4618a833022d52d25e16@rew09926dag05a.domain1.systemhost.net>
References: <be4f6446fc8f4618a833022d52d25e16@rew09926dag05a.domain1.systemhost.net>
Message-ID: <55254F40.80806@timgolden.me.uk>

Fixed in 3.4 & default. Thanks.

(Should appear after the next scheduled rebuild).

TJG

On 08/04/2015 16:01, keith.briggs at bt.com wrote:
> This sentence makes no sense:
> 
>  
> 
> Alternatively, the host name and optional port number can be passed to
> the constructor, to, in which case the connection to the server will be
> established before the constructor returns.
> 
>  
> 
> Should it be:
> 
>  
> 
> Alternatively, the host name and optional port number can be passed to
> the constructor too, in which case the connection to the server will be
> established before the constructor returns.
> 
>  
> 
> ?
> 
> Keith
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
> 


From python at discontinuity.net  Wed Apr  8 22:10:32 2015
From: python at discontinuity.net (python at discontinuity.net)
Date: Wed, 08 Apr 2015 20:10:32 -0000
Subject: [docs] SemLock acquire() keyword arg 'blocking' is invalid
	(issue 23484)
Message-ID: <20150408201032.24688.64330@psf.upfronthosting.co.za>

Hi Berker --

Unrelated to this but thanks also for finishing off issue23400 today.


Davin




https://bugs.python.org/review/23484/diff/14347/Doc/library/multiprocessing.rst
File Doc/library/multiprocessing.rst (right):

https://bugs.python.org/review/23484/diff/14347/Doc/library/multiprocessing.rst#newcode1199
Doc/library/multiprocessing.rst:1199: .. versionchanged:: 2.7
Looking back through the prior branches, it turns out the timeout
parameter was introduced in 2.6 (same branch where multiprocessing
itself was introduced) and it is present in 3.0 upwards too. 
Unfortunately I trusted or misinterpreted the docs that suggested
otherwise -- makes your reacting to this an especially good catch.

I think the right thing to do is to remove the versionchanged line
altogether since both 'block' and 'timeout' have been there pretty much
since the beginning.  I'll make that quick change and update the patch
files.

On 2015/04/02 18:00:10, davin wrote:
> On 2015/04/01 17:36:10, berkerpeksag wrote:
> > If the timeout parameter was added in 2.7 and 3.0, we can remove
this
> directive
> > on 3.4 and default branches since it's there for the beginning of
Python 3.
> > 
> > On the other hand, for example, if it was added in 2.7 and 3.2, we
should
> change
> > it to .. versionchanged:: 3.2 in Python 3 documentation.
> 
> Makes sense -- I will double-check when it got added to Python 3 and
make that
> change.
> 
> My thinking was that bringing attention to this, even if it has been
there for a
> while, is a good thing because this is the first time it's been
reflected in the
> documentation.  But if your immediate reaction is that this looks
weird (coming
> from 2.7 or 3.0), then my idea was the wrong way to go.

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

From report at bugs.python.org  Wed Apr  8 22:27:54 2015
From: report at bugs.python.org (Davin Potts)
Date: Wed, 08 Apr 2015 20:27:54 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1428524873.99.0.0969132446405.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

Updating patch for default/3.5 and 3.4 branches to remove versionchanged message on {Lock,RLock}.acquire per feedback from @berker.

----------
Added file: http://bugs.python.org/file38867/issue_23484_doc_locks_py35_and_py34_noverchange.patch

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

From report at bugs.python.org  Wed Apr  8 22:28:24 2015
From: report at bugs.python.org (Davin Potts)
Date: Wed, 08 Apr 2015 20:28:24 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1428524904.75.0.93261819158.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

Same for 2.7 branch.

----------
Added file: http://bugs.python.org/file38868/issue_23484_doc_locks_py27_noverchange.patch

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

From zachary.ware+pydocs at gmail.com  Thu Apr  9 04:22:16 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 8 Apr 2015 21:22:16 -0500
Subject: [docs]
	=?utf-8?q?Pb_de_d=27essai_du_code_=C3=A0_la_section_7=2E2?=
	=?utf-8?q?=2E1_Methods_Of_File_Objects?=
In-Reply-To: <CAK9O0gbh=+3OvGQNmsky1AmxHLKdJhAq+g20=3_gOurQZCZ7rg@mail.gmail.com>
References: <CAK9O0gbh=+3OvGQNmsky1AmxHLKdJhAq+g20=3_gOurQZCZ7rg@mail.gmail.com>
Message-ID: <CAKJDb-Odd+eXMb5OCRBBEa+YFApJVbW1WkNe3i4bSEJD=FH5qQ@mail.gmail.com>

Hi Vincent,

Sorry for the delay in responding.

2015-03-05 13:01 GMT-06:00 Vincent . <gooogleapps33 at gmail.com>:
> Hello,
>
> When I run this code
> f = open('workfile', 'r')
> f.read()
>
> under python interpreter, it operate.
> in a file, it doesn't work
>
> Please, help to fix this bug which be useful for all readers of your docs.

I'm not sure where you found this, as I can't find it in any current
version of the docs.  However, that code does work properly when run
from a file, but as you're just throwing away the return value of
'f.read()', it *looks* like nothing happens (when running that code in
an interactive session, the return value is printed automatically).

Thanks for the report anyway!

Regards,
-- 
Zach

From gooogleapps33 at gmail.com  Thu Apr  9 10:56:16 2015
From: gooogleapps33 at gmail.com (Vincent .)
Date: Thu, 9 Apr 2015 10:56:16 +0200
Subject: [docs]
	=?utf-8?q?Pb_de_d=27essai_du_code_=C3=A0_la_section_7=2E2?=
	=?utf-8?q?=2E1_Methods_Of_File_Objects?=
In-Reply-To: <CAKJDb-Odd+eXMb5OCRBBEa+YFApJVbW1WkNe3i4bSEJD=FH5qQ@mail.gmail.com>
References: <CAK9O0gbh=+3OvGQNmsky1AmxHLKdJhAq+g20=3_gOurQZCZ7rg@mail.gmail.com>
 <CAKJDb-Odd+eXMb5OCRBBEa+YFApJVbW1WkNe3i4bSEJD=FH5qQ@mail.gmail.com>
Message-ID: <CAK9O0gaoq0nb5XEQ5ftBJbJUVdeNFzmcx1r7j5y4qUS+dOAyUw@mail.gmail.com>

Your delay in responding permit me to solve this problem:

If you write in a file:

*        f = open('workfile, 'r')*

*        print(f.read())*

it's work. So, the output fille must always printed to the screen by the
command print() and I forget it[?], by recopying this example.

Today, I fix it and I must wait until to post a little disappointment.

Regards,

Vincent

2015-04-09 4:22 GMT+02:00 Zachary Ware <zachary.ware+pydocs at gmail.com>:

> Hi Vincent,
>
> Sorry for the delay in responding.
>
> 2015-03-05 13:01 GMT-06:00 Vincent . <gooogleapps33 at gmail.com>:
> > Hello,
> >
> > When I run this code
> > f = open('workfile', 'r')
> > f.read()
> >
> > under python interpreter, it operate.
> > in a file, it doesn't work
> >
> > Please, help to fix this bug which be useful for all readers of your
> docs.
>
> I'm not sure where you found this, as I can't find it in any current
> version of the docs.  However, that code does work properly when run
> from a file, but as you're just throwing away the return value of
> 'f.read()', it *looks* like nothing happens (when running that code in
> an interactive session, the return value is printed automatically).
>
> Thanks for the report anyway!
>
> Regards,
> --
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150409/c7c342ef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 362.gif
Type: image/gif
Size: 101 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150409/c7c342ef/attachment-0001.gif>

From report at bugs.python.org  Thu Apr  9 16:59:12 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 09 Apr 2015 14:59:12 +0000
Subject: [docs] [issue19247] Describe surrogateescape algorithm in the
	Library	Reference
In-Reply-To: <1381673577.83.0.634006615694.issue19247@psf.upfronthosting.co.za>
Message-ID: <1428591552.15.0.584964236743.issue19247@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The last round of updates to the codecs module docs covered the relevant details in the new error handlers section: https://docs.python.org/3/library/codecs.html#error-handlers

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

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

From report at bugs.python.org  Thu Apr  9 22:34:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Apr 2015 20:34:20 +0000
Subject: [docs] [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1428611660.99.0.198767724091.issue12160@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Apr 10 13:11:22 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Fri, 10 Apr 2015 11:11:22 +0000
Subject: [docs] [issue23904] pathlib.PurePath does not accept bytes
	components
Message-ID: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za>


New submission from Bruno Cauet:

At https://docs.python.org/3/library/pathlib.html#pure-paths one can read

> Each element of pathsegments can be either a string or bytes object representing a path segment; it can also be another path object:

which is a lie:

>>> pathlib.PurePath(b"/foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/bru/code/cpython/Lib/pathlib.py", line 609, in __new__
    return cls._from_parts(args)
  File "/home/bru/code/cpython/Lib/pathlib.py", line 638, in _from_parts
    drv, root, parts = self._parse_args(args)
  File "/home/bru/code/cpython/Lib/pathlib.py", line 630, in _parse_args
    % type(a))
TypeError: argument should be a path or str object, not <class 'bytes'>

So either
(1) the doc is wrong
(2) PathLib path management fails: it should decode bytes parts with os.fsdecode()
I doubt I tagged both components. I'll be happy to provide a fix once you decide what is the right solution.

I take this opportunity to share an itch: filesystem encoding on Unix cannot be reliably determined. sys.getfilesystemencoding() is only a preference and there is no guarantee that an arbitrary file will respect it. This is extensively discussed in the following thread: https://mail.python.org/pipermail/python-dev/2014-August/135873.html
What is the right way to deal with those? If I use "surrogateescape" (see PEP383) how can I display the fake-unicode path to the user? `print()` does seems to use strict encoding. Should I encode it with "surrogateescape" or "ignore" myself beforehand?

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 240414
nosy: bru, docs at python
priority: normal
severity: normal
status: open
title: pathlib.PurePath does not accept bytes components
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Apr 10 15:19:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Apr 2015 13:19:26 +0000
Subject: [docs] [issue23025] ssl.RAND_bytes docs should mention os.urandom
In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za>
Message-ID: <20150410131917.62497.29940@psf.io>


Roundup Robot added the comment:

New changeset f85ac33b12a1 by Berker Peksag in branch '3.4':
Issue #23025: Add a mention of os.urandom to RAND_bytes and RAND_pseudo_bytes docs.
https://hg.python.org/cpython/rev/f85ac33b12a1

New changeset 7aa42cea8968 by Berker Peksag in branch 'default':
Issue #23025: Add a mention of os.urandom to RAND_bytes and RAND_pseudo_bytes docs.
https://hg.python.org/cpython/rev/7aa42cea8968

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

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

From report at bugs.python.org  Fri Apr 10 15:20:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 10 Apr 2015 13:20:10 +0000
Subject: [docs] [issue23025] ssl.RAND_bytes docs should mention os.urandom
In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za>
Message-ID: <1428672010.53.0.0555950872335.issue23025@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Alex.

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

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

From report at bugs.python.org  Fri Apr 10 20:17:36 2015
From: report at bugs.python.org (Mark Mikofski)
Date: Fri, 10 Apr 2015 18:17:36 +0000
Subject: [docs] [issue23909] highlight query string does not work on
	docs.python.org/2
Message-ID: <1428689856.01.0.985094593971.issue23909@psf.upfronthosting.co.za>


New submission from Mark Mikofski:

expected: using Sphinx search in docs, search keyword is usually highlighted on resulting pages.

observerd: query string ?highligh=<string> does nothing on http://docs.python.org/2 although it actually does work for 2.6 and all 3.x docs. Doesn't appear to be a function of Sphinx version as 3.x docs and 2.7.x docs all use Sphinx-1.2.3

examples:

works: https://docs.python.org/3/tutorial/appetite.html?highlight=indent

does'nt: https://docs.python.org/2/tutorial/appetite.html?highlight=indent

platform: works?
chrome: no
firefox: no

----------
assignee: docs at python
components: Documentation
messages: 240443
nosy: bwanamarko, docs at python
priority: normal
severity: normal
status: open
title: highlight query string does not work on docs.python.org/2
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 11 00:40:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Apr 2015 22:40:33 +0000
Subject: [docs] [issue23909] highlight query string does not work on
	docs.python.org/2
In-Reply-To: <1428689856.01.0.985094593971.issue23909@psf.upfronthosting.co.za>
Message-ID: <20150410224029.62499.80424@psf.io>


Roundup Robot added the comment:

New changeset 89d47911209b by Benjamin Peterson in branch '2.7':
highlight is now highlighted (closes #23909)
https://hg.python.org/cpython/rev/89d47911209b

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

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

From report at bugs.python.org  Sat Apr 11 03:29:03 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 11 Apr 2015 01:29:03 +0000
Subject: [docs] [issue20693] Sidebar scrolls down 2x as fast as page content
In-Reply-To: <1392854470.16.0.730014647108.issue20693@psf.upfronthosting.co.za>
Message-ID: <1428715742.81.0.0692901335912.issue20693@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Is this still a problem?  I haven't noticed it on docs.python.org in quite some time.  Ezio, can you still reproduce?

----------
status: open -> pending

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

From report at bugs.python.org  Sat Apr 11 04:15:46 2015
From: report at bugs.python.org (James Edwards)
Date: Sat, 11 Apr 2015 02:15:46 +0000
Subject: [docs] [issue23912] Inconsistent whitespace/formatting
	in	docs/reference/datamodel/Special Method Lookup
Message-ID: <1428718546.88.0.646269142708.issue23912@psf.upfronthosting.co.za>


New submission from James Edwards:

There's inconsistent leading whitespace between the two classes in the 4th code snippet of the "Special Method Lookup" section.

https://docs.python.org/3/reference/datamodel.html#special-method-lookup

The (very substantial :) included patch makes both classes use consistent leading whitespace, that is PEP-8 conformant.

(This issue also exists in the Python 2 documentation[1], but since other things have changed -- e.g. print statement -> function, metaclass declaration -- the same patch won't apply cleanly.)

[1] https://docs.python.org/2/reference/datamodel.html#special-method-lookup-for-new-style-classes

----------
assignee: docs at python
components: Documentation
files: datamodel.rst.diff
keywords: patch
messages: 240458
nosy: docs at python, jedwards
priority: normal
severity: normal
status: open
title: Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup
versions: Python 3.6
Added file: http://bugs.python.org/file38894/datamodel.rst.diff

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

From report at bugs.python.org  Sat Apr 11 10:04:00 2015
From: report at bugs.python.org (Boyd Blackwell)
Date: Sat, 11 Apr 2015 08:04:00 +0000
Subject: [docs] [issue23913] error in some byte sizes of docs in array module
Message-ID: <1428739439.99.0.273745755962.issue23913@psf.upfronthosting.co.za>


New submission from Boyd Blackwell:

See 8.6. array ? Efficient arrays of numeric values?

I think these two table entries should list 4 instead of 2, at least for 64 python.
The error is currently in 2.710rc0, but also in previous versions.
also in 3.4.3, presumably some previous versions
it might also be argued that the column heading should not but minimum size but simply Element Size (bytes)


'i'	signed int	int	2
'I'	unsigned int	long	2

code:
import array

a = array.array('I')
a.fromstring('\x01\x02\x03\x04')
print(a)
#array('I', [67305985L])  # one element as expected (4 bytes, 4 bytes/elt)

a = array.array('H')
a.fromstring('\x01\x02\x03\x04')
print(a)
#array('H', [513, 1027])  # two elements as expected (4 bytes, 2 bytes/elt)

----------
assignee: docs at python
components: Documentation
files: arraydocbug.py
messages: 240466
nosy: bdb112, docs at python
priority: normal
severity: normal
status: open
title: error in some byte sizes of docs in array module
versions: Python 2.7
Added file: http://bugs.python.org/file38897/arraydocbug.py

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

From report at bugs.python.org  Sat Apr 11 10:31:36 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 11 Apr 2015 08:31:36 +0000
Subject: [docs] [issue23913] error in some byte sizes of docs in array module
In-Reply-To: <1428739439.99.0.273745755962.issue23913@psf.upfronthosting.co.za>
Message-ID: <1428741096.84.0.774163902512.issue23913@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

As noted below the table, the exact size is platform specific, so the current documentation is correct in stating a "minimum size in bytes" of "2" for int.

https://en.wikipedia.org/wiki/C_data_types

IMHO, close as "not a bug" as it works as documented.

----------
nosy: +scoder

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

From report at bugs.python.org  Sat Apr 11 13:59:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Apr 2015 11:59:23 +0000
Subject: [docs] [issue23912] Inconsistent whitespace/formatting
	in	docs/reference/datamodel/Special Method Lookup
In-Reply-To: <1428718546.88.0.646269142708.issue23912@psf.upfronthosting.co.za>
Message-ID: <20150411115919.129684.25098@psf.io>


Roundup Robot added the comment:

New changeset 714b7b684610 by Berker Peksag in branch '3.4':
Issue #23912: Fix code formatting in datamodel.rst.
https://hg.python.org/cpython/rev/714b7b684610

New changeset 5cd072882051 by Berker Peksag in branch 'default':
Issue #23912: Fix code formatting in datamodel.rst.
https://hg.python.org/cpython/rev/5cd072882051

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

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

From report at bugs.python.org  Sat Apr 11 14:00:21 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Apr 2015 12:00:21 +0000
Subject: [docs] [issue23912] Inconsistent whitespace/formatting
	in	docs/reference/datamodel/Special Method Lookup
In-Reply-To: <1428718546.88.0.646269142708.issue23912@psf.upfronthosting.co.za>
Message-ID: <1428753621.8.0.708798454493.issue23912@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the patch, James.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.5 -Python 3.6

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

From report at bugs.python.org  Sat Apr 11 17:13:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Apr 2015 15:13:48 +0000
Subject: [docs] [issue23913] error in some byte sizes of docs in array module
In-Reply-To: <1428739439.99.0.273745755962.issue23913@psf.upfronthosting.co.za>
Message-ID: <1428765228.41.0.171022081003.issue23913@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Apr 12 00:02:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Apr 2015 22:02:08 +0000
Subject: [docs] [issue23904] pathlib.PurePath does not accept bytes
	components
In-Reply-To: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za>
Message-ID: <1428789728.59.0.0145801550908.issue23904@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Interesting. The doc is wrong here: pathlib was designed so that it only accepts text strings.

> If I use "surrogateescape" (see PEP383) how can I display the
> fake-unicode path to the user? `print()` does seems to use strict
> encoding. Should I encode it with "surrogateescape" or "ignore" myself 
> beforehand?

Yes, you should probably encode it yourself. If you are sure your terminal can eat the original bytestring, then use "surrogateescape". Otherwise, "replace" sounds better so that the user knows there are some undecodable characters out there.

----------
nosy: +ncoghlan, pitrou

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

From report at bugs.python.org  Sun Apr 12 00:08:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Apr 2015 22:08:46 +0000
Subject: [docs] [issue23904] pathlib.PurePath does not accept bytes
	components
In-Reply-To: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za>
Message-ID: <20150411220842.8629.49241@psf.io>


Roundup Robot added the comment:

New changeset 7463c06f6e87 by Antoine Pitrou in branch '3.4':
Close #23904: fix pathlib documentation misleadingly mentioning that bytes objects are accepted in the PurePath constructor
https://hg.python.org/cpython/rev/7463c06f6e87

New changeset 386732087dfb by Antoine Pitrou in branch 'default':
Close #23904: fix pathlib documentation misleadingly mentioning that bytes objects are accepted in the PurePath constructor
https://hg.python.org/cpython/rev/386732087dfb

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

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

From report at bugs.python.org  Sun Apr 12 00:09:05 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Apr 2015 22:09:05 +0000
Subject: [docs] [issue23904] pathlib.PurePath does not accept bytes
	components
In-Reply-To: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za>
Message-ID: <1428790145.57.0.336321174438.issue23904@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the report!

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

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

From report at bugs.python.org  Sun Apr 12 02:00:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 12 Apr 2015 00:00:14 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1428796814.1.0.530086647426.issue14050@psf.upfronthosting.co.za>


Martin Panter added the comment:

The first paragraph in the patch already seems to have been applied, for Issue 21575.

The Sorting How-to <https://docs.python.org/dev/howto/sorting.html#odd-and-ends> already guarantees that defining only __lt__() is sufficient for sorted() and list.sort(). And the list.sort() specification <https://docs.python.org/dev/library/stdtypes.html#list.sort> says ?only < comparisons? are used, which implies that only __gt__() may also be sufficient.

It might be good to change ?ordering relationship? to ?total ordering relationship?, but I think further explanation and other details are probably not worth adding to the tutorial. They could be clarified in the main documentation, but that is probably a separate issue.

----------
nosy: +vadmium

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

From vadmium+py at gmail.com  Sun Apr 12 02:46:45 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 12 Apr 2015 00:46:45 -0000
Subject: [docs] Document magic methods called by built-in functions (issue
	10289)
Message-ID: <20150412004645.24688.71260@psf.upfronthosting.co.za>


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

https://bugs.python.org/review/10289/diff/12349/Doc/library/functions.rst#newcode1289
Doc/library/functions.rst:1289: The items in *iterable* need to be
orderable; otherwise, :exc:`TypeError` is
Actually I think they need to be totally orderable, though TypeError
isn?t going to be raised for partially orderable sequences.

https://bugs.python.org/review/10289/diff/12349/Doc/library/functions.rst#newcode1291
Doc/library/functions.rst:1291: by defining :dfn:`rich comparison
methods` like :meth:`__lt__`, described in
Would be good to be more specific. I suspect it is sufficient to define
the < and > operations, by defining at least one of __lt__() and
__gt__(). And I suspect that many other comparison operations, <=, >=,
==, !=, __eq__(), __le__(), etc, are never used. See also the
list.sort() specification.

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

From report at bugs.python.org  Sun Apr 12 02:49:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 12 Apr 2015 00:49:50 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1428799790.45.0.920803795253.issue10289@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sizeof is not relevant to the built-in functions as far as I know. It is already described at <https://docs.python.org/dev/library/sys.html#sys.getsizeof>.

Some more delegations that I think should be documented here (at least for Python 3):

* abs() -> object.__abs__()
* bytes() -> object.__bytes__()
* complex() -> object.__complex__()
* divmod() -> object.__divmod__()
* float() -> object.__float__(). The text is already there, but there is no hyperlink.
* hex() -> object.__index__(). Also just needs a hyperlink.
* isinstance() -> class.__instancecheck__()
* issubclass() -> class.__subclasscheck__()
* pow() -> object.__pow__()
* round() -> object.__round__()

I added some comments about the sorted() specification on Reitveld, but maybe they should be handled in a separate issue, because the delegation is less direct compared to the other functions being considered here. And any update to sorted() should probably also consider list.sort(), min(), max(), and maybe the bisect and heapq modules.

----------
nosy: +vadmium

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

From report at bugs.python.org  Sun Apr 12 06:59:00 2015
From: report at bugs.python.org (James Edwards)
Date: Sun, 12 Apr 2015 04:59:00 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
Message-ID: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>


New submission from James Edwards:

I realize this is a huge patch, I'd be happy to split it to multiple little 
patches (one per file, one per documentation directory, etc.) to make things 
easier.  Just let me know.

The patch attempts to do a few things (with exceptions, as noted below):

    1. Standardize leading whitespace in block bodies (4 spaces per level)
    2. Enforce >= 2 spaces between code and inline comment
    3. In interactive interpreter snippets, ensures lines meant to be entered
        are preceded by '>>> ' or '... '
    4. Inline whitespace standardization (following a liberal / lenient 
        (not strict) PEP-8 testing)

Scanning the documentation, extracting the code snippets, and testing them for
PEP-8 compliance was done with a script, but all adjustments were done by hand.

This means that there remain some code that fails the lenient PEP-8 checks that
I used.  For example, code at [1] ("How to write obfuscated one liners") 
obviously threw errors, but because of the context of the snippet and the use it 
serves in the documentation, it was left it unchanged.

Similarly, there are (intentionally) poorly formatted snippets in [2] ("Lexical
Analysis") that were also left unchanged.

Since these changes were applied by hand, I was able to ignore situations where
things that would normally raise warnings.  I erred on the side of leaving the
documentation examples unchanged, and strived to make only innocuous changes.

I made no attempt to change the functionality or semantics of any of the 
snippets.  The only changes I made were "harmless" formatting.  None of the
changes will affect the function or output of the snippets.

What the changes do, however, is give a consistency to the documentation that
will allow readers to become more comfortable with the structure of the language
and improve readability.

[1] https://docs.python.org/3/faq/programming.html#is-it-possible-to-write-obfuscated-one-liners-in-python
[2] https://docs.python.org/3/reference/lexical_analysis.html#indentation
[3] http://pep8.readthedocs.org/en/latest/intro.html

In addition to the checks that are ignored by default by the pep8[3] module for 
not being unanimously accepted:

    E121    # continuation line under-indented for hanging indent
    E123    # closing bracket does not match indentation of opening bracket?s line
    E126    # continuation line over-indented for hanging indent
    E133    # closing bracket is missing indentation
    E226    # missing whitespace around arithmetic operator
    E241    # multiple spaces after ?,? 
    E242    # tab after ?,?
    E704    # multiple statements on one line (def)

The following checks were "globally" ignored in my script, though many others 
were conditionally ignored by the script or by myself.

    ignore.append('W292')       # no newline at end of file
    ignore.append('E302')       # expected 2 blank lines, found 0
    ignore.append('E401')       # multiple imports on one line
    ignore.append('W391')       # blank line at end of file
    ignore.append('E231')       # missing whitespace after ','
    ignore.append('E114')       # indentation is not multiple of four (comment)
    ignore.append('E116')       # unexpected indentation (comment)
    
While the patch diffstat is:

    67 files changed, 450 insertions(+), 412 deletions(-)

Ignoring all whitespace changes, the diffstat is only:

    10 files changed, 118 insertions(+), 114 deletions(-)

The majority of these remaining changes fix the inconsistency of interactive interpreter snippets, where, within the same snippet, some lines have '>>> ' while others are missing it, or the '... ' continuation prompt.

Let me know if you need anything from me (such as splitting this patch up) to
help get it merged.  Thanks.

----------
assignee: docs at python
components: Documentation
files: docsdiff.diff
keywords: patch
messages: 240540
nosy: docs at python, jedwards
priority: normal
severity: normal
status: open
title: Standardize documentation whitespace, formatting
type: enhancement
Added file: http://bugs.python.org/file38903/docsdiff.diff

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

From report at bugs.python.org  Sun Apr 12 06:59:28 2015
From: report at bugs.python.org (James Edwards)
Date: Sun, 12 Apr 2015 04:59:28 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1428814768.76.0.57104650965.issue23921@psf.upfronthosting.co.za>


Changes by James Edwards <jheiv at jheiv.com>:


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

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

From report at bugs.python.org  Sun Apr 12 07:11:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Apr 2015 05:11:31 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1428815491.06.0.185118320089.issue23921@psf.upfronthosting.co.za>


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


----------
nosy: +r.david.murray, serhiy.storchaka
stage:  -> patch review

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

From report at bugs.python.org  Sun Apr 12 10:31:34 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 12 Apr 2015 08:31:34 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1428827494.11.0.79512024541.issue10289@psf.upfronthosting.co.za>


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


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

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

From berker.peksag at gmail.com  Sun Apr 12 11:17:30 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Sun, 12 Apr 2015 09:17:30 -0000
Subject: [docs] Standardize documentation whitespace,
	formatting (issue 23921)
Message-ID: <20150412091730.19370.32887@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23921/diff/14500/Doc/faq/programming.rst#oldcode1102
Doc/faq/programming.rst:1102: Use the :func:`reversed` built-in
function, which is new in Python 2.4::
I'd drop the "which is new in Python 2.4" part.

http://bugs.python.org/review/23921/diff/14500/Doc/faq/programming.rst#oldcode1110
Doc/faq/programming.rst:1110: With Python 2.3, you can use an extended
slice syntax::
I'd remove this part entirely. Python 2.3 is dead :)

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

http://bugs.python.org/review/23921/diff/14500/Doc/faq/programming.rst#newcode668
Doc/faq/programming.rst:668: >>> print(b)
Thanks for the patch!

If you adding >>> here, you'll also need to add to the whole example.
And print() is redundant here.

    >>> class B: pass
    ... 
    >>> b = B()
    >>> b
    <__main__.B object at 0x7f8273825740>

http://bugs.python.org/review/23921/diff/14500/Doc/faq/programming.rst#newcode1106
Doc/faq/programming.rst:1106: # ... do something with x ...
I'm not fan of ``# do something`` type of comments. We can just print
``x`` here.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/curses.rst#newcode182
Doc/howto/curses.rst:182: (height, width)    = (5, 40)
() is not needed:

    begin_x, begin_y = (20, 7)

is a valid Python code.

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst
File Doc/howto/functional.rst (left):

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst#oldcode397
Doc/howto/functional.rst:397: if not (condition2):
if not condition2:

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst#oldcode399
Doc/howto/functional.rst:399: ...
# ...

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst#newcode401
Doc/howto/functional.rst:401: if not (conditionN):
if not conditionN:

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/regex.rst#newcode1117
Doc/howto/regex.rst:1117: >>> p = re.compile( '(blue|white|red)' )
p = re.compile('(blue|white|red)')

Drop the trailing spaces please.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/webservers.rst#newcode298
Doc/howto/webservers.rst:298: yield
'<tr><th>{0}</th><td>{1}</td></tr>'.format(
{0} and {1} can be written like {}.

http://bugs.python.org/review/23921/diff/14500/Doc/library/collections.abc.rst
File Doc/library/collections.abc.rst (right):

http://bugs.python.org/review/23921/diff/14500/Doc/library/collections.abc.rst#newcode143
Doc/library/collections.abc.rst:143: ''' Alternate set implementation
favoring space over speed
I'd use """ and remove the trailing spaces.

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

http://bugs.python.org/review/23921/diff/14500/Doc/library/subprocess.rst#newcode942
Doc/library/subprocess.rst:942: # ==>
Perhaps ``# becomes`` or something like that would be better here.

http://bugs.python.org/review/23921/diff/14500/Doc/reference/simple_stmts.rst
File Doc/reference/simple_stmts.rst (right):

http://bugs.python.org/review/23921/diff/14500/Doc/reference/simple_stmts.rst#newcode334
Doc/reference/simple_stmts.rst:334: if not expression: raise
AssertionError
if not expression:
    raise AssertionError

http://bugs.python.org/review/23921/diff/14500/Doc/reference/simple_stmts.rst#newcode339
Doc/reference/simple_stmts.rst:339: if not expression1: raise
AssertionError(expression2)
if not expression1:
    raise AssertionError(expression2)

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

From report at bugs.python.org  Sun Apr 12 11:23:18 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 12 Apr 2015 09:23:18 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1428830598.53.0.493927491563.issue23921@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Patch looks good to me. Thanks! :)

I left a couple of comments on Rietveld: http://bugs.python.org/review/23921/

We can probably ignore the following type of changes too:

-      if pid == 0: # In a child process
+      if pid == 0:  # In a child process

-          status = '200 OK' # HTTP Status
-          headers = [('Content-type', 'text/plain')] # HTTP Headers
+          status = '200 OK'  # HTTP Status
+          headers = [('Content-type', 'text/plain')]  # HTTP Headers

-   dom1 = parse('c:\\temp\\mydata.xml') # parse an XML file by name
+   dom1 = parse('c:\\temp\\mydata.xml')  # parse an XML file by name

Also, perhaps we can add your script to Tools/scripts and integrate it with the "make patchcheck" command.

----------
nosy: +berker.peksag
versions: +Python 3.4, Python 3.5 -Python 3.6

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

From report at bugs.python.org  Sun Apr 12 12:53:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 12 Apr 2015 10:53:00 +0000
Subject: [docs] [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <20150412105257.113191.85074@psf.io>


Roundup Robot added the comment:

New changeset 6d5336a193cc by Berker Peksag in branch '3.4':
Issue #12955: Change the urlopen() examples to use context managers where appropriate.
https://hg.python.org/cpython/rev/6d5336a193cc

New changeset 08adaaf08697 by Berker Peksag in branch 'default':
Issue #12955: Change the urlopen() examples to use context managers where appropriate.
https://hg.python.org/cpython/rev/08adaaf08697

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

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

From report at bugs.python.org  Sun Apr 12 12:54:41 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 12 Apr 2015 10:54:41 +0000
Subject: [docs] [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1428836081.47.0.169975603059.issue12955@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Great patch. Thanks Martin.

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

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

From abhityagi85 at gmail.com  Sun Apr 12 15:08:09 2015
From: abhityagi85 at gmail.com (Abhinav Tyagi)
Date: Sun, 12 Apr 2015 18:38:09 +0530
Subject: [docs] docs@ InfiniteLoop in example on website
Message-ID: <CAFOpQqt2+EwjJ+fZt1WTb4hcSES98mbMYFMrnJerTBB_eFRxuQ@mail.gmail.com>

Following example in Section 4.2 would run into infinite loop.

https://docs.python.org/2/tutorial/controlflow.html#for-statements

>>> for w in words[:]:  # Loop over a slice copy of the entire list....     if len(w) > 6:...         words.insert(0, w)...>>> words['defenestrate', 'cat', 'window', 'defenestrate']


Should be something like this (but still leaves duplicate elements in the
list):
-----------------------------------
words_tmp = copy.deepcopy(words)
for w in words_tmp:
    if len(w)>6 :
            words.insert(0,w)
-----------------------------------


Thanks & Regards
Abhinav Tyagi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150412/e0ead62c/attachment.html>

From mail at timgolden.me.uk  Sun Apr 12 15:17:58 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 12 Apr 2015 14:17:58 +0100
Subject: [docs] docs@ InfiniteLoop in example on website
In-Reply-To: <CAFOpQqt2+EwjJ+fZt1WTb4hcSES98mbMYFMrnJerTBB_eFRxuQ@mail.gmail.com>
References: <CAFOpQqt2+EwjJ+fZt1WTb4hcSES98mbMYFMrnJerTBB_eFRxuQ@mail.gmail.com>
Message-ID: <552A7086.8040204@timgolden.me.uk>

On 12/04/2015 14:08, Abhinav Tyagi wrote:
> Following example in Section 4.2 would run into infinite loop.
>
> https://docs.python.org/2/tutorial/controlflow.html#for-statements
>
>>>>for  w  in  words[:]:   # Loop over a slice copy of the entire list.
> ...     if  len(w)  >  6:
> ...         words.insert(0,  w)
> ...
>>>>words
> ['defenestrate', 'cat', 'window', 'defenestrate']

Except that it doesn't. You seem to have missed the entire point of that 
particular example, which is that [:] makes a copy of the list, so 
mutating the original list will not affect the loop.

Did you actually try it in an interpreter?

TJG


From abhityagi85 at gmail.com  Sun Apr 12 15:15:15 2015
From: abhityagi85 at gmail.com (Abhinav Tyagi)
Date: Sun, 12 Apr 2015 18:45:15 +0530
Subject: [docs] docs@ InfiniteLoop in example on website
In-Reply-To: <CAFOpQqt2+EwjJ+fZt1WTb4hcSES98mbMYFMrnJerTBB_eFRxuQ@mail.gmail.com>
References: <CAFOpQqt2+EwjJ+fZt1WTb4hcSES98mbMYFMrnJerTBB_eFRxuQ@mail.gmail.com>
Message-ID: <CAFOpQqs73YP4fw8hsOdgt8TqGJFr+YakzuFhLZ-Q40ebSMshuQ@mail.gmail.com>

Sorry for the inconvinience. I realised that the example is correct.

Thanks & Regards
Abhinav Tyagi


On 12 April 2015 at 18:38, Abhinav Tyagi <abhityagi85 at gmail.com> wrote:

> Following example in Section 4.2 would run into infinite loop.
>
> https://docs.python.org/2/tutorial/controlflow.html#for-statements
>
> >>> for w in words[:]:  # Loop over a slice copy of the entire list....     if len(w) > 6:...         words.insert(0, w)...>>> words['defenestrate', 'cat', 'window', 'defenestrate']
>
>
> Should be something like this (but still leaves duplicate elements in the
> list):
> -----------------------------------
> words_tmp = copy.deepcopy(words)
> for w in words_tmp:
>     if len(w)>6 :
>             words.insert(0,w)
> -----------------------------------
>
>
> Thanks & Regards
> Abhinav Tyagi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150412/e0042182/attachment.html>

From report at bugs.python.org  Sun Apr 12 16:17:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Apr 2015 14:17:06 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1428848226.29.0.0612512341354.issue23921@psf.upfronthosting.co.za>


R. David Murray added the comment:

I will have comments on this, but it may be a bit before I get to it.  In general I'm not sure of the value, though in the little bit I scanned so far there are at least a few changes that look worthwhile.

----------

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

From jheiv at jheiv.com  Sun Apr 12 19:55:06 2015
From: jheiv at jheiv.com (jheiv at jheiv.com)
Date: Sun, 12 Apr 2015 17:55:06 -0000
Subject: [docs] Standardize documentation whitespace,
	formatting (issue 23921)
Message-ID: <20150412175506.8668.78893@psf.upfronthosting.co.za>

Reviewers: berkerpeksag,


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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/curses.rst#newcode182
Doc/howto/curses.rst:182: (height, width)    = (5, 40)
On 2015/04/12 11:17:30, berkerpeksag wrote:
> () is not needed:
> 
>     begin_x, begin_y = (20, 7)
> 
> is a valid Python code.

This was the most substantiate change I made in the patch -- I believe
it was the only place where I violated my rule of "whitespace only". 

I wrapped the LHS in parens in an attempt to make it more
new-user-friendly.

I originally has what you wrote:

a, b = (c, d)

But, after looking at it, I was afraid that new users would get this
confused with 

a = b = (c, d)

This concern may not be founded of course, but just explaining the
thought process behind the change.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/regex.rst#newcode1117
Doc/howto/regex.rst:1117: >>> p = re.compile( '(blue|white|red)' )
On 2015/04/12 11:17:30, berkerpeksag wrote:
> p = re.compile('(blue|white|red)')
> 
> Drop the trailing spaces please.

I agree, the reason for keeping it like this ( <- with spaces -> ) is
only because the author originally had a leading space before the
arguments and no trailing space after.

I tried to change as little as possible, so instead of removing the
leading space, I added a trailing space for balance.

But I agree that there should be neither.

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

http://bugs.python.org/review/23921/diff/14500/Doc/library/subprocess.rst#newcode942
Doc/library/subprocess.rst:942: # ==>
On 2015/04/12 11:17:30, berkerpeksag wrote:
> Perhaps ``# becomes`` or something like that would be better here.

The `# becomes` style is actually used earlier in the document:

https://docs.python.org/3/library/subprocess.html#replacing-bin-sh-shell-backquote

I'm not sure why it changes part way through either.

http://bugs.python.org/review/23921/diff/14500/Doc/reference/simple_stmts.rst
File Doc/reference/simple_stmts.rst (right):

http://bugs.python.org/review/23921/diff/14500/Doc/reference/simple_stmts.rst#newcode334
Doc/reference/simple_stmts.rst:334: if not expression: raise
AssertionError
On 2015/04/12 11:17:30, berkerpeksag wrote:
> if not expression:
>     raise AssertionError

Yes, this would be the most compliant, and I can change this.

Because of the many lines of code in the docs that contain what I called
"trival blocks" in-line with conditions, I had to start conditionally
ignoring them.

if <cond>: <trivial block>

Ended up getting ignored, provided that <trivial block> was exactly
"pass", "continue", "break", or (less trivially) started with "print" or
"raise".



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

Affected files:
  Doc/distutils/apiref.rst
  Doc/faq/design.rst
  Doc/faq/library.rst
  Doc/faq/programming.rst
  Doc/howto/curses.rst
  Doc/howto/descriptor.rst
  Doc/howto/functional.rst
  Doc/howto/logging-cookbook.rst
  Doc/howto/logging.rst
  Doc/howto/regex.rst
  Doc/howto/unicode.rst
  Doc/howto/urllib2.rst
  Doc/howto/webservers.rst
  Doc/library/abc.rst
  Doc/library/argparse.rst
  Doc/library/asynchat.rst
  Doc/library/asyncio-sync.rst
  Doc/library/asyncore.rst
  Doc/library/audioop.rst
  Doc/library/collections.abc.rst
  Doc/library/collections.rst
  Doc/library/concurrent.futures.rst
  Doc/library/configparser.rst
  Doc/library/contextlib.rst
  Doc/library/crypt.rst
  Doc/library/ctypes.rst
  Doc/library/email.headerregistry.rst
  Doc/library/getopt.rst
  Doc/library/html.parser.rst
  Doc/library/http.client.rst
  Doc/library/inspect.rst
  Doc/library/ipaddress.rst
  Doc/library/locale.rst
  Doc/library/mailcap.rst
  Doc/library/mmap.rst
  Doc/library/multiprocessing.rst
  Doc/library/optparse.rst
  Doc/library/re.rst
  Doc/library/shelve.rst
  Doc/library/ssl.rst
  Doc/library/string.rst
  Doc/library/subprocess.rst
  Doc/library/threading.rst
  Doc/library/tkinter.rst
  Doc/library/tokenize.rst
  Doc/library/types.rst
  Doc/library/unittest.rst
  Doc/library/urllib.request.rst
  Doc/library/wsgiref.rst
  Doc/library/xml.dom.minidom.rst
  Doc/library/xml.etree.elementtree.rst
  Doc/library/xmlrpc.client.rst
  Doc/reference/datamodel.rst
  Doc/reference/expressions.rst
  Doc/reference/simple_stmts.rst
  Doc/tutorial/appendix.rst
  Doc/tutorial/classes.rst
  Doc/tutorial/controlflow.rst
  Doc/tutorial/errors.rst
  Doc/tutorial/inputoutput.rst
  Doc/tutorial/introduction.rst
  Doc/tutorial/modules.rst
  Doc/tutorial/stdlib.rst
  Doc/tutorial/stdlib2.rst
  Doc/whatsnew/3.2.rst
  Doc/whatsnew/3.3.rst
  Doc/whatsnew/3.4.rst



From report at bugs.python.org  Mon Apr 13 02:56:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Apr 2015 00:56:36 +0000
Subject: [docs] [issue23915] traceback set with
	BaseException.with_traceback()	overwritten on raise
In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za>
Message-ID: <1428886596.38.0.360553029404.issue23915@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, a doc note would be a good idea, I think.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution: not a bug -> 
status: closed -> open
versions:  -Python 3.2, Python 3.3, Python 3.6

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

From report at bugs.python.org  Mon Apr 13 03:12:14 2015
From: report at bugs.python.org (James Powell)
Date: Mon, 13 Apr 2015 01:12:14 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <1428887534.01.0.00635951761102.issue17380@psf.upfronthosting.co.za>


Changes by James Powell <james at dontusethiscode.com>:


----------
nosy: +james

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

From report at bugs.python.org  Mon Apr 13 03:14:00 2015
From: report at bugs.python.org (James Powell)
Date: Mon, 13 Apr 2015 01:14:00 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <1428887640.21.0.461375148349.issue17380@psf.upfronthosting.co.za>


James Powell added the comment:

See attached patch to clarify this in the docs.

----------
keywords: +patch
Added file: http://bugs.python.org/file38910/issue_17380.patch

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

From report at bugs.python.org  Mon Apr 13 03:18:09 2015
From: report at bugs.python.org (James Powell)
Date: Mon, 13 Apr 2015 01:18:09 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <1428887889.82.0.386491360574.issue17380@psf.upfronthosting.co.za>


Changes by James Powell <james at dontusethiscode.com>:


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

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

From report at bugs.python.org  Mon Apr 13 03:54:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Apr 2015 01:54:08 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <20150413015405.21087.39645@psf.io>


Roundup Robot added the comment:

New changeset c6dc1e0db7f0 by R David Murray in branch '3.4':
#17380: Document tp_init return value in extending docs.
https://hg.python.org/cpython/rev/c6dc1e0db7f0

New changeset d74ede4bbf81 by R David Murray in branch 'default':
Merge: #17380: Document tp_init return value in extending docs.
https://hg.python.org/cpython/rev/d74ede4bbf81

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

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

From report at bugs.python.org  Mon Apr 13 03:55:19 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Apr 2015 01:55:19 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <1428890119.11.0.518933910616.issue17380@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, James.

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

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

From abhityagi85 at gmail.com  Mon Apr 13 07:07:39 2015
From: abhityagi85 at gmail.com (Abhinav Tyagi)
Date: Mon, 13 Apr 2015 10:37:39 +0530
Subject: [docs] docs@ InfiniteLoop in example on website
In-Reply-To: <552A7086.8040204@timgolden.me.uk>
References: <CAFOpQqt2+EwjJ+fZt1WTb4hcSES98mbMYFMrnJerTBB_eFRxuQ@mail.gmail.com>
 <552A7086.8040204@timgolden.me.uk>
Message-ID: <CAFOpQqtOG1FmgEuJJ--a3_0WqYgCQQn0zNp6z72GC9XfQoyxPQ@mail.gmail.com>

Just after I wrote the email, I realised I made a mistake and within few
minutes I replied to my email that example was fine.
On 12-Apr-2015 6:48 pm, "Tim Golden" <mail at timgolden.me.uk> wrote:

> On 12/04/2015 14:08, Abhinav Tyagi wrote:
>
>> Following example in Section 4.2 would run into infinite loop.
>>
>> https://docs.python.org/2/tutorial/controlflow.html#for-statements
>>
>>  for  w  in  words[:]:   # Loop over a slice copy of the entire list.
>>>>>
>>>> ...     if  len(w)  >  6:
>> ...         words.insert(0,  w)
>> ...
>>
>>> words
>>>>>
>>>> ['defenestrate', 'cat', 'window', 'defenestrate']
>>
>
> Except that it doesn't. You seem to have missed the entire point of that
> particular example, which is that [:] makes a copy of the list, so mutating
> the original list will not affect the loop.
>
> Did you actually try it in an interpreter?
>
> TJG
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150413/cec3ca0d/attachment.html>

From report at bugs.python.org  Mon Apr 13 09:17:28 2015
From: report at bugs.python.org (Jeffrey Walton)
Date: Mon, 13 Apr 2015 07:17:28 +0000
Subject: [docs] [issue23928] SSL wiki page, host name matching, CN and SAN
Message-ID: <1428909448.45.0.483164672396.issue23928@psf.upfronthosting.co.za>


New submission from Jeffrey Walton:

The Python wiki page on SSL states (https://wiki.python.org/moin/SSL):

    To validate that a certificate matches requested site,
    you need to check commonName field in the subject of
    the certificate.

I don't think its quite correct.

Both the IETF and the CA/B Forums deprecated the use of a hostname or IP address in the commonName (CN). All hostnames and IP addresses must be listed in the subjectAlternateName (SAN), and that's where to look for them.

Though deprecated, placing a name in the CN is not forbidden. In fact, RFC 6125 states the CN should be used as a "last resort" in Section 6.4.4:

    Therefore, if and only if the presented identifiers
    do not include a DNS-ID, SRV-ID, URI-ID, or any
    application-specific identifier types supported by
    the client, then the client MAY as a last resort check
    for a string whose form matches that of a fully
    qualified DNS domain name in a Common Name field of
    the subject field (i.e., a CN-ID). 

Following the advice on the wiki might lead to a Type II error, where an otherwise good certificate is rejected. Its not as bad as accepting a bad certificate, though (by omitting the hostname matching checks).

The IETF deprecated the practice of placing a name in the CN in RFC 6125, Section 6.4.4. The CA/Browser Forum deprecated a DNS name in the CN in Baseline Requirements (BR) Section 9.2.2 Subject Common Name Field.

----------
assignee: docs at python
components: Documentation
messages: 240590
nosy: Jeffrey.Walton, docs at python
priority: normal
severity: normal
status: open
title: SSL wiki page, host name matching, CN and SAN
type: enhancement

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

From report at bugs.python.org  Mon Apr 13 09:30:11 2015
From: report at bugs.python.org (Philippe)
Date: Mon, 13 Apr 2015 07:30:11 +0000
Subject: [docs] [issue23929] Minor typo (way vs. away) in os.renames
	docstring
Message-ID: <1428910211.95.0.877861303749.issue23929@psf.upfronthosting.co.za>


New submission from Philippe:

There is a minor typo in the docstring of os.renames:

See https://hg.python.org/cpython/file/37905786b34b/Lib/os.py#l275

"After the rename, directories corresponding to rightmost path segments of the old name will be pruned way until [..]"

This should be using away instead of way:

"After the rename, directories corresponding to rightmost path segments of the old name will be pruned away until [..]"

----------
assignee: docs at python
components: Documentation
messages: 240595
nosy: docs at python, pombreda
priority: normal
severity: normal
status: open
title: Minor typo (way vs. away) in os.renames docstring
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/issue23929>
_______________________________________

From report at bugs.python.org  Mon Apr 13 11:09:05 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Apr 2015 09:09:05 +0000
Subject: [docs] [issue23929] Minor typo (way vs. away) in os.renames
	docstring
In-Reply-To: <1428910211.95.0.877861303749.issue23929@psf.upfronthosting.co.za>
Message-ID: <1428916145.37.0.0753805724713.issue23929@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think removing the word "way" would be a better improvement.

----------
nosy: +eric.smith
versions:  -Python 3.2, Python 3.3, Python 3.6

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

From report at bugs.python.org  Mon Apr 13 11:09:21 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Apr 2015 09:09:21 +0000
Subject: [docs] [issue23929] Minor typo (way vs. away) in os.renames
	docstring
In-Reply-To: <1428910211.95.0.877861303749.issue23929@psf.upfronthosting.co.za>
Message-ID: <1428916161.54.0.93555545896.issue23929@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +easy

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

From report at bugs.python.org  Mon Apr 13 13:21:22 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Apr 2015 11:21:22 +0000
Subject: [docs] [issue23928] SSL wiki page, host name matching, CN and SAN
In-Reply-To: <1428909448.45.0.483164672396.issue23928@psf.upfronthosting.co.za>
Message-ID: <1428924082.31.0.626909815751.issue23928@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the report; your remarks are obviously true. Unfortunately, the wiki is community-maintained, there's not much point in reporting bugs here about it. That page's contents look very outdated, by the way.

The official documentation for the ssl module is here:
https://docs.python.org/3/library/ssl.html

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

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

From report at bugs.python.org  Mon Apr 13 13:31:51 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Apr 2015 11:31:51 +0000
Subject: [docs] [issue23928] SSL wiki page, host name matching, CN and SAN
In-Reply-To: <1428909448.45.0.483164672396.issue23928@psf.upfronthosting.co.za>
Message-ID: <1428924711.53.0.155241062825.issue23928@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm closing this issue since it isn't part of our responsibilites here, sorry.
If you want to see that wiki page fixed, the best is probably to... fix it yourself :-) (it's a wiki after all)

(frankly, I think it should be removed or replaced with a pair of links to the official ssl module and the pyOpenSSL docs)

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From tronster at fastmail.us  Mon Apr 13 13:49:56 2015
From: tronster at fastmail.us (Tronster)
Date: Mon, 13 Apr 2015 07:49:56 -0400
Subject: [docs] Bug - 4.7.7
Message-ID: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>

For someone learning Python, the sample itself doesn't make sense.


https://docs.python.org/3/tutorial/controlflow.html <https://docs.python.org/3/tutorial/controlflow.html>
4.7.7 Function Annotations

Typed in program in PyCharm and received the following:

>>> def f(ham:42, eggs:int='spam') ->"Nothing to see here":
...     print("Annotations:", f.__annotations__)
...     print("Arguements:", ham,eggs)
...     
  File "<input>", line 1
    def f(ham:42, eggs:int='spam') ->"Nothing to see here":
             ^
SyntaxError: invalid syntax



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

From mail at timgolden.me.uk  Mon Apr 13 14:26:39 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 13 Apr 2015 13:26:39 +0100
Subject: [docs] Bug - 4.7.7
In-Reply-To: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
References: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
Message-ID: <552BB5FF.6060408@timgolden.me.uk>

On 13/04/2015 12:49, Tronster wrote:
> For someone learning Python, the sample itself doesn't make sense.

Thanks for taking the trouble to point this out. However, you don't seem
clear on whether it doesn't make sense (ie it won't be understood) or
whether it fails to compile -- as your traceback below suggests.

It certainly does compile correctly under Python 3.4, the version for
which those docs are current, so it's possible that your PyCharm
interpreter window is running some earlier version.

As to whether it makes sense: you'll have to explain better what aspect
of it doesn't make sense.


> 
> 
> https://docs.python.org/3/tutorial/controlflow.html
> 4.7.7 Function Annotations
> 
> Typed in program in PyCharm and received the following:
> 
>>>> def f(ham:42, eggs:int='spam') ->"Nothing to see here":
> ...     print("Annotations:", f.__annotations__)
> ...     print("Arguements:", ham,eggs)
> ...     
>   File "<input>", line 1
>     def f(ham:42, eggs:int='spam') ->"Nothing to see here":
>              ^
> SyntaxError: invalid syntax


TJG

From mail at timgolden.me.uk  Mon Apr 13 14:55:30 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 13 Apr 2015 13:55:30 +0100
Subject: [docs] Bug - 4.7.7
In-Reply-To: <1FB6857B-BC90-4C25-AB28-3A4AB70A9F3F@fastmail.us>
References: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
 <552BB5FF.6060408@timgolden.me.uk>
 <1FB6857B-BC90-4C25-AB28-3A4AB70A9F3F@fastmail.us>
Message-ID: <552BBCC2.2040707@timgolden.me.uk>

[Keeping the conversation cc-ed to docs@ for the benefit of the other
docs admins]

On 13/04/2015 13:36, Tronster wrote:
> Hi Tim, thanks for the quick reply.
> 
> These language overview documents are great; some of the cleanest and
> clearest I've read for any language.

Thanks; nice of you to say so.


> The compiling looks like it's due to PyCharm using Python 2.6; thank you
> for mentioning this works under 3.4 ... I'll be looking into getting on
> that version (right now just using the default PyCharm install.)

Excellent.

> 
> As for making sense... I just don't understand why a string is passed to
> an integer, unless that's the point; that Python isn't strongly typed
> and that even though something is labeled an 'int' a string can be
> passed.  If that is the case; there is a lot of things happening in that
> example; perhaps break it out (e.g., single argument function, showing
> how the type is override.)

Ok; now I understand your concerns rather better. I agree that the
example is cramming rather a lot in. In particular, the unexplained
"eggs: int = 'spam'" param is highlighting the complete optionality of
the annotation. In this example, the annotation looks as if it might
well be used for some sort of parameter validation or optimisation. But
in current versions of Python, none of the built-in functionality makes
any use of it.

It would be perfectly valid to have an annotation which was a max/min
value pair, or a longer explanation of the parameter's meaning, or a
GUID which could be used to represent it to some remote system. Or anything.

Unless one of the other docs maintainers has a view, I'll dig a little
into that particular section to see who set it up in the first place
before I wade in to make changes, but I agree that it is probably too
confusing for a tutorial.

TJG

> 
> Cheers.
> 
> 
> Tronster
> http://tronster.com
> 410-299-6348



From zachary.ware at gmail.com  Mon Apr 13 15:04:16 2015
From: zachary.ware at gmail.com (Zachary Ware)
Date: Mon, 13 Apr 2015 08:04:16 -0500
Subject: [docs] Bug - 4.7.7
In-Reply-To: <552BBCC2.2040707@timgolden.me.uk>
References: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
 <552BB5FF.6060408@timgolden.me.uk>
 <1FB6857B-BC90-4C25-AB28-3A4AB70A9F3F@fastmail.us>
 <552BBCC2.2040707@timgolden.me.uk>
Message-ID: <CAKJDb-Osny4h1iweUaLnW4KPJ+3JhCJnYfFXihmDTwNhyM-BAw@mail.gmail.com>

On Apr 13, 2015 8:55 AM, "Tim Golden" <mail at timgolden.me.uk> wrote:
> Unless one of the other docs maintainers has a view, I'll dig a little
> into that particular section to see who set it up in the first place
> before I wade in to make changes, but I agree that it is probably too
> confusing for a tutorial.

I'm the original author. That section does need an update, especially in
light of PEP 484.

--
Zach

Posted from a phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150413/3e31f05e/attachment.html>

From mail at timgolden.me.uk  Mon Apr 13 15:08:58 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 13 Apr 2015 14:08:58 +0100
Subject: [docs] Bug - 4.7.7
In-Reply-To: <CAKJDb-Osny4h1iweUaLnW4KPJ+3JhCJnYfFXihmDTwNhyM-BAw@mail.gmail.com>
References: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
 <552BB5FF.6060408@timgolden.me.uk>
 <1FB6857B-BC90-4C25-AB28-3A4AB70A9F3F@fastmail.us>
 <552BBCC2.2040707@timgolden.me.uk>
 <CAKJDb-Osny4h1iweUaLnW4KPJ+3JhCJnYfFXihmDTwNhyM-BAw@mail.gmail.com>
Message-ID: <552BBFEA.8030302@timgolden.me.uk>

On 13/04/2015 14:04, Zachary Ware wrote:
> On Apr 13, 2015 8:55 AM, "Tim Golden" <mail at timgolden.me.uk
> <mailto:mail at timgolden.me.uk>> wrote:
>> Unless one of the other docs maintainers has a view, I'll dig a little
>> into that particular section to see who set it up in the first place
>> before I wade in to make changes, but I agree that it is probably too
>> confusing for a tutorial.
> 
> I'm the original author. That section does need an update, especially in
> light of PEP 484.

(Just deleted the draft email I was about to send you!)

Good point re PEP 484 [for the OP: Guido van Rossum's proposal to have
built-in type hinting make use of function annotations:
https://www.python.org/dev/peps/pep-0484/].

I'd probably expect the initial patch to include an update to the
tutorial, so probably best leave as it is for now?

TJG

From zachary.ware at gmail.com  Mon Apr 13 15:31:02 2015
From: zachary.ware at gmail.com (Zachary Ware)
Date: Mon, 13 Apr 2015 08:31:02 -0500
Subject: [docs] Bug - 4.7.7
In-Reply-To: <552BBFEA.8030302@timgolden.me.uk>
References: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
 <552BB5FF.6060408@timgolden.me.uk>
 <1FB6857B-BC90-4C25-AB28-3A4AB70A9F3F@fastmail.us>
 <552BBCC2.2040707@timgolden.me.uk>
 <CAKJDb-Osny4h1iweUaLnW4KPJ+3JhCJnYfFXihmDTwNhyM-BAw@mail.gmail.com>
 <552BBFEA.8030302@timgolden.me.uk>
Message-ID: <CAKJDb-PvdZubbPPeytvEgwddgs8-zoqQmt_hEcLcNL26aRjxMQ@mail.gmail.com>

On Mon, Apr 13, 2015 at 8:08 AM, Tim Golden <mail at timgolden.me.uk> wrote:
> (Just deleted the draft email I was about to send you!)

Good timing on my part? :)

> Good point re PEP 484 [for the OP: Guido van Rossum's proposal to have
> built-in type hinting make use of function annotations:
> https://www.python.org/dev/peps/pep-0484/].
>
> I'd probably expect the initial patch to include an update to the
> tutorial, so probably best leave as it is for now?

It should also be changed in 3.4, though.  I'll open an issue for it
and add see if somebody wants to fix it at the sprints today.

-- 
Zach

From report at bugs.python.org  Mon Apr 13 15:39:54 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 13 Apr 2015 13:39:54 +0000
Subject: [docs] [issue23932] Tutorial section on function annotations is out
	of date	re: PEP 484
Message-ID: <1428932394.25.0.74013439586.issue23932@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Brought up by 'Tronster' on docs@)

https://docs.python.org/3/tutorial/controlflow.html#function-annotations

In light of the PEP 484 and its clear intentions for function annotations, the tutorial section on function annotations is out of date.  It should be updated to be clear that function annotations are intended for type hints, and that other uses are no longer encouraged.  The example should also use some built-in types in a manner consistent with PEP 484.

----------
assignee: docs at python
components: Documentation
messages: 240606
nosy: docs at python, gvanrossum, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Tutorial section on function annotations is out of date re: PEP 484
versions: Python 3.4, Python 3.5

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

From zachary.ware at gmail.com  Mon Apr 13 15:40:54 2015
From: zachary.ware at gmail.com (Zachary Ware)
Date: Mon, 13 Apr 2015 08:40:54 -0500
Subject: [docs] Bug - 4.7.7
In-Reply-To: <CAKJDb-PvdZubbPPeytvEgwddgs8-zoqQmt_hEcLcNL26aRjxMQ@mail.gmail.com>
References: <A0C143C6-9BD3-4F14-870E-BEF03CF3B717@fastmail.us>
 <552BB5FF.6060408@timgolden.me.uk>
 <1FB6857B-BC90-4C25-AB28-3A4AB70A9F3F@fastmail.us>
 <552BBCC2.2040707@timgolden.me.uk>
 <CAKJDb-Osny4h1iweUaLnW4KPJ+3JhCJnYfFXihmDTwNhyM-BAw@mail.gmail.com>
 <552BBFEA.8030302@timgolden.me.uk>
 <CAKJDb-PvdZubbPPeytvEgwddgs8-zoqQmt_hEcLcNL26aRjxMQ@mail.gmail.com>
Message-ID: <CAKJDb-MGgQ4RXySW5o_EKA7rg1q6BsYQpKNpHL=08EZU-2eOig@mail.gmail.com>

On Mon, Apr 13, 2015 at 8:31 AM, Zachary Ware <zachary.ware at gmail.com> wrote:
> It should also be changed in 3.4, though.  I'll open an issue for it
> and add see if somebody wants to fix it at the sprints today.

http://bugs.python.org/issue23932

-- 
Zach

From report at bugs.python.org  Mon Apr 13 16:33:55 2015
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Mon, 13 Apr 2015 14:33:55 +0000
Subject: [docs] [issue21108] Add examples for importlib in doc
In-Reply-To: <1396240944.13.0.279884654032.issue21108@psf.upfronthosting.co.za>
Message-ID: <1428935635.53.0.495414542959.issue21108@psf.upfronthosting.co.za>


Changes by Ra?l Cumplido <raulcumplido at gmail.com>:


----------
nosy: +raulcd

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

From report at bugs.python.org  Mon Apr 13 16:35:19 2015
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Mon, 13 Apr 2015 14:35:19 +0000
Subject: [docs] [issue23915] traceback set with
	BaseException.with_traceback()	overwritten on raise
In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za>
Message-ID: <1428935719.54.0.0052976453571.issue23915@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

I've had a very hard time adding to the doc in a way that elucidates rather than further obfuscating; see if you like this patch.

----------
keywords: +patch
nosy: +emptysquare
Added file: http://bugs.python.org/file38916/issue23915.patch

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

From report at bugs.python.org  Mon Apr 13 16:56:14 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 13 Apr 2015 14:56:14 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1428936974.13.0.806444172272.issue13850@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Just updated this patch with "x" instead of the unicode character.

----------
nosy: +matrixise
Added file: http://bugs.python.org/file38917/argparse-actions-matrix-v2

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

From report at bugs.python.org  Mon Apr 13 17:07:58 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 13 Apr 2015 15:07:58 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1428936974.13.0.806444172272.issue13850@psf.upfronthosting.co.za>
Message-ID: <3ED6AA51-5BD3-4339-96F7-60E7665F99E4@wirtel.be>


St?phane Wirtel added the comment:

On 13 Apr 2015, at 10:56, St?phane Wirtel wrote:

> St?phane Wirtel added the comment:
>
> Just updated this patch with "x" instead of the unicode character.

Sorry bad patch, I have read the last comment (?replace by x or 
?yes/no?) and not the other comments.

----------

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

From report at bugs.python.org  Mon Apr 13 17:30:14 2015
From: report at bugs.python.org (Juti Noppornpitak)
Date: Mon, 13 Apr 2015 15:30:14 +0000
Subject: [docs] [issue23932] Tutorial section on function annotations is out
	of date	re: PEP 484
In-Reply-To: <1428932394.25.0.74013439586.issue23932@psf.upfronthosting.co.za>
Message-ID: <1428939014.13.0.0321152854594.issue23932@psf.upfronthosting.co.za>


Juti Noppornpitak added the comment:

I reworded to mention the coming changes regarding to PEP 484. The old writing which mention about arbitariness is moved to the end of the "function annotations" section as a warning.

----------
keywords: +patch
nosy: +shiroyuki
Added file: http://bugs.python.org/file38920/issue23932.r1.patch

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

From zachary.ware at gmail.com  Mon Apr 13 17:41:36 2015
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Mon, 13 Apr 2015 15:41:36 -0000
Subject: [docs] Tutorial section on function annotations is out of date re:
 PEP 484 (issue 23932)
Message-ID: <20150413154136.13954.82322@psf.upfronthosting.co.za>

Reviewers: ,


http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst
File Doc/tutorial/controlflow.rst (right):

http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst#newcode678
Doc/tutorial/controlflow.rst:678: Python will use annotations as type
hints for static analyzer and overloading
Python itself won't use them, though; we're leaving that up to
third-party type-checking tools (for now and the foreseeable future).

http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst#newcode690
Doc/tutorial/controlflow.rst:690: >>> def f(a: str, b: str = 'bar') ->
str:
Can come up with a better example keeping with something referring to
the Flying Circus? Foo and bar are boring and this is Python :)

http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst#newcode700
Doc/tutorial/controlflow.rst:700: .. warning::
I think this can just be left out, really.  Since this is in the
tutorial, we don't need to go into all of the nitty-gritty details, just
show the syntax and give a link to more information (the PEP link).



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

Affected files:
  Doc/tutorial/controlflow.rst


diff -r 37905786b34b Doc/tutorial/controlflow.rst
--- a/Doc/tutorial/controlflow.rst	Sun Apr 12 23:24:17 2015 -0500
+++ b/Doc/tutorial/controlflow.rst	Mon Apr 13 11:25:56 2015 -0400
@@ -673,11 +673,10 @@
    pair: function; annotations
    single: -> (return annotation assignment)
 
-:ref:`Function annotations <function>` are completely optional,
-arbitrary metadata information about user-defined functions.  Neither Python
-itself nor the standard library use function annotations in any way; this
-section just shows the syntax. Third-party projects are free to use function
-annotations for documentation, type checking, and other uses.
+:ref:`Function annotations <function>` are completely optional metadata
+information about user-defined functions. If the annotations are provided,
+Python will use annotations as type hints for static analyzer and overloading
+methods (:pep:`484`).
 
 Annotations are stored in the :attr:`__annotations__` attribute of the function
 as a dictionary and have no effect on any other part of the function.  Parameter
@@ -688,14 +687,23 @@
 following example has a positional argument, a keyword argument, and the return
 value annotated with nonsense::
 
-   >>> def f(ham: 42, eggs: int = 'spam') -> "Nothing to see here":
+   >>> def f(a: str, b: str = 'bar') -> str:
    ...     print("Annotations:", f.__annotations__)
-   ...     print("Arguments:", ham, eggs)
+   ...     print("Arguments:", a, b)
+   ...     return a + b
    ...
-   >>> f('wonderful')
-   Annotations: {'eggs': <class 'int'>, 'return': 'Nothing to see here', 'ham': 42}
-   Arguments: wonderful spam
+   >>> f('sample')
+   Annotations: {'a': <class 'str'>, 'return': <class 'str'>, 'b': <class 'str'>}
+   Arguments: sample bar
+   'samplebar'
 
+.. warning::
+
+   In Python 3.0-3.5, :ref:`function annotations <function>` are still completely
+   optional, arbitrary metadata information about user-defined functions.
+   Neither Python itself nor the standard library use function annotations in
+   any way; this section just shows the syntax. Third-party projects are free to
+   use function annotations for documentation, type checking, and other uses.
 
 .. _tut-codingstyle:
 



From report at bugs.python.org  Mon Apr 13 17:43:50 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 13 Apr 2015 15:43:50 +0000
Subject: [docs] [issue23932] Tutorial section on function annotations is out
	of date	re: PEP 484
In-Reply-To: <1428932394.25.0.74013439586.issue23932@psf.upfronthosting.co.za>
Message-ID: <1428939830.28.0.751467320831.issue23932@psf.upfronthosting.co.za>


Zachary Ware added the comment:

@Juti: Thanks for the patch!  I've left a review on Rietveld, which should have sent you an email (or you can get to it through the 'review' link).

----------

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

From report at bugs.python.org  Mon Apr 13 18:00:42 2015
From: report at bugs.python.org (Juti Noppornpitak)
Date: Mon, 13 Apr 2015 16:00:42 +0000
Subject: [docs] [issue23932] Tutorial section on function annotations is out
	of date	re: PEP 484
In-Reply-To: <1428932394.25.0.74013439586.issue23932@psf.upfronthosting.co.za>
Message-ID: <1428940842.64.0.755625067989.issue23932@psf.upfronthosting.co.za>


Juti Noppornpitak added the comment:

Based on the review

----------
Added file: http://bugs.python.org/file38923/issue23932.r2.patch

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

From report at bugs.python.org  Mon Apr 13 18:03:06 2015
From: report at bugs.python.org (Jeffrey Walton)
Date: Mon, 13 Apr 2015 16:03:06 +0000
Subject: [docs] [issue23928] SSL wiki page, host name matching, CN and SAN
In-Reply-To: <1428909448.45.0.483164672396.issue23928@psf.upfronthosting.co.za>
Message-ID: <1428940986.71.0.275663689457.issue23928@psf.upfronthosting.co.za>


Jeffrey Walton added the comment:

> there's not much point in reporting bugs here about it.

Oh, sorry about that.

> That page's contents look very outdated, by the way.

Yeah, there's a few opportunities for improvement.

----------

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

From report at bugs.python.org  Mon Apr 13 18:32:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Apr 2015 16:32:27 +0000
Subject: [docs] [issue23932] Tutorial section on function annotations is out
	of date	re: PEP 484
In-Reply-To: <1428932394.25.0.74013439586.issue23932@psf.upfronthosting.co.za>
Message-ID: <20150413163224.113211.64724@psf.io>


Roundup Robot added the comment:

New changeset 0acb8dcb8e0c by Zachary Ware in branch '3.4':
Issue #23932: Update the tutorial section on function annotations.
https://hg.python.org/cpython/rev/0acb8dcb8e0c

New changeset 75a6774ba070 by Zachary Ware in branch 'default':
Closes #23932: Merge with 3.4
https://hg.python.org/cpython/rev/75a6774ba070

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

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

From report at bugs.python.org  Mon Apr 13 18:33:03 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 13 Apr 2015 16:33:03 +0000
Subject: [docs] [issue23932] Tutorial section on function annotations is out
	of date	re: PEP 484
In-Reply-To: <1428932394.25.0.74013439586.issue23932@psf.upfronthosting.co.za>
Message-ID: <1428942783.21.0.305174271661.issue23932@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Cleaned it up just a little bit and committed.  Thanks for the patch, Juti!

----------

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

From report at bugs.python.org  Mon Apr 13 19:18:03 2015
From: report at bugs.python.org (Saul Shanabrook)
Date: Mon, 13 Apr 2015 17:18:03 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428945483.37.0.669866018164.issue23864@psf.upfronthosting.co.za>


Saul Shanabrook added the comment:

I have added a failing test to based on the first example, of a class that provides the necessary methods, but fails to be an instance of Sequence.

----------
keywords: +patch
nosy: +saulshanabrook
Added file: http://bugs.python.org/file38935/patch.diff

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

From report at bugs.python.org  Mon Apr 13 19:22:55 2015
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Mon, 13 Apr 2015 17:22:55 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
	instead of	find_spec
Message-ID: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>


New submission from Ra?l Cumplido:

While taking a look on the import mechanisms I've seen in the documentation that find_module has been deprecated for find_spec, but on different parts of the documentation there are still references to find_module, as in the definition of sys.meta_path (https://docs.python.org/3/library/sys.html#sys.meta_path).

Shouldn't it be (example on this case) a list of finder objects that have their find_spec() methods called, instead of find_module method?

I've been taking a look on _bootstrap.py and I can see we call find_spec:

for finder in sys.meta_path:
    with _ImportLockContext():
        try:
            find_spec = finder.find_spec

If you agree with me that this is wrong I'll submit a patch to fix it.

----------
assignee: docs at python
components: Documentation
messages: 240671
nosy: brett.cannon, docs at python, eric.snow, raulcd
priority: normal
severity: normal
status: open
title: Wrong references to deprecated find_module instead of find_spec
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 13 19:24:51 2015
From: report at bugs.python.org (Saul Shanabrook)
Date: Mon, 13 Apr 2015 17:24:51 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428945891.68.0.195290716675.issue23864@psf.upfronthosting.co.za>


Changes by Saul Shanabrook <s.shanabrook at gmail.com>:


Removed file: http://bugs.python.org/file38935/patch.diff

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

From report at bugs.python.org  Mon Apr 13 19:26:35 2015
From: report at bugs.python.org (Saul Shanabrook)
Date: Mon, 13 Apr 2015 17:26:35 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428945995.55.0.530667822396.issue23864@psf.upfronthosting.co.za>


Changes by Saul Shanabrook <s.shanabrook at gmail.com>:


Added file: http://bugs.python.org/file38937/patch.diff

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

From report at bugs.python.org  Mon Apr 13 19:27:51 2015
From: report at bugs.python.org (Saul Shanabrook)
Date: Mon, 13 Apr 2015 17:27:51 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428946071.24.0.072829932093.issue23864@psf.upfronthosting.co.za>


Changes by Saul Shanabrook <s.shanabrook at gmail.com>:


Removed file: http://bugs.python.org/file38937/patch.diff

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

From report at bugs.python.org  Mon Apr 13 19:27:58 2015
From: report at bugs.python.org (Saul Shanabrook)
Date: Mon, 13 Apr 2015 17:27:58 +0000
Subject: [docs] [issue23864] issubclass without registration only works
	for	"one-trick pony" collections ABCs.
In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za>
Message-ID: <1428946078.24.0.694334209704.issue23864@psf.upfronthosting.co.za>


Changes by Saul Shanabrook <s.shanabrook at gmail.com>:


Added file: http://bugs.python.org/file38938/patch.diff

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

From report at bugs.python.org  Mon Apr 13 19:51:21 2015
From: report at bugs.python.org (Pam McA'Nulty)
Date: Mon, 13 Apr 2015 17:51:21 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1428947481.34.0.580794971274.issue22812@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

Remove quotes from quoted patterns only on windows systems (since if the quotes get parsed into the pattern field on a non-windows system, one should respect the user's command line efforts).

Test uses unittest.mock.patch to test "windows" path.

----------
keywords: +patch
nosy: +Pam.McANulty
Added file: http://bugs.python.org/file38939/cpython-22812-discovery-quotes-v1.patch

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

From report at bugs.python.org  Mon Apr 13 19:58:47 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 13 Apr 2015 17:58:47 +0000
Subject: [docs] [issue23730] Document return value for ZipFile.extract()
In-Reply-To: <1426929089.45.0.62065226759.issue23730@psf.upfronthosting.co.za>
Message-ID: <1428947927.46.0.842799387847.issue23730@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

fix for the documentation of ZipFile.extract.

In the code of _extract_member, there is a normalisation of the target path, I use this term "normalized" for the fix.

----------
keywords: +patch
nosy: +matrixise
Added file: http://bugs.python.org/file38943/issue23730.diff

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

From berker.peksag at gmail.com  Mon Apr 13 20:04:09 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Mon, 13 Apr 2015 18:04:09 -0000
Subject: [docs] Tutorial section on function annotations is out of date
 re: PEP 484 (issue 23932)
Message-ID: <20150413180409.30575.86396@psf.upfronthosting.co.za>


http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst
File Doc/tutorial/controlflow.rst (right):

http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst#newcode679
Doc/tutorial/controlflow.rst:679: methods (:pep:`484`).
It would be better to move the PEP 484 link into a seealso directive.

http://bugs.python.org/review/23932/diff/14513/Doc/tutorial/controlflow.rst#newcode690
Doc/tutorial/controlflow.rst:690: >>> def f(a: str, b: str = 'bar') ->
str:
On 2015/04/13 17:41:36, Zach Ware wrote:
> Can come up with a better example keeping with something referring to
the Flying
> Circus? Foo and bar are boring and this is Python :)

Agreed. spam, ham and eggs examples were fine in my opinion :)

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

From report at bugs.python.org  Mon Apr 13 22:25:16 2015
From: report at bugs.python.org (Alex Walters)
Date: Mon, 13 Apr 2015 20:25:16 +0000
Subject: [docs] [issue23938] Deprecation of windows xp support missing from
	whats new
In-Reply-To: <1428955714.97.0.53855207407.issue23938@psf.upfronthosting.co.za>
Message-ID: <1428956716.61.0.282721213144.issue23938@psf.upfronthosting.co.za>


Changes by Alex Walters <tritium-list at sdamon.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

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

From report at bugs.python.org  Mon Apr 13 22:26:38 2015
From: report at bugs.python.org (Aidan Lowe)
Date: Mon, 13 Apr 2015 20:26:38 +0000
Subject: [docs] [issue13814] Document why generators don't support the
	context	management protocol
In-Reply-To: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za>
Message-ID: <1428956798.69.0.683354062806.issue13814@psf.upfronthosting.co.za>


Changes by Aidan Lowe <megadude42 at gmail.com>:


----------
keywords: +patch
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file38955/design.patch

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

From report at bugs.python.org  Mon Apr 13 22:52:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Apr 2015 20:52:35 +0000
Subject: [docs] [issue23938] Deprecation of windows xp support missing from
	whats new
In-Reply-To: <1428955714.97.0.53855207407.issue23938@psf.upfronthosting.co.za>
Message-ID: <20150413205231.66515.19766@psf.io>


Roundup Robot added the comment:

New changeset 24f2c0279120 by Zachary Ware in branch 'default':
Closes #23938: List Windows XP as an unsupported platform.
https://hg.python.org/cpython/rev/24f2c0279120

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

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

From report at bugs.python.org  Mon Apr 13 22:52:53 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 13 Apr 2015 20:52:53 +0000
Subject: [docs] [issue23938] Deprecation of windows xp support missing from
	whats new
In-Reply-To: <1428955714.97.0.53855207407.issue23938@psf.upfronthosting.co.za>
Message-ID: <1428958373.21.0.173078189077.issue23938@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the patch!

----------
nosy: +zach.ware

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

From report at bugs.python.org  Mon Apr 13 23:07:23 2015
From: report at bugs.python.org (Tina Zhang)
Date: Mon, 13 Apr 2015 21:07:23 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1428959243.31.0.312004718894.issue13850@psf.upfronthosting.co.za>


Tina Zhang added the comment:

Created Quick Reference table subsection under the add_argument() method section - used the table originally created by xmorel, replacing ticks with 'x' and adding links to the sections in the documentation for each parameter names.  Removed the 'version' column and row as that wasn't adding much info.  

There is also a link to the quick reference subsection at the top of the page.

----------
keywords: +patch
nosy: +ttz
Added file: http://bugs.python.org/file38966/patch13850v0.patch

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

From report at bugs.python.org  Mon Apr 13 23:44:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Apr 2015 21:44:17 +0000
Subject: [docs] [issue23730] Document return value for ZipFile.extract()
In-Reply-To: <1426929089.45.0.62065226759.issue23730@psf.upfronthosting.co.za>
Message-ID: <20150413214414.46668.35579@psf.io>


Roundup Robot added the comment:

New changeset 731e366885f5 by Zachary Ware in branch '2.7':
Issue #23730: Document the return value of ZipFile.extract
https://hg.python.org/cpython/rev/731e366885f5

New changeset 7ac1c2307a70 by Zachary Ware in branch '3.4':
Issue #23730: Document the return value of ZipFile.extract
https://hg.python.org/cpython/rev/7ac1c2307a70

New changeset d958c74ddb0c by Zachary Ware in branch 'default':
Closes #23730: merge with 3.4
https://hg.python.org/cpython/rev/d958c74ddb0c

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

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

From report at bugs.python.org  Mon Apr 13 23:46:02 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 13 Apr 2015 21:46:02 +0000
Subject: [docs] [issue23730] Document return value for ZipFile.extract()
In-Reply-To: <1426929089.45.0.62065226759.issue23730@psf.upfronthosting.co.za>
Message-ID: <1428961562.17.0.742407341965.issue23730@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the patch!

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

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

From report at bugs.python.org  Tue Apr 14 02:25:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 00:25:21 +0000
Subject: [docs] [issue23929] Minor typo (way vs. away) in os.renames
	docstring
In-Reply-To: <1428910211.95.0.877861303749.issue23929@psf.upfronthosting.co.za>
Message-ID: <20150414002515.96143.36331@psf.io>


Roundup Robot added the comment:

New changeset 94c3cd410cf6 by Benjamin Peterson in branch '3.4':
remove useless word (closes #23929)
https://hg.python.org/cpython/rev/94c3cd410cf6

New changeset feb0717c1004 by Benjamin Peterson in branch '2.7':
remove useless word (closes #23929)
https://hg.python.org/cpython/rev/feb0717c1004

New changeset 4f90751edb4f by Benjamin Peterson in branch 'default':
merge 3.4 (#23929)
https://hg.python.org/cpython/rev/4f90751edb4f

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

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

From report at bugs.python.org  Tue Apr 14 02:38:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Apr 2015 00:38:48 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1428971927.9.0.853853217419.issue13850@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it would be better to move the summary table to the end (just before the Action section), and add another link to the summary to the sentence "The following sections describe how each of these are used."  That is, follow that sentence with something like 'a summary table of the relevance of each paramter to the various possible actions is given at the end of the section', with a link on summary table.

Otherwise, the patch looks good to me.

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

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

From report at bugs.python.org  Tue Apr 14 02:41:04 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 14 Apr 2015 00:41:04 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1428971927.9.0.853853217419.issue13850@psf.upfronthosting.co.za>
Message-ID: <6DE3F01A-5889-4ECB-A6FD-80C738863B18@wirtel.be>


St?phane Wirtel added the comment:

Hi all,

If you think the patch is ok, please merge it, we will close this issue.

Thanks

----------

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

From report at bugs.python.org  Tue Apr 14 02:54:29 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Apr 2015 00:54:29 +0000
Subject: [docs] [issue13814] Document why generators don't support the
	context	management protocol
In-Reply-To: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za>
Message-ID: <1428972869.66.0.519491582019.issue13814@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks like the right approach, I hadn't thought of the design FAQ, but it makes sense as a place to put it.  I made a couple of review comments.

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

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

From report at bugs.python.org  Tue Apr 14 03:39:37 2015
From: report at bugs.python.org (Piotr Kasprzyk)
Date: Tue, 14 Apr 2015 01:39:37 +0000
Subject: [docs] [issue23943] Misspellings in a few files
Message-ID: <1428975576.21.0.663921788116.issue23943@psf.upfronthosting.co.za>


New submission from Piotr Kasprzyk:

Correct misspellings in various files.

----------
assignee: docs at python
components: Documentation
files: misspellings.patch
keywords: patch
messages: 240825
nosy: docs at python, kwadrat
priority: normal
severity: normal
status: open
title: Misspellings in a few files
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38977/misspellings.patch

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

From report at bugs.python.org  Tue Apr 14 03:40:25 2015
From: report at bugs.python.org (James Edwards)
Date: Tue, 14 Apr 2015 01:40:25 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1428975625.18.0.334557730599.issue23921@psf.upfronthosting.co.za>


James Edwards added the comment:

Thanks Berker, I responded to most of your comments in rietveld.

A few of your comments suggested "we should get rid of X", and while I can't say I disagree, I really tried to limit the scope of the changes to whitespace and formatting.

As far as the script goes, it still requires significant human interaction.

Of the 1983 code snippets it extracts[1], 346 still raise warnings and require human verification.  The majority of these snippets aren't actually intended to be Python code.  Some of the snippets are C code, others are optparse/argparse command line examples, configparser config files, or just sections where the author wanted to use a literal block in the documentation.[2]

Of course, when the script triggers on one of these blocks, I ignore it.

Eventually, my goal was to have the script also verify interactive code blocks, much like doctest, but I thought a good intermediary step was to unify the whitespace.

As for the value, I understand the concern one might have before embarking on the process of standardizing the whitespace and formatting -- but given that it's mostly done and comes neatly packaged in a patch, I'm not sure I understand any remaining concerns.  In other words, if it's not something you would spend time on personally, because you have better ways to contribute/ spend your time, I absolutely understand that.  But given that the majority of the leg work is done by the patch, I hope you'll consider merging the changes.

In general the goal was to make the snippets, especially in the tutorial-type sections consistent, to allow the reader to become comfortable with the language instead of being distracted by varied formatting and to facilitate readability.  I hope this explains the motivation behind the effort.

[1] Some files were ignored from future runs after the snippets were validated, because they contained too many false positives, e.g. ctypes.rst.  So this count doesn't reflect the blocks in those ignored files.

[2] I wonder if explicitly indicating which rst literal blocks are intended to be python code would be of some benefit.  For example, adding such a tag could trigger the automatic formatting checks and, for interactive blocks, run the automatic doctest-type verification I was envisioning.  I may think more about the feasibility of this and bring it to python-ideas/python-dev.

----------

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

From zachary.ware at gmail.com  Tue Apr 14 03:54:53 2015
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Tue, 14 Apr 2015 01:54:53 -0000
Subject: [docs] Documentation of unittest -p usage wrong on windows. (issue
	22812)
Message-ID: <20150414015453.345.76816@psf.upfronthosting.co.za>


https://bugs.python.org/review/22812/diff/14527/Lib/unittest/main.py
File Lib/unittest/main.py (right):

https://bugs.python.org/review/22812/diff/14527/Lib/unittest/main.py#newcode233
Lib/unittest/main.py:233: self.pattern[0]==self.pattern[-1]:
Just a style nit, it's best to avoid backslashes wherever you can.  Here
you can do so by wrapping the whole condition in parentheses.

Also, the indentation of the continuation line looks wrong to me, but
I'm honestly not sure what "right" should be.  I seem to think PEP8 says
to indent an extra level from what the suite should be, but I haven't
looked it up again.

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

From report at bugs.python.org  Tue Apr 14 03:55:25 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Apr 2015 01:55:25 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1428976525.85.0.193987671221.issue22812@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I left a comment on Rietveld.  Also, the test doesn't pass on Windows:

test test_unittest failed -- Traceback (most recent call last):
  File "C:\Data\code\CPython\hg.python.org\devinabox\cpython\lib\unittest\test\t
est_discovery.py", line 677, in test_command_line_handling_do_discovery_calls_lo
ader
    self.assertEqual(Loader.args, [('.', "'test*.py'", None)])
AssertionError: Lists differ: [('.', 'test*.py', None)] != [('.', "'test*.py'",
None)]

First differing element 0:
('.', 'test*.py', None)
('.', "'test*.py'", None)

- [('.', 'test*.py', None)]
+ [('.', "'test*.py'", None)]
?        +          +

----------
nosy: +zach.ware

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

From report at bugs.python.org  Tue Apr 14 03:59:25 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Apr 2015 01:59:25 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1428976765.86.0.268049564041.issue22812@psf.upfronthosting.co.za>


Zachary Ware added the comment:

As an aside: Pam, I got a bounce notice from the email that Rietveld tried to send you.  It claims that your email account is disabled, though I suspect that might be it's way of saying it thinks Rietveld is spam (since it tries to send in the reviewer's name).

----------

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

From report at bugs.python.org  Tue Apr 14 08:36:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 06:36:07 +0000
Subject: [docs] [issue23943] Misspellings in a few files
In-Reply-To: <1428975576.21.0.663921788116.issue23943@psf.upfronthosting.co.za>
Message-ID: <20150414063604.21291.71002@psf.io>


Roundup Robot added the comment:

New changeset 9f2bd9939d4b by Berker Peksag in branch '3.4':
Issue #23943: Fix typos. Patch by Piotr Kasprzyk.
https://hg.python.org/cpython/rev/9f2bd9939d4b

New changeset 4fb2075952a4 by Berker Peksag in branch 'default':
Issue #23943: Fix typos. Patch by Piotr Kasprzyk.
https://hg.python.org/cpython/rev/4fb2075952a4

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

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

From report at bugs.python.org  Tue Apr 14 08:38:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 14 Apr 2015 06:38:05 +0000
Subject: [docs] [issue23943] Misspellings in a few files
In-Reply-To: <1428975576.21.0.663921788116.issue23943@psf.upfronthosting.co.za>
Message-ID: <1428993485.14.0.411771767142.issue23943@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Piotr.

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

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

From rdmurray at bitdance.com  Tue Apr 14 02:53:26 2015
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Tue, 14 Apr 2015 00:53:26 -0000
Subject: [docs] Document why generators don't support the context management
 protocol (issue 13814)
Message-ID: <20150414005326.8299.98907@psf.upfronthosting.co.za>

Also, please wrap the text at 79 columns.


http://bugs.python.org/review/13814/diff/14541/Doc/faq/design.rst
File Doc/faq/design.rst (right):

http://bugs.python.org/review/13814/diff/14541/Doc/faq/design.rst#newcode834
Doc/faq/design.rst:834: (denoting that __exit__() is missing from your
generator). If you are using a generator in
I think you meant "If the generator object directly supported the
context manager protocol (ie: it had an __exit__ method), then..." (and
then you need to change the tense of the rest of the sentence).

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

From report at bugs.python.org  Tue Apr 14 12:53:12 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 14 Apr 2015 10:53:12 +0000
Subject: [docs] [issue12652] Keep test.support docs out of the global docs
	index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1429008792.5.0.429786081338.issue12652@psf.upfronthosting.co.za>


Carol Willing added the comment:

Reviewed the issue history during the PyCon sprints. Thanks to all for the thoughts on this issue. I am closing this issue since any additional actions on this subject would be best filed as a new issue.

----------
nosy: +willingc
resolution:  -> out of date
status: open -> closed

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

From storchaka at gmail.com  Tue Apr 14 15:35:46 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Tue, 14 Apr 2015 13:35:46 -0000
Subject: [docs] Standardize documentation whitespace,
	formatting (issue 23921)
Message-ID: <20150414133546.8299.76531@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23921/diff/14500/Doc/faq/design.rst#newcode161
Doc/faq/design.rst:161: # ... do something with line
No need to swap ... and #. It is better to follow common style in
examples and "...  #" has advantages over "# ...".

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

http://bugs.python.org/review/23921/diff/14500/Doc/faq/library.rst#newcode260
Doc/faq/library.rst:260: for i in range(n):
Trailing space.

http://bugs.python.org/review/23921/diff/14500/Doc/faq/library.rst#newcode277
Doc/faq/library.rst:277: for i in range(n):
Trailing space.

http://bugs.python.org/review/23921/diff/14500/Doc/faq/library.rst#newcode747
Doc/faq/library.rst:747: 
Trailing spaces.

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

http://bugs.python.org/review/23921/diff/14500/Doc/faq/programming.rst#newcode1106
Doc/faq/programming.rst:1106: # ... do something with x ...
Previous code was syntactically correct, new code is not
(IndentationError: expected an indented block), because a comment is not
a statement.

http://bugs.python.org/review/23921/diff/14500/Doc/faq/programming.rst#newcode1114
Doc/faq/programming.rst:1114: # ... do something with x ...
Same as above.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/curses.rst#newcode182
Doc/howto/curses.rst:182: (height, width)    = (5, 40)
On 2015/04/12 19:55:06, jedwards wrote:
> On 2015/04/12 11:17:30, berkerpeksag wrote:
> > () is not needed:
> > 
> >     begin_x, begin_y = (20, 7)
> > 
> > is a valid Python code.
> 
> This was the most substantiate change I made in the patch -- I believe
it was
> the only place where I violated my rule of "whitespace only". 
> 
> I wrapped the LHS in parens in an attempt to make it more
new-user-friendly.
> 
> I originally has what you wrote:
> 
> a, b = (c, d)
> 
> But, after looking at it, I was afraid that new users would get this
confused
> with 
> 
> a = b = (c, d)
> 
> This concern may not be founded of course, but just explaining the
thought
> process behind the change.

I prefer more clean

    a, b = c, d

if multitarget assignment is used. This is one of nicer features of
Python and no one Python user should be confused by it.

But in this case it may be better to left original code with multiple
assignments. At least let don't change this in this patch.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/descriptor.rst#newcode380
Doc/howto/descriptor.rst:380: return self.f
Same as above.

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst
File Doc/howto/functional.rst (left):

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst#oldcode397
Doc/howto/functional.rst:397: if not (condition2):
On 2015/04/12 11:17:30, berkerpeksag wrote:
> if not condition2:

I think it is implied that condition2 is not a bare variable, but an
expression with operations that have lesser priority than "not". E.g.
"expr2 is None or expr2 < expr1". Parenthesis are required in such case.

Current code LGTM.

http://bugs.python.org/review/23921/diff/14500/Doc/howto/functional.rst#oldcode399
Doc/howto/functional.rst:399: ...
On 2015/04/12 11:17:30, berkerpeksag wrote:
> # ...

It is better to follow uniform style in all examples: "...  #". But an
empty comment is useless, so bare "..." looks good.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/logging-cookbook.rst#newcode713
Doc/howto/logging-cookbook.rst:713: if record is None:     # We send
this as a sentinel to tell the listener to quit.
This line already is too long, and additional spaces make it even
longer. This violates PEP 8. I would left this code (and other long
lines) as is. You can open new issue for long lines in examples.

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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/regex.rst#newcode1117
Doc/howto/regex.rst:1117: >>> p = re.compile( '(blue|white|red)' )
On 2015/04/12 19:55:06, jedwards wrote:
> On 2015/04/12 11:17:30, berkerpeksag wrote:
> > p = re.compile('(blue|white|red)')
> > 
> > Drop the trailing spaces please.
> 
> I agree, the reason for keeping it like this ( <- with spaces -> ) is
only
> because the author originally had a leading space before the arguments
and no
> trailing space after.
> 
> I tried to change as little as possible, so instead of removing the
leading
> space, I added a trailing space for balance.
> 
> But I agree that there should be neither.

I agree with Berker. We should remove spaces after "(" instead of adding
them before ")".

http://bugs.python.org/review/23921/diff/14500/Doc/library/html.parser.rst
File Doc/library/html.parser.rst (right):

http://bugs.python.org/review/23921/diff/14500/Doc/library/html.parser.rst#newcode294
Doc/library/html.parser.rst:294: 
Trailing spaces.

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

http://bugs.python.org/review/23921/diff/14500/Doc/library/subprocess.rst#newcode942
Doc/library/subprocess.rst:942: # ==>
On 2015/04/12 19:55:06, jedwards wrote:
> On 2015/04/12 11:17:30, berkerpeksag wrote:
> > Perhaps ``# becomes`` or something like that would be better here.
> 
> The `# becomes` style is actually used earlier in the document:
> 
>
https://docs.python.org/3/library/subprocess.html#replacing-bin-sh-shell-backquote
> 
> I'm not sure why it changes part way through either.

Actually the first line even can not be Python 3 code (as the use of
`...` syntax above). May be these examples should be written as two
different code blocks with non-block message "becomes" or "==>" between
them.

Changes in this file can be non-trivial, so it would better to open a
separate issue for them and exclude this file from this patch.

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

http://bugs.python.org/review/23921/diff/14500/Doc/whatsnew/3.2.rst#newcode215
Doc/whatsnew/3.2.rst:215: ...     conf = json.load(f)
I think this example (and other examples in this file) needs an empty
line after the block (i.e. the line with only the "..." prompt).

http://bugs.python.org/review/23921/diff/14500/Doc/whatsnew/3.2.rst#newcode1137
Doc/whatsnew/3.2.rst:1137: 
Trailing spaces.

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

From report at bugs.python.org  Tue Apr 14 15:45:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Apr 2015 13:45:41 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1429019141.32.0.107939514488.issue23921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch mostly LGTM. Most changes are trivial, but the patch also fixes few bugs. It is nice that the patch adds empty lines after blocks, this makes copying the code to interactive interpreter easier. I left comments on Rietveld.

The most questionable changes are adding spaces before comments. But these changes are simple and can slightly increase readability.

----------

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

From report at bugs.python.org  Tue Apr 14 15:51:10 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 14 Apr 2015 13:51:10 +0000
Subject: [docs] [issue19121] Documentation guidelines enhancements
In-Reply-To: <1380446758.24.0.414615784712.issue19121@psf.upfronthosting.co.za>
Message-ID: <1429019470.31.0.91084592034.issue19121@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks to all for the feedback. Since this issue covers a sufficiently broad set of thoughts, it would be better suited for a PEP. Closing this issue with the recommendation to submit a PEP if interested.

----------
nosy: +willingc
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Apr 14 15:53:31 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 14 Apr 2015 13:53:31 +0000
Subject: [docs] [issue12652] Keep test.support docs out of the global docs
	index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1429019611.95.0.189848845986.issue12652@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Apr 14 16:01:52 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 14 Apr 2015 14:01:52 +0000
Subject: [docs] [issue19121] Documentation guidelines enhancements
In-Reply-To: <1380446758.24.0.414615784712.issue19121@psf.upfronthosting.co.za>
Message-ID: <1429020112.39.0.946869765323.issue19121@psf.upfronthosting.co.za>


Changes by Carol Willing <willingc at willingconsulting.com>:


----------
stage:  -> resolved

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

From report at bugs.python.org  Tue Apr 14 16:11:52 2015
From: report at bugs.python.org (Piotr Kasprzyk)
Date: Tue, 14 Apr 2015 14:11:52 +0000
Subject: [docs] [issue23943] Misspellings in a few files
In-Reply-To: <1428975576.21.0.663921788116.issue23943@psf.upfronthosting.co.za>
Message-ID: <1429020712.56.0.167883548395.issue23943@psf.upfronthosting.co.za>


Piotr Kasprzyk added the comment:

Thank you for accepting the patch!

----------

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

From zachary.ware at gmail.com  Tue Apr 14 16:20:49 2015
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Tue, 14 Apr 2015 14:20:49 -0000
Subject: [docs] Documentation of unittest -p usage wrong on windows.
	(issue 22812)
Message-ID: <20150414142049.8299.89248@psf.upfronthosting.co.za>


http://bugs.python.org/review/22812/diff/14527/Lib/unittest/main.py
File Lib/unittest/main.py (right):

http://bugs.python.org/review/22812/diff/14527/Lib/unittest/main.py#newcode231
Lib/unittest/main.py:231: QUOTE_CHARS = '\'"'
I don't think we should worry about ".  To get " into an argument on
Windows you need to either put in a lot of effort to make sense of the
quoting rules, or make a mistake in trying to make sense of the quoting
rules.  In the first case, the user *really* wants " in their argument,
in the second case it's not our place to clean it up.

Here's an example:

C:\>python -c "import sys;print(sys.argv)" test "test2" "test 3" 'test
4' 'test5' """test 6" ""test 7 "test""8"
['-c', 'test', 'test2', 'test 3', "'test", "4'", "'test5'", '"test 6',
'test', '7', 'test"8']

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

From report at bugs.python.org  Tue Apr 14 16:22:41 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Apr 2015 14:22:41 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1429021361.55.0.132025095516.issue22812@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Looking deeper at this, I think the best solution is to use '"*.py"' instead of "'*.py'" without changing the code at all.  Quoting on the Windows shell is somewhat of a nightmare (see my example on Rietveld), but using double quotes works on both Windows and Linux.

----------

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

From report at bugs.python.org  Tue Apr 14 17:08:37 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Apr 2015 15:08:37 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
	instead of	find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1429024117.1.0.248928053627.issue23936@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You're right, it should be find_spec.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Tue Apr 14 17:45:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 15:45:22 +0000
Subject: [docs] [issue21146] update gzip usage examples in docs
In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za>
Message-ID: <20150414154518.119978.28133@psf.io>


Roundup Robot added the comment:

New changeset ae1528beae67 by Andrew Kuchling in branch 'default':
#21146: give a more efficient recipe in gzip docs
https://hg.python.org/cpython/rev/ae1528beae67

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

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

From report at bugs.python.org  Tue Apr 14 17:46:40 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 14 Apr 2015 15:46:40 +0000
Subject: [docs] [issue21146] update gzip usage examples in docs
In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za>
Message-ID: <1429026400.15.0.839336954859.issue21146@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <amk at amk.ca>:


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

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

From report at bugs.python.org  Tue Apr 14 17:47:03 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 14 Apr 2015 15:47:03 +0000
Subject: [docs] [issue21146] update gzip usage examples in docs
In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za>
Message-ID: <1429026423.47.0.244804794366.issue21146@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Applied to trunk.  Wolfgang Maier: thanks for your patch!

----------
nosy: +akuchling

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

From report at bugs.python.org  Tue Apr 14 18:07:09 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Tue, 14 Apr 2015 16:07:09 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1429027629.09.0.946654410289.issue9014@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

PEP 3123 is the one that describes this change. I'm submitting a file with the proposed changes to the docs.

----------
keywords: +patch
nosy: +wiggin15
Added file: http://bugs.python.org/file38991/issue9014.diff

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

From report at bugs.python.org  Tue Apr 14 19:05:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 17:05:19 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <20150414170516.66501.95363@psf.io>


Roundup Robot added the comment:

New changeset 3e8047ee9bbb by Gregory P. Smith in branch '3.4':
issue22046: mention that zipfile can raise NotImplementedError on unsupported
https://hg.python.org/cpython/rev/3e8047ee9bbb

New changeset 4b9deb7e6f2b by Gregory P. Smith in branch 'default':
issue22046: mention that zipfile can raise NotImplementedError on unsupported
https://hg.python.org/cpython/rev/4b9deb7e6f2b

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

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

From report at bugs.python.org  Tue Apr 14 19:06:57 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Apr 2015 17:06:57 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1429031217.12.0.22658221716.issue22046@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

fyi - i didn't update the 2.7 docs. just 3.4 and 3.5. if some committer wants to, feel free.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Tue Apr 14 19:07:06 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Apr 2015 17:07:06 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1429031226.54.0.0791801308363.issue22046@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Tue Apr 14 20:12:35 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 14 Apr 2015 18:12:35 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1429035155.04.0.204597584886.issue9014@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Did you intend to remove the discussion of Py_TRACE_REFS completely?  (I've reworked your patch a little bit, adding some markup such as :c:macro:`Py_REFCNT`.)

----------
nosy: +akuchling
Added file: http://bugs.python.org/file39000/issue.txt

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

From report at bugs.python.org  Tue Apr 14 20:13:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 18:13:34 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <20150414181331.111150.48382@psf.io>


Roundup Robot added the comment:

New changeset 760c5cfacbaa by Gregory P. Smith in branch '3.4':
issue9014: Properly document PyObject_HEAD and friends post-PEP-3123.
https://hg.python.org/cpython/rev/760c5cfacbaa

New changeset 7dc8f0075d60 by Gregory P. Smith in branch 'default':
issue9014: Properly document PyObject_HEAD and friends post-PEP-3123.
https://hg.python.org/cpython/rev/7dc8f0075d60

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

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

From report at bugs.python.org  Tue Apr 14 20:14:46 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Apr 2015 18:14:46 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1429035286.46.0.767640133294.issue9014@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

i used wiggin15's patch to start with.  I'm now looking at akuchling's patch and will incorporate any additional things it adds (I missed that earlier).

----------
assignee: docs at python -> gregory.p.smith
nosy: +gregory.p.smith

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

From report at bugs.python.org  Tue Apr 14 20:17:00 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 14 Apr 2015 18:17:00 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1429035420.72.0.0260125287774.issue9014@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The markup is not a huge deal, I think.  I also did some bits of rewording that can probably be ignored.  The TRACE_REFS question is the only important one, I think.

----------

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

From report at bugs.python.org  Tue Apr 14 20:21:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 18:21:40 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <20150414182137.21281.27422@psf.io>


Roundup Robot added the comment:

New changeset 752ea0acc37e by Gregory P. Smith in branch '3.4':
issue9014: Include more formatting on :c:type:`PyObject` etc.
https://hg.python.org/cpython/rev/752ea0acc37e

New changeset 78a2d1169be1 by Gregory P. Smith in branch 'default':
issue9014: Include more formatting on :c:type:`PyObject` etc.
https://hg.python.org/cpython/rev/78a2d1169be1

----------

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

From report at bugs.python.org  Tue Apr 14 20:24:53 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Apr 2015 18:24:53 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1429035893.57.0.892510151424.issue9014@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

We no longer describe the contents of PyObject in the docs so mentioning Py_TRACE_REFS does not seem worth it as that just changes Py_HEAD_EXTRA which adds the doubly linked list to PyObject (today).

Py_TRACE_REFS isn't useful for anyone to know about IMNSHO as it's a compile time define that normally comes from choosing to do a pydebug build.  (I believe we have or have at least had bugs in our code where Py_TRACE_REFS won't work if Py_DEBUG is not also defined as we never test in such a mixed non-DEBUG but with TRACE_REFS configuration)

----------
resolution:  -> fixed
stage:  -> commit review
status: open -> closed
versions: +Python 3.4, Python 3.5

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

From jheiv at jheiv.com  Tue Apr 14 20:38:11 2015
From: jheiv at jheiv.com (jheiv at jheiv.com)
Date: Tue, 14 Apr 2015 18:38:11 -0000
Subject: [docs] Standardize documentation whitespace,
	formatting (issue 23921)
Message-ID: <20150414183811.8299.96434@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23921/diff/14500/Doc/faq/design.rst#newcode161
Doc/faq/design.rst:161: # ... do something with line
On 2015/04/14 15:35:46, storchaka wrote:
> No need to swap ... and #. It is better to follow common style in
examples and
> "...  #" has advantages over "# ...".

I agree completely.  I'm not sure why I got this backwards.  In other
places, I did the opposite (replace "# ..." with "...  #")

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

From report at bugs.python.org  Tue Apr 14 20:39:54 2015
From: report at bugs.python.org (James Edwards)
Date: Tue, 14 Apr 2015 18:39:54 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1429036794.82.0.883495813948.issue23921@psf.upfronthosting.co.za>


James Edwards added the comment:

Thanks for the review Serhiy.

I'll prepare a revised patchset, given the comments from you and Berker and have it uploaded today.

Thanks again.

----------

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

From jheiv at jheiv.com  Tue Apr 14 21:56:25 2015
From: jheiv at jheiv.com (jheiv at jheiv.com)
Date: Tue, 14 Apr 2015 19:56:25 -0000
Subject: [docs] Standardize documentation whitespace,
	formatting (issue 23921)
Message-ID: <20150414195625.30575.95149@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23921/diff/14500/Doc/howto/logging-cookbook.rst#newcode713
Doc/howto/logging-cookbook.rst:713: if record is None:     # We send
this as a sentinel to tell the listener to quit.
On 2015/04/14 15:35:46, storchaka wrote:
> This line already is too long, and additional spaces make it even
longer. This
> violates PEP 8. I would left this code (and other long lines) as is.
You can
> open new issue for long lines in examples.

FTR, I relaxed the PEP-8 requirements in my script for long lines from
80 to 100 -- there were a significant number of lines that violated the
80 character width, and considerably less that violated the 100
character width.

I'll revert this change as you suggest, and then run a pass of the
script looking only for long lines and open a separate issue for them.

http://bugs.python.org/review/23921/diff/14500/Doc/library/html.parser.rst
File Doc/library/html.parser.rst (right):

http://bugs.python.org/review/23921/diff/14500/Doc/library/html.parser.rst#newcode294
Doc/library/html.parser.rst:294: 
On 2015/04/14 15:35:46, storchaka wrote:
> Trailing spaces.

It's my understanding that these are needed for docutils to consider the
two sections part of a contiguous literal block.

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

From report at bugs.python.org  Tue Apr 14 22:00:05 2015
From: report at bugs.python.org (James Edwards)
Date: Tue, 14 Apr 2015 20:00:05 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1429041599.47.0.0805330763774.issue23921@psf.upfronthosting.co.za>


James Edwards added the comment:

Attaching revised patch per reviews.

Notable changes:

  * Reverted howto/curses.rst multiple inline statements -> multi-target 
    assignment (curses.rst is now unchanged)

  * Reverted library/subprocess.rst "==>" to "# ==>" changes since there are 
    other outstanding issues in the file.  (subprocess.rst is now unchanged)

----------
Added file: http://bugs.python.org/file39013/docsdiff.r2.diff

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

From report at bugs.python.org  Tue Apr 14 22:05:58 2015
From: report at bugs.python.org (Jacinda Shelly)
Date: Tue, 14 Apr 2015 20:05:58 +0000
Subject: [docs] [issue23956] Compatibility misspelled in Lib/imp.py
Message-ID: <1429041958.63.0.857805541545.issue23956@psf.upfronthosting.co.za>


New submission from Jacinda Shelly:

Minor misspelling in Lib/imp.py. Doing this as a training exercise for my first patch.

----------
assignee: docs at python
components: Documentation
files: misspelling.patch
keywords: patch
messages: 241005
nosy: docs at python, jacinda
priority: normal
severity: normal
status: open
title: Compatibility misspelled in Lib/imp.py
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39014/misspelling.patch

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

From report at bugs.python.org  Tue Apr 14 22:06:13 2015
From: report at bugs.python.org (Andrew Pinkham)
Date: Tue, 14 Apr 2015 20:06:13 +0000
Subject: [docs] [issue23957] Additional misspelled in documentation
Message-ID: <1429041973.13.0.203426260536.issue23957@psf.upfronthosting.co.za>


New submission from Andrew Pinkham:

There is a minor typo under PyMem_SetupDebugHooks in the C-API section in 3.4 and 3.5 . "Additional" is misspelled as "Additionnal" on the page.

https://docs.python.org/3.5/c-api/memory.html
https://docs.python.org/3.4/c-api/memory.html

The problem does not appear to occur earlier.

----------
assignee: docs at python
components: Documentation
files: additionnal_typo_fix.patch
keywords: patch
messages: 241006
nosy: docs at python, jambonrose
priority: normal
severity: normal
status: open
title: Additional misspelled in documentation
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39015/additionnal_typo_fix.patch

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

From report at bugs.python.org  Tue Apr 14 22:36:51 2015
From: report at bugs.python.org (Dorian Pula)
Date: Tue, 14 Apr 2015 20:36:51 +0000
Subject: [docs] [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1429043811.71.0.181453200321.issue20769@psf.upfronthosting.co.za>


Changes by Dorian Pula <dorian.pula at amber-penguin-software.ca>:


----------
keywords: +patch
versions: +Python 3.5
Added file: http://bugs.python.org/file39019/reload_importlib_doc_py_3_5_fix.patch

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

From report at bugs.python.org  Tue Apr 14 22:43:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 20:43:15 +0000
Subject: [docs] [issue23957] Additional misspelled in documentation
In-Reply-To: <1429041973.13.0.203426260536.issue23957@psf.upfronthosting.co.za>
Message-ID: <20150414204312.16117.7356@psf.io>


Roundup Robot added the comment:

New changeset ef58fc2e7b06 by R David Murray in branch '3.4':
#23957: fix typo.
https://hg.python.org/cpython/rev/ef58fc2e7b06

New changeset 4286afa7b63e by R David Murray in branch 'default':
Merge: #23957: fix typo.
https://hg.python.org/cpython/rev/4286afa7b63e

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

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

From report at bugs.python.org  Tue Apr 14 22:44:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Apr 2015 20:44:10 +0000
Subject: [docs] [issue23957] Additional misspelled in documentation
In-Reply-To: <1429041973.13.0.203426260536.issue23957@psf.upfronthosting.co.za>
Message-ID: <1429044250.68.0.269279970664.issue23957@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Andrew.

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

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

From report at bugs.python.org  Tue Apr 14 22:46:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Apr 2015 20:46:35 +0000
Subject: [docs] [issue23956] Compatibility misspelled in Lib/imp.py
In-Reply-To: <1429041958.63.0.857805541545.issue23956@psf.upfronthosting.co.za>
Message-ID: <20150414204632.816.96599@psf.io>


Roundup Robot added the comment:

New changeset 08400c64af93 by Zachary Ware in branch '3.4':
Issue #23956: Fix typo in imp.py docstring.
https://hg.python.org/cpython/rev/08400c64af93

New changeset 5586d4a4402e by Zachary Ware in branch 'default':
Closes #23956: Merge with 3.4
https://hg.python.org/cpython/rev/5586d4a4402e

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

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

From report at bugs.python.org  Tue Apr 14 22:47:03 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Apr 2015 20:47:03 +0000
Subject: [docs] [issue23956] Compatibility misspelled in Lib/imp.py
In-Reply-To: <1429041958.63.0.857805541545.issue23956@psf.upfronthosting.co.za>
Message-ID: <1429044423.12.0.637689638948.issue23956@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thank you for the patch!

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

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

From report at bugs.python.org  Tue Apr 14 23:08:50 2015
From: report at bugs.python.org (Dorian Pula)
Date: Tue, 14 Apr 2015 21:08:50 +0000
Subject: [docs] [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1429045730.5.0.900442477897.issue20769@psf.upfronthosting.co.za>


Changes by Dorian Pula <dorian.pula at amber-penguin-software.ca>:


Added file: http://bugs.python.org/file39020/reload_builtin_functions_doc_py_2_7_fix.patch

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

From report at bugs.python.org  Tue Apr 14 23:09:44 2015
From: report at bugs.python.org (Dorian Pula)
Date: Tue, 14 Apr 2015 21:09:44 +0000
Subject: [docs] [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1429045784.3.0.574365387441.issue20769@psf.upfronthosting.co.za>


Dorian Pula added the comment:

Attached patches with proposed change to the documentation to make the description clearer.

Please review and comment.

----------
nosy: +dorianpula

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

From report at bugs.python.org  Tue Apr 14 23:50:07 2015
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Tue, 14 Apr 2015 21:50:07 +0000
Subject: [docs] [issue23936] Wrong references to deprecated find_module
	instead of	find_spec
In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za>
Message-ID: <1429048207.84.0.331360524312.issue23936@psf.upfronthosting.co.za>


Ra?l Cumplido added the comment:

Added changes on both places where there was still references to find_module without specifying that has been deprecated.

----------
keywords: +patch
Added file: http://bugs.python.org/file39021/issue23936.patch

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

From report at bugs.python.org  Wed Apr 15 01:51:03 2015
From: report at bugs.python.org (Pam McA'Nulty)
Date: Tue, 14 Apr 2015 23:51:03 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1429055463.67.0.775053006843.issue22812@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

This version of the patch just updates the docs.  Since the quotes aren't really necessary for the example to work, the patch removes the single quotes from the example.  

I don't think that the python unittest documentation should explain/document the various command-line quoting rules, so let's not add un-necessary confusion.

----------
Added file: http://bugs.python.org/file39025/cpython-22812-discovery-quotes-v2.patch

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

From report at bugs.python.org  Wed Apr 15 02:03:51 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Wed, 15 Apr 2015 00:03:51 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429056231.33.0.167223146246.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

Ping?

----------

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

From report at bugs.python.org  Wed Apr 15 02:06:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Apr 2015 00:06:42 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1429056402.75.0.502123840413.issue22812@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, but the quotes *are* necessary on unix.  Without the quotes, the shell will try to fill in the glob, which will either fail with an error that no files match or (worse) succeed and turn the pattern into a list of filenames.  Which is why Zach is suggesting using double quotes, which have the (same) documented result on both unix and windows, even though *why* they have the same result is slightly different on the two systems.

----------

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

From report at bugs.python.org  Wed Apr 15 02:17:35 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Apr 2015 00:17:35 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429057055.1.0.625442977291.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm re-uploading the patch as an hg diff so that it gets a review link.

----------
Added file: http://bugs.python.org/file39026/tempfile_docs.patch

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

From rdmurray at bitdance.com  Wed Apr 15 02:40:14 2015
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Wed, 15 Apr 2015 00:40:14 -0000
Subject: [docs] [PATCH] update tempfile docs to say that TemporaryFile is
 secure (issue 23725)
Message-ID: <20150415004014.345.3651@psf.upfronthosting.co.za>


http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst
File Doc/library/tempfile.rst (left):

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#oldcode55
Doc/library/tempfile.rst:55: :keyword:`with` statement, just like a
normal file.
Why did you remove this statement?

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst
File Doc/library/tempfile.rst (right):

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode25
Doc/library/tempfile.rst:25: The need to use the insecure :func:`mktemp`
function is eliminated.
How about we get even more radical.  Let's eliminate the mention of
mktemp from the documentation, except for a "Deprecated Functions"
section at the end, where we explain that it is deprecated because it is
insecure and anything you could do with it you can do with the
un-deprecated functions.

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode27
Doc/library/tempfile.rst:27: instead a string of six random characters
is used.
Let's likewise eliminate the mention of the process id, and just leave
the explanation that six random characters are used.

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode31
Doc/library/tempfile.rst:31: directories.  It is no longer necessary to
use the global *tempdir* variable.
The global tempdir variable can likewise be moved to the deprecated
section and removed from mention here.

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode42
Doc/library/tempfile.rst:42: collected).  Under Unix, the directory
entry for the file is either not created at all or removed
"or is removed"

http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode247
Doc/library/tempfile.rst:247: 
There should be another blank line here.

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

From report at bugs.python.org  Wed Apr 15 02:40:57 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Apr 2015 00:40:57 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429058457.38.0.549651729455.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for reformatting the patch.  I made some review comments.

----------

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

From report at bugs.python.org  Wed Apr 15 02:43:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Apr 2015 00:43:30 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1429058609.98.0.656640002438.issue22812@psf.upfronthosting.co.za>


R. David Murray added the comment:

I should clarify that some unix shells will pass the glob through if there are no files that match, while some will generate the 'no matching files' error message.  The former is actually worse, since that means that sometimes it works without the quotes, and sometimes it doesn't.

----------

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

From report at bugs.python.org  Wed Apr 15 04:15:27 2015
From: report at bugs.python.org (Pam McA'Nulty)
Date: Wed, 15 Apr 2015 02:15:27 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1429064127.31.0.847482696623.issue22812@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

Thanks, Zach for both the comments and the mention of the email bounce.  I changed jobs and didn't have this site listed in my "must update email address list"  (fixed now)

Should I re-update the doc patch and put in double quotes?

----------

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

From report at bugs.python.org  Wed Apr 15 05:33:52 2015
From: report at bugs.python.org (Ryder Lewis)
Date: Wed, 15 Apr 2015 03:33:52 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
	concurrent.futures	documentation
Message-ID: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>


New submission from Ryder Lewis:

The documentation at https://docs.python.org/3/library/concurrent.futures.html has several functions that case raise a TimeoutError. The hyperlink generated for TimeoutError links to the built-in exception https://docs.python.org/3/library/exceptions.html#TimeoutError. However, the exception raised is a concurrent.futures._base.TimeoutError exception instead, which is undocumented.

----------
assignee: docs at python
components: Documentation
messages: 241074
nosy: docs at python, ryder.lewis
priority: normal
severity: normal
status: open
title: Incorrect TimeoutError referenced in concurrent.futures documentation
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 15 05:37:54 2015
From: report at bugs.python.org (Ryder Lewis)
Date: Wed, 15 Apr 2015 03:37:54 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
	concurrent.futures	documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <1429069073.93.0.402092737341.issue23962@psf.upfronthosting.co.za>


Ryder Lewis added the comment:

I attached a small patch that fixes the documentation, and also documents the other missing exceptions from concurrent.futures documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file39029/issue23962.patch

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

From report at bugs.python.org  Wed Apr 15 06:51:17 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Apr 2015 04:51:17 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
	concurrent.futures	documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <1429073477.2.0.774380273674.issue23962@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bquinlan
stage:  -> patch review

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

From report at bugs.python.org  Wed Apr 15 10:44:57 2015
From: report at bugs.python.org (Carol Willing)
Date: Wed, 15 Apr 2015 08:44:57 +0000
Subject: [docs] [issue23320] devguide should mention rules about "paragraph
	reflow"	in the documentation
In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za>
Message-ID: <1429087497.61.0.797133900506.issue23320@psf.upfronthosting.co.za>


Carol Willing added the comment:

https://bugs.python.org/issue18041 also provides related insights. Ideally, a patch for this issue should address and close both issues.

----------
nosy: +willingc

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

From report at bugs.python.org  Wed Apr 15 14:05:17 2015
From: report at bugs.python.org (Pam McA'Nulty)
Date: Wed, 15 Apr 2015 12:05:17 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1429099517.24.0.474206084151.issue22812@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

Here's a version of the docs with double quotes

----------
Added file: http://bugs.python.org/file39033/cpython-22812-discovery-double-quotes-v3.patch

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

From report at bugs.python.org  Wed Apr 15 22:16:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 15 Apr 2015 20:16:20 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <20150415201617.11872.79067@psf.io>


Roundup Robot added the comment:

New changeset e3cc75b1000b by Steve Dower in branch 'default':
Issue 19933: Provide default argument for ndigits in round. Patch by Vajrasky Kok.
https://hg.python.org/cpython/rev/e3cc75b1000b

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

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

From report at bugs.python.org  Wed Apr 15 22:16:44 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Apr 2015 20:16:44 +0000
Subject: [docs] [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1429129004.87.0.522395801755.issue19933@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


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

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

From stephen.longfield at gmail.com  Thu Apr 16 02:15:03 2015
From: stephen.longfield at gmail.com (Stephen Longfield)
Date: Wed, 15 Apr 2015 20:15:03 -0400
Subject: [docs] Contributing curses example programs
Message-ID: <CAGM0z9AhEK-zJU8cFQ3PSqGWvRbuiZnmumJr0VzKCJmokHn6Tg@mail.gmail.com>

Hi Docs,

I was reading over https://docs.python.org/2/bugs.html, and at the bottom,
it suggests that if we've created any interesting programs using the curses
python library that they would be useful to contribute as examples.

I've translated the basic examples from the NCURSES HOWTO (
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/index.html ) to Python 2.7
using the curses library, as well as translating the game of life example,
and writing some of my own code for editing bass guitar tablature. I would
be happy to contribute these as examples, but I wasn't sure how to do so.

Best,

--Stephen Longfield
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150415/c74f2fa9/attachment.html>

From berker.peksag at gmail.com  Thu Apr 16 17:01:14 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Thu, 16 Apr 2015 18:01:14 +0300
Subject: [docs] Contributing curses example programs
In-Reply-To: <CAGM0z9AhEK-zJU8cFQ3PSqGWvRbuiZnmumJr0VzKCJmokHn6Tg@mail.gmail.com>
References: <CAGM0z9AhEK-zJU8cFQ3PSqGWvRbuiZnmumJr0VzKCJmokHn6Tg@mail.gmail.com>
Message-ID: <CAF4280KqoqXbxqniFnTCsNXaa0+rpUUBRYhUbtJP8nbzEVKzAw@mail.gmail.com>

On Thu, Apr 16, 2015 at 3:15 AM, Stephen Longfield
<stephen.longfield at gmail.com> wrote:
> Hi Docs,
>
> I was reading over https://docs.python.org/2/bugs.html, and at the bottom,
> it suggests that if we've created any interesting programs using the curses
> python library that they would be useful to contribute as examples.
>
> I've translated the basic examples from the NCURSES HOWTO (
> http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/index.html ) to Python 2.7
> using the curses library, as well as translating the game of life example,
> and writing some of my own code for editing bass guitar tablature. I would
> be happy to contribute these as examples, but I wasn't sure how to do so.

Hi and welcome Stephen,

The standard library documentation is located in Doc/ directory in the
main CPython repo: https://hg.python.org/cpython/

https://docs.python.org/devguide/index.html is a good starting point
for learning how to clone the main repo and send your first patch to
https://bugs.python.org/.

You can also ask more questions on the core-mentorship list:
https://mail.python.org/mailman/listinfo/core-mentorship

Thanks!

--Berker

From report at bugs.python.org  Thu Apr 16 21:37:32 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Apr 2015 19:37:32 +0000
Subject: [docs] [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1429213052.03.0.0961924803803.issue20769@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch LGTM.

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

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

From report at bugs.python.org  Fri Apr 17 03:17:28 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Apr 2015 01:17:28 +0000
Subject: [docs] [issue23983] Update example in the pty documentation
Message-ID: <1429233448.23.0.72580455628.issue23983@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I was reading pty docs after watching a PyCon talk and the example in https://docs.python.org/3/library/pty.html#example looked a bit outdated to me. Here is a patch to update it.

Changes:

* Fixed a ResourceWarning warning
* Used argparse instead of getopt

----------
assignee: docs at python
components: Documentation
files: pty-example.diff
keywords: patch
messages: 241301
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Update example in the pty documentation
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39082/pty-example.diff

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

From report at bugs.python.org  Fri Apr 17 05:51:08 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2015 03:51:08 +0000
Subject: [docs] [issue23983] Update example in the pty documentation
In-Reply-To: <1429233448.23.0.72580455628.issue23983@psf.upfronthosting.co.za>
Message-ID: <1429242668.97.0.821705180201.issue23983@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +twouters

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

From report at bugs.python.org  Fri Apr 17 06:42:08 2015
From: report at bugs.python.org (bjonnh)
Date: Fri, 17 Apr 2015 04:42:08 +0000
Subject: [docs] [issue23984] Documentation error: Descriptors
Message-ID: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>


New submission from bjonnh:

in
https://docs.python.org/3.5/howto/descriptor.html#static-methods-and-class-methods

(same problem in all python 3.x documentations)

There is this example where the return of f function is printed and there is already a print in the function:
"""
>>> class E(object):
     def f(x):
          print(x)
     f = staticmethod(f)

>>> print(E.f(3))
3
>>> print(E().f(3))
3
"""

It should probably be:

"""
def f(x):
    return(x)
"""

or 

"""
>> E.f(3)
3
>> E().f(3)
"""

----------
assignee: docs at python
components: Documentation
messages: 241312
nosy: bjonnh, docs at python
priority: normal
severity: normal
status: open
title: Documentation error: Descriptors
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Apr 17 06:52:48 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2015 04:52:48 +0000
Subject: [docs] [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1429246368.18.0.195303102233.issue23984@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +rhettinger
versions: +Python 2.7 -Python 3.2, Python 3.3, Python 3.6

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

From report at bugs.python.org  Fri Apr 17 07:19:32 2015
From: report at bugs.python.org (Alex Lord)
Date: Fri, 17 Apr 2015 05:19:32 +0000
Subject: [docs] [issue18262] ZipInfo.external_attr are not documented
In-Reply-To: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za>
Message-ID: <1429247972.67.0.371079856607.issue18262@psf.upfronthosting.co.za>


Alex Lord added the comment:

Any follow up on this?

----------

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

From report at bugs.python.org  Fri Apr 17 07:22:07 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2015 05:22:07 +0000
Subject: [docs] [issue18262] ZipInfo.external_attr are not documented
In-Reply-To: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za>
Message-ID: <1429248127.27.0.0469830036871.issue18262@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters

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

From report at bugs.python.org  Fri Apr 17 07:22:42 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Apr 2015 05:22:42 +0000
Subject: [docs] [issue18262] ZipInfo.external_attr are not documented
In-Reply-To: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za>
Message-ID: <1429248162.29.0.28391546425.issue18262@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From stephen.longfield at gmail.com  Thu Apr 16 20:36:26 2015
From: stephen.longfield at gmail.com (Stephen Longfield)
Date: Thu, 16 Apr 2015 18:36:26 +0000
Subject: [docs] Contributing curses example programs
In-Reply-To: <CAF4280KqoqXbxqniFnTCsNXaa0+rpUUBRYhUbtJP8nbzEVKzAw@mail.gmail.com>
References: <CAGM0z9AhEK-zJU8cFQ3PSqGWvRbuiZnmumJr0VzKCJmokHn6Tg@mail.gmail.com>
 <CAF4280KqoqXbxqniFnTCsNXaa0+rpUUBRYhUbtJP8nbzEVKzAw@mail.gmail.com>
Message-ID: <CAGM0z9Co=KtStU=7wRmMRjyyzPguuHPtfiPb3e3Ff8YRCz=skQ@mail.gmail.com>

Thank you, I'll look into that.

Best,

--Stephen

On Thu, Apr 16, 2015, 8:01 AM Berker Peksa? <berker.peksag at gmail.com> wrote:

> On Thu, Apr 16, 2015 at 3:15 AM, Stephen Longfield
> <stephen.longfield at gmail.com> wrote:
> > Hi Docs,
> >
> > I was reading over https://docs.python.org/2/bugs.html, and at the
> bottom,
> > it suggests that if we've created any interesting programs using the
> curses
> > python library that they would be useful to contribute as examples.
> >
> > I've translated the basic examples from the NCURSES HOWTO (
> > http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/index.html ) to Python
> 2.7
> > using the curses library, as well as translating the game of life
> example,
> > and writing some of my own code for editing bass guitar tablature. I
> would
> > be happy to contribute these as examples, but I wasn't sure how to do so.
>
> Hi and welcome Stephen,
>
> The standard library documentation is located in Doc/ directory in the
> main CPython repo: https://hg.python.org/cpython/
>
> https://docs.python.org/devguide/index.html is a good starting point
> for learning how to clone the main repo and send your first patch to
> https://bugs.python.org/.
>
> You can also ask more questions on the core-mentorship list:
> https://mail.python.org/mailman/listinfo/core-mentorship
>
> Thanks!
>
> --Berker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150416/46fafd9b/attachment.html>

From brett at python.org  Thu Apr 16 21:35:58 2015
From: brett at python.org (brett at python.org)
Date: Thu, 16 Apr 2015 19:35:58 -0000
Subject: [docs] Wrong references to deprecated find_module instead of
	find_spec (issue 23936)
Message-ID: <20150416193558.23582.34854@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/23936/diff/14587/Doc/glossary.rst#oldcode253
Doc/glossary.rst:253: implement either a method named
:meth:`find_loader` or a method named
If find_loader() is going to be mentioned then find_module should also
be mentioned, leading to three methods being listed
(backwards-compatibility is such fun =/ ).

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

From report at bugs.python.org  Fri Apr 17 09:22:58 2015
From: report at bugs.python.org (wim glenn)
Date: Fri, 17 Apr 2015 07:22:58 +0000
Subject: [docs] [issue23986] Inaccuracy about "in" keyword for list and tuple
Message-ID: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za>


New submission from wim glenn:

The comparisons section of the python 2 docs says:

--- 

https://docs.python.org/2/reference/expressions.html#comparisons

For the list and tuple types, x in y is true if and only if there exists an index i such that x == y[i] is true.

---

But it's not strictly speaking correct.  Simplest counter-example:

x = float('nan')
y = [x]

The python 3 docs instead mention correct equivalent which is 

any(x is e or x == e for e in y)

----------
assignee: docs at python
components: Documentation
messages: 241317
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: Inaccuracy about "in" keyword for list and tuple
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 17 12:04:17 2015
From: report at bugs.python.org (Jonathan Sharpe)
Date: Fri, 17 Apr 2015 10:04:17 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429265057.98.0.197098103761.issue23987@psf.upfronthosting.co.za>


Changes by Jonathan Sharpe <j.r.sharpe+python at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, jonrsharpe

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

From report at bugs.python.org  Fri Apr 17 12:08:50 2015
From: report at bugs.python.org (Jonathan Sharpe)
Date: Fri, 17 Apr 2015 10:08:50 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429265330.6.0.656689045008.issue23987@psf.upfronthosting.co.za>


Jonathan Sharpe added the comment:

I don't think it's as simple as linking to the hashable definition. The "equivalent expression" is simply wrong for dict/set/frozenset, as those types check hash equality, not identity.

----------

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

From report at bugs.python.org  Fri Apr 17 17:04:40 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 17 Apr 2015 15:04:40 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429283080.62.0.4450895858.issue23987@psf.upfronthosting.co.za>


Ethan Furman added the comment:

It's not quite that simple -- those containers use the hash to find the objects that will be first checked by identity, and then equality* -- otherwise they would have to do a complete scan from first key to last, and that would kill performance.

...

Okay, I see your point -- even for sane objects, a systematic check of every key is not undertaken for the hash-type containers.

Perhaps something like:

For container types such as list, tuple, or collections.deque, the expression 'x in y' is equivalent to 'any(x is e or x == e for e in y)'.  For container types such as set, frozenset, and dict, 'x in y' is equivalent to 'any(x is e or x == e for e in z)' where 'z' is a collection of objects in 'y' that have the same hash.

----------

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

From report at bugs.python.org  Fri Apr 17 17:37:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Apr 2015 15:37:58 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429285078.33.0.535689392867.issue23987@psf.upfronthosting.co.za>


R. David Murray added the comment:

Could we add "For dictionaries and sets this equivalence expression is modified by the addition of 'if hash(x) == hash(e)'?

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

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

From report at bugs.python.org  Fri Apr 17 18:11:27 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 17 Apr 2015 16:11:27 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429287087.4.0.662930749483.issue23987@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I think I like that better than my suggestion.  :)

----------

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

From report at bugs.python.org  Fri Apr 17 19:06:31 2015
From: report at bugs.python.org (James Edwards)
Date: Fri, 17 Apr 2015 17:06:31 +0000
Subject: [docs] [issue23986] Inaccuracy about "in" keyword for list and tuple
In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za>
Message-ID: <1429290391.08.0.570578690761.issue23986@psf.upfronthosting.co.za>


James Edwards added the comment:

What about:

 For the list and tuple types, ``x in y`` is true if and only if there exists an
-index *i* such that ``x == y[i]`` is true.
+index *i* such that either ``x == y[i]`` or ``x is y[i]`` is true.

Seems to address your issue, and match the semantics of the Python3 any() approach.

----------
keywords: +patch
nosy: +jedwards
Added file: http://bugs.python.org/file39087/issue23986.diff

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

From report at bugs.python.org  Fri Apr 17 20:33:42 2015
From: report at bugs.python.org (VanL)
Date: Fri, 17 Apr 2015 18:33:42 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
Message-ID: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>


New submission from VanL:

Attached is a basic patch to add a recommendation to use requests to the http.client documentation for 3.5. It is implemented as a seealso at the top of the file: 

See Also: The Requests package is recommended for a higher-level http client interface.

If people are happy with the wording, I'll also add the same message to urllib.request and do the same with previous versions (2.7, 3.3, and 3.4).

----------
assignee: docs at python
components: Documentation
files: recommend_requests.patch
keywords: patch
messages: 241349
nosy: VanL, docs at python
priority: normal
severity: normal
status: open
title: Add recommendation to use requests to the documentation, per summit
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39088/recommend_requests.patch

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

From report at bugs.python.org  Fri Apr 17 21:35:07 2015
From: report at bugs.python.org (Ian Cordasco)
Date: Fri, 17 Apr 2015 19:35:07 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <1429299307.97.0.646277837673.issue23989@psf.upfronthosting.co.za>


Changes by Ian Cordasco <graffatcolmingov at gmail.com>:


----------
nosy: +icordasc

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

From graffatcolmingov at gmail.com  Fri Apr 17 21:38:43 2015
From: graffatcolmingov at gmail.com (graffatcolmingov at gmail.com)
Date: Fri, 17 Apr 2015 19:38:43 -0000
Subject: [docs] Add recommendation to use requests to the documentation,
 per summit (issue 23989)
Message-ID: <20150417193843.4418.74827@psf.upfronthosting.co.za>

LGTM

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

From report at bugs.python.org  Fri Apr 17 21:39:28 2015
From: report at bugs.python.org (Cory Benfield)
Date: Fri, 17 Apr 2015 19:39:28 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <1429299568.76.0.158319314243.issue23989@psf.upfronthosting.co.za>


Changes by Cory Benfield <cory at lukasa.co.uk>:


----------
nosy: +Lukasa

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

From report at bugs.python.org  Fri Apr 17 22:25:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Apr 2015 20:25:51 +0000
Subject: [docs] [issue23986] Inaccuracy about "in" keyword for list and tuple
In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za>
Message-ID: <1429302351.16.0.989351907002.issue23986@psf.upfronthosting.co.za>


R. David Murray added the comment:

Those two should be in the reverse order, though.  Identity is checked before equality.  But why not backport the python3 wording?  (Note that there is an open issue for slightly improving that wording).

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

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

From report at bugs.python.org  Sat Apr 18 00:54:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Apr 2015 22:54:45 +0000
Subject: [docs] [issue18262] ZipInfo.external_attr are not documented
In-Reply-To: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za>
Message-ID: <1429311285.74.0.784161202531.issue18262@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Sat Apr 18 01:46:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 17 Apr 2015 23:46:30 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <1429314390.26.0.533351972626.issue23989@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From cory at lukasa.co.uk  Fri Apr 17 23:06:05 2015
From: cory at lukasa.co.uk (cory at lukasa.co.uk)
Date: Fri, 17 Apr 2015 21:06:05 -0000
Subject: [docs] Add recommendation to use requests to the documentation,
 per summit (issue 23989)
Message-ID: <20150417210605.4449.24635@psf.upfronthosting.co.za>

Looks good to me.

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

From report at bugs.python.org  Sat Apr 18 12:43:54 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 18 Apr 2015 10:43:54 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1429353834.08.0.154294193733.issue16574@psf.upfronthosting.co.za>


Carol Willing added the comment:

This patch should close this languishing devguide issue. This patch adds wording suggested by Terry Reedy re: pep documentation reference to section 7.4.5 Inline markup (https://docs.python.org/devguide/documenting.html#id3).

The devguide covers the pep process and PEP 1 in section 20.1.2
(https://docs.python.org/devguide/langchanges.html?highlight=pep#pep-process).

----------
keywords: +patch
nosy: +willingc
stage:  -> patch review
Added file: http://bugs.python.org/file39101/iss16574.patch

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

From report at bugs.python.org  Sat Apr 18 14:02:33 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 18 Apr 2015 12:02:33 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1429358553.29.0.224214712257.issue5784@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Here's a short patch that expands the discussion of wbits, and duplicates it under both the compressobj() and decompress() methods.  Should I avoid the duplication and just have a reference?

----------
nosy: +akuchling
Added file: http://bugs.python.org/file39102/patch-5784.txt

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

From report at bugs.python.org  Sat Apr 18 14:16:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Apr 2015 12:16:17 +0000
Subject: [docs] [issue23536] Add explicit information on config file format
	not	supporting filters
In-Reply-To: <1425041368.98.0.00469006830804.issue23536@psf.upfronthosting.co.za>
Message-ID: <20150418121532.27912.50564@psf.io>


Roundup Robot added the comment:

New changeset df28044b7e14 by Vinay Sajip in branch '2.7':
Issue #23536: Clarified scope of fileConfig()'s API.
https://hg.python.org/cpython/rev/df28044b7e14

New changeset 968c086bf6cc by Vinay Sajip in branch '3.4':
Issue #23536: Clarified scope of fileConfig()'s API.
https://hg.python.org/cpython/rev/968c086bf6cc

New changeset 439517000aa2 by Vinay Sajip in branch 'default':
Closes #23536: Clarified scope of fileConfig()'s API.
https://hg.python.org/cpython/rev/439517000aa2

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

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

From report at bugs.python.org  Sat Apr 18 14:38:14 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 18 Apr 2015 12:38:14 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1429360694.65.0.250965857489.issue5784@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <amk at amk.ca>:


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

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

From report at bugs.python.org  Sat Apr 18 14:42:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 18 Apr 2015 12:42:47 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1429360967.33.0.143186737624.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks good in general (apart from one grammar comment).

It might be best to only include one copy, and reference the others. There are actually three places ?wbits? is allowed that I can see:

* compressobj()
* decompress()
* decompressobj()

Maybe just pointing from decompress() and decompressobj() back to the compressobj() description would be good enough. Unless if you know if wbits=0 is also accepted or not for decompression.

----------

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

From report at bugs.python.org  Sat Apr 18 17:19:26 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sat, 18 Apr 2015 15:19:26 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429370366.65.0.878532152608.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

Replying to review here... I get 500 server error in the patch review reply dialogue :(

On 2015/04/15 02:40:14, r.david.murray wrote:
> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst
> File Doc/library/tempfile.rst (left):
> 
> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#oldcode55
> Doc/library/tempfile.rst:55: :keyword:`with` statement, just like a normal file.
> Why did you remove this statement?
It is redundant. The fact that this can be used as CM is already mentioned in the introduction and in the description of TemporaryFile.

> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst
> File Doc/library/tempfile.rst (right):
> 
> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode25
> Doc/library/tempfile.rst:25: The need to use the insecure :func:`mktemp`
> function is eliminated.
> How about we get even more radical.  Let's eliminate the mention of mktemp from
> the documentation, except for a "Deprecated Functions" section at the end, where
> we explain that it is deprecated because it is insecure and anything you could
> do with it you can do with the un-deprecated functions.
Agreed. I'll submit a new version which removes all the historical notes and adds a "Deprecated" section at the end for tempdir and mktemp.

> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode27
> Doc/library/tempfile.rst:27: instead a string of six random characters is used.
> Let's likewise eliminate the mention of the process id, and just leave the
> explanation that six random characters are used.
OK.

> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode31
> Doc/library/tempfile.rst:31: directories.  It is no longer necessary to use the
> global *tempdir* variable.
> The global tempdir variable can likewise be moved to the deprecated section and
> removed from mention here.
OK.

> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode42
> Doc/library/tempfile.rst:42: collected).  Under Unix, the directory entry for
> the file is either not created at all or removed
> "or is removed"
OK.

> http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode247
> Doc/library/tempfile.rst:247: 
> There should be another blank line here.

v5:
- relegate `tempdir` and `mktemp` descriptions to 'Deprecated functions and variables' section at the end. This requires moving some descriptions around.
- add missing "is" pointed out in review
- add missing 's'

----------

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

From report at bugs.python.org  Sat Apr 18 17:23:05 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sat, 18 Apr 2015 15:23:05 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429370585.67.0.466851220365.issue23725@psf.upfronthosting.co.za>


Changes by Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:


Added file: http://bugs.python.org/file39104/tempfile_docs.patch

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

From report at bugs.python.org  Sat Apr 18 18:19:32 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 18 Apr 2015 16:19:32 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1429373972.86.0.17122335401.issue5784@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Thanks! Here's an updated version with some more rewriting -- the list is now in only one place and is linked-to from the decompression documentation.

----------
Added file: http://bugs.python.org/file39105/patch-5784.txt

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

From report at bugs.python.org  Sat Apr 18 19:00:33 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Apr 2015 17:00:33 +0000
Subject: [docs] [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1429376433.47.0.917774697826.issue23984@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Apr 18 20:59:37 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Apr 2015 18:59:37 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <1429383577.11.0.178306858721.issue23989@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

nice and simple. that wording looks good to me.

----------
nosy: +gregory.p.smith

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

From rdmurray at bitdance.com  Sat Apr 18 21:13:48 2015
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Sat, 18 Apr 2015 19:13:48 -0000
Subject: [docs] [PATCH] update tempfile docs to say that TemporaryFile
 is secure (issue 23725)
Message-ID: <20150418191348.4418.45995@psf.upfronthosting.co.za>

One minor suggestion, otherwise this looks good.


http://bugs.python.org/review/23725/diff/14651/Doc/library/tempfile.rst
File Doc/library/tempfile.rst (right):

http://bugs.python.org/review/23725/diff/14651/Doc/library/tempfile.rst#newcode49
Doc/library/tempfile.rst:49: from the filesystem.
OK, somehow I thought the last paragraph (where before I said "why did
you delete this" was talking about a different object...just not paying
attention on my part.  But I think the flow would be better if you moved
this paragraph to the end of the section, where that deleted sentence
was, and start it with "Either way, the returned object can be used
as..."

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

From report at bugs.python.org  Sat Apr 18 21:14:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Apr 2015 19:14:36 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429384476.54.0.232153405145.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Made one minor suggestion in review comments (related to that deleted line).  Otherwise this looks good to me, thanks.

----------

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

From report at bugs.python.org  Sat Apr 18 21:16:31 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Apr 2015 19:16:31 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429384591.92.0.722792822333.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, because of the O_TMPDIR bits, this patch is only applicable to 3.5, so I'm removing 3.4 from versions.  I don't think it is worth it to make a version that would apply to 3.4, since it is not the case that the 3.4 docs are *wrong*.

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

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

From report at bugs.python.org  Sat Apr 18 22:45:48 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Apr 2015 20:45:48 +0000
Subject: [docs] [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1429389948.54.0.256452705218.issue23984@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In addition to being broken, the code is a crummy example that gives no hint of why one might want to use a staticmethod.

----------

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

From report at bugs.python.org  Sun Apr 19 02:08:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 19 Apr 2015 00:08:59 +0000
Subject: [docs] [issue15566] tarfile.TarInfo.frombuf documentation is out of
	date
In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za>
Message-ID: <1429402139.75.0.476810341045.issue15566@psf.upfronthosting.co.za>


Martin Panter added the comment:

Very simple documentation fix; looks good to me.

----------
nosy: +vadmium
stage: needs patch -> commit review
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 19 02:44:00 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sun, 19 Apr 2015 00:44:00 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429404240.35.0.658679712032.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

v6:
- add newline

----------
Added file: http://bugs.python.org/file39112/tempfile_docs.patch

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

From report at bugs.python.org  Sun Apr 19 03:32:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Apr 2015 01:32:42 +0000
Subject: [docs] [issue15566] tarfile.TarInfo.frombuf documentation is out of
	date
In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za>
Message-ID: <20150419013238.31121.27633@psf.io>


Roundup Robot added the comment:

New changeset d737ab3ea1ae by Berker Peksag in branch '3.4':
Issue #15566: Document encoding and errors parameters of TarInfo.frombuf().
https://hg.python.org/cpython/rev/d737ab3ea1ae

New changeset 85cba64e24dc by Berker Peksag in branch 'default':
Issue #15566: Document encoding and errors parameters of TarInfo.frombuf().
https://hg.python.org/cpython/rev/85cba64e24dc

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

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

From report at bugs.python.org  Sun Apr 19 03:33:32 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Apr 2015 01:33:32 +0000
Subject: [docs] [issue15566] tarfile.TarInfo.frombuf documentation is out of
	date
In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za>
Message-ID: <1429407212.17.0.740579595153.issue15566@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 3.2, Python 3.3

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

From vadmium+py at gmail.com  Sat Apr 18 14:40:08 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sat, 18 Apr 2015 12:40:08 -0000
Subject: [docs] raw deflate format and zlib module (issue 5784)
Message-ID: <20150418124008.4418.31524@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/5784/diff/14649/Doc/library/zlib.rst#newcode81
Doc/library/zlib.rst:81: Larger values resulting in better compression
at the expense of greater
Larger values _result_ in . . .

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

From zbyszek at in.waw.pl  Sun Apr 19 02:37:35 2015
From: zbyszek at in.waw.pl (Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?=)
Date: Sun, 19 Apr 2015 00:37:35 +0000
Subject: [docs] [PATCH] update tempfile docs to say that TemporaryFile
 is secure (issue 23725)
In-Reply-To: <20150418191348.4418.45995@psf.upfronthosting.co.za>
References: <1429370366.65.0.878532152608.issue23725@psf.upfronthosting.co.za>
 <20150418191348.4418.45995@psf.upfronthosting.co.za>
Message-ID: <20150419003735.GA25516@in.waw.pl>

On Sat, Apr 18, 2015 at 07:13:48PM -0000, rdmurray at bitdance.com wrote:
> One minor suggestion, otherwise this looks good.
> 
> 
> http://bugs.python.org/review/23725/diff/14651/Doc/library/tempfile.rst
> File Doc/library/tempfile.rst (right):
> 
> http://bugs.python.org/review/23725/diff/14651/Doc/library/tempfile.rst#newcode49
> Doc/library/tempfile.rst:49: from the filesystem.
> OK, somehow I thought the last paragraph (where before I said "why did
> you delete this" was talking about a different object...just not paying
> attention on my part.  But I think the flow would be better if you moved
> this paragraph to the end of the section, where that deleted sentence
> was, and start it with "Either way, the returned object can be used
> as..."
I don't think so. The fact that the file object is the main object or an attribute
is not really important for the user, it is an implementation detail, like the
fact that O_TMPFILE is used. OTOH, using TemporaryFile as a context manager
is important information, and should be exposed at the beginning of the description.

> http://bugs.python.org/review/23725/

So I'm leaving the patch as is, just adding the extra blank line.

Zbyszek

From report at bugs.python.org  Sun Apr 19 12:29:29 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Sun, 19 Apr 2015 10:29:29 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
Message-ID: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>


New submission from Jaivish Kothari:

https://docs.python.org/2/whatsnew/2.4.html?highlight=decorators#pep-318-decorators-for-functions-and-methods
'''
def require_int (func):
    def wrapper (arg):
        assert isinstance(arg, int)
        return func(arg)

    return wrapper
'''

New line is ommited before return wrapper 

'''
def require_int (func):
    def wrapper (arg):
        assert isinstance(arg, int)
        return func(arg)
    return wrapper

'''

----------
assignee: docs at python
components: Documentation
messages: 241508
nosy: docs at python, georg.brandl, janonymous
priority: normal
severity: normal
status: open
title: Documentation Error: Extra line Break
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 19 13:00:56 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Sun, 19 Apr 2015 11:00:56 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429441256.9.0.797668988436.issue24005@psf.upfronthosting.co.za>


Jaivish Kothari added the comment:

Please find the attached patch for review.

----------
keywords: +patch
resolution:  -> fixed
Added file: http://bugs.python.org/file39118/doc_patch.patch

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

From report at bugs.python.org  Sun Apr 19 14:42:51 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Apr 2015 12:42:51 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429447371.09.0.694023660988.issue24005@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Why is this a bug?

----------

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

From report at bugs.python.org  Sun Apr 19 17:23:50 2015
From: report at bugs.python.org (irdb)
Date: Sun, 19 Apr 2015 15:23:50 +0000
Subject: [docs] [issue16893] Generate Idle help from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1429457030.01.0.677664493513.issue16893@psf.upfronthosting.co.za>


Changes by irdb <dalba.wiki at gmail.com>:


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

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

From report at bugs.python.org  Sun Apr 19 19:54:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Apr 2015 17:54:23 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1429466063.78.0.466926069878.issue23725@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Apr 19 20:10:03 2015
From: report at bugs.python.org (Carol Willing)
Date: Sun, 19 Apr 2015 18:10:03 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429467003.58.0.535639176032.issue24005@psf.upfronthosting.co.za>


Carol Willing added the comment:

janonymous, Thanks for the contribution. I agree with George that this is not a bug. The whitespace exists for developer readability and maintainability of code. Here's a section from PEP8 about the use of whitespace (https://www.python.org/dev/peps/pep-0008/#id15). I am closing this issue as not a bug. I do hope you will contribute to Python again. Thanks.

Close as not a bug.

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

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

From report at bugs.python.org  Sun Apr 19 21:06:12 2015
From: report at bugs.python.org (Tim Golden)
Date: Sun, 19 Apr 2015 19:06:12 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429470372.46.0.100362166674.issue24005@psf.upfronthosting.co.za>


Tim Golden added the comment:

One small thing to bear in mind is that the existing code (ie with the extra linefeed) raises an IndentationError if cut-and-pasted into the interactive interpreter; with the OP's change, it succeeds. Might not have been their intention, but certainly is the case.

(Doesn't make it a bug, as such, but makes it more than a stylistic difference of opinion).

----------
nosy: +tim.golden

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

From report at bugs.python.org  Sun Apr 19 21:36:24 2015
From: report at bugs.python.org (Carol Willing)
Date: Sun, 19 Apr 2015 19:36:24 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429472184.93.0.952396992717.issue24005@psf.upfronthosting.co.za>


Carol Willing added the comment:

Tim, A good point re: the interpreter. I've attached an output from IPython interpreter.

Georg, Given Tim's additional insight, I'm inclined to reopen the issue and review the patch as a positive change. Though not a bug, but as an enhancement for learners to copy-paste doc code into an interpreter. Thoughts?

----------
Added file: http://bugs.python.org/file39130/Screen Shot 2015-04-19 at 12.19.07 PM.png

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

From report at bugs.python.org  Sun Apr 19 22:01:52 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 19 Apr 2015 20:01:52 +0000
Subject: [docs] [issue24013] Improve os.scandir() and DirEntry documentation
Message-ID: <1429473711.62.0.571757122461.issue24013@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

Victor Stinner's documentation for os.scandir and DirEntry is a great start (https://docs.python.org/dev/library/os.html#os.scandir), however there are a few mistakes in it, and a few ways I think it could be improved. Attaching a patch with the following overall changes:

1. Tweak the "see also" note on os.listdir() to mention *why* you'd want to use scandir -- namely that it includes file attribute info, and performance.
2. Move that str/bytes note in the scandir() docs down a bit, as I think that's really a detail and the other stuff is more important.
3. More details on why you'd want to use scandir -- to "increase the performance of code that also needs file type or file" -- and be more specific about what system calls are and are not required.
4. Replace "POSIX" with "Unix", per the rest of the os module docs when talking about generic Unix-like operating systems. It seems "POSIX" is used specifically when talking about the POSIX standard.
5. Remove half-true statement in DirEntry docs, "if a file is deleted between calling scandir and stat, a FileNotFoundError can be raised" -- but the method docs state that they specifically don't raise FileNotFoundError.
6. Removed "unfortunately, the behaviour of errors depends on the platform". This is always the case and doesn't add anything.
7. Tried to simplify and clarify the is_dir() and is_file() docs. Not sure I've succeeded here. This is hard!
8. Added "Availability: Unix, Windows." to scandir docs like listdir and most other os functions have.
9. Remove the see also about how "the listdir function returns the names of the directory entries" as that's already stated/implied above.

----------
assignee: docs at python
components: Documentation
files: scandir_doc_tweaks.patch
keywords: patch
messages: 241560
nosy: benhoyt, docs at python, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve os.scandir() and DirEntry documentation
versions: Python 3.5
Added file: http://bugs.python.org/file39131/scandir_doc_tweaks.patch

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

From report at bugs.python.org  Mon Apr 20 02:25:07 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 20 Apr 2015 00:25:07 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429489506.74.0.51750626217.issue24005@psf.upfronthosting.co.za>


Berker Peksag added the comment:

That document is 10 years old :) I don't think it's worth to change now. Also, "what's new" documents shouldn't be used as a tutorial. There are many tutorials about writing decorators on the internet.

(Thanks for the report and the patch, Jaivish)

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

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

From report at bugs.python.org  Mon Apr 20 03:25:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Apr 2015 01:25:10 +0000
Subject: [docs] [issue22468] Tarfile using fstat on GZip file object
In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za>
Message-ID: <1429493110.54.0.157522754466.issue22468@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am posting a documentation patch which I hope should clarify that objects like GzipFile won?t work automatically with gettarinfo(). It also has other modifications to address Issue 21996 (name must be text) and help with Issue 22208 (clarify non-OS files won?t work).

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file39136/gettarinfo.patch

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

From report at bugs.python.org  Mon Apr 20 03:28:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Apr 2015 01:28:32 +0000
Subject: [docs] [issue21996] gettarinfo method does not handle files without
	text	string names
In-Reply-To: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za>
Message-ID: <1429493311.97.0.483525671828.issue21996@psf.upfronthosting.co.za>


Martin Panter added the comment:

Over in Issue 22468, I posted a documentation patch which includes wording to address this bug.

----------

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

From report at bugs.python.org  Mon Apr 20 04:25:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Apr 2015 02:25:31 +0000
Subject: [docs] [issue13386] Document documentation conventions for optional
	args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1429496731.21.0.238462293514.issue13386@psf.upfronthosting.co.za>


Martin Panter added the comment:

When a parameter is optional but does not have a simple default value, I suggest using some obviously invalid pseudocode, such as

function(arg1, arg2=<automatic, see text>)

See Issue 8706 about adding more support for keyword arguments. See also Issue 23738 for signatures that incorrectly appear to accept keywords due to including default values, and PEP 457?s slash (/) indicator for documenting positional-only parameters.

----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Apr 20 04:30:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Apr 2015 02:30:04 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1429497004.21.0.00425339752102.issue23738@psf.upfronthosting.co.za>


Martin Panter added the comment:

Of course in a new release, the functions could actually grow support for keywords, sidestepping the problem. Issue 8706 proposes to do this.

And see Issue 13386 about the conventions for optional arguments more generally.

----------

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

From report at bugs.python.org  Mon Apr 20 06:05:23 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2015 04:05:23 +0000
Subject: [docs] [issue23986] Inaccuracy about "in" keyword for list and tuple
In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za>
Message-ID: <1429502723.9.0.506212300842.issue23986@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll add James' suggested wording, but with the reversed-order suggested by David Murray.

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

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

From report at bugs.python.org  Mon Apr 20 06:09:17 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Apr 2015 04:09:17 +0000
Subject: [docs] [issue13386] Document documentation conventions for optional
	args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1429502957.01.0.224377167748.issue13386@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please don't add a new notation that makes the docs less readable than they are now.  For the most part, the existing docs have done a great job communicating how to use our functions.  Please don't undo 20 years of tradition because it bugs you.

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

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

From report at bugs.python.org  Mon Apr 20 07:03:38 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Apr 2015 05:03:38 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1429506218.71.0.857045514073.issue24005@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Yeah, agreed.

----------

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

From report at bugs.python.org  Mon Apr 20 07:14:47 2015
From: report at bugs.python.org (Tim Golden)
Date: Mon, 20 Apr 2015 05:14:47 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429489506.74.0.51750626217.issue24005@psf.upfronthosting.co.za>
Message-ID: <55348B41.9070504@timgolden.me.uk>


Tim Golden added the comment:

(Laughs). I admit, I was so close to the trees, I missed the fact that 
the doc is, as you say, a What's New, and for Python 2.4. Agree that to 
change this now would be somewhat ludicrous.

If some similar patch were proposed to some more current, relevant 
document I'd still be at least open to the change proposed for the 
reasons I gave but let's close this one now.

----------

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

From report at bugs.python.org  Mon Apr 20 17:29:23 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 20 Apr 2015 15:29:23 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429543763.14.0.847919882238.issue23987@psf.upfronthosting.co.za>


Ethan Furman added the comment:

So something like:

For container types such as list, tuple, or collections.deque, the expression 'x in y' is equivalent to 'any(x is e or x == e for e in y)'.  For container types such as set, frozenset, and dict, this equivalence expression is modified by the addition of 'if hash(x) == hash(e)'.

?

----------

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

From report at bugs.python.org  Mon Apr 20 18:09:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Apr 2015 16:09:50 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429546189.97.0.737296535784.issue23987@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, that's what I had in mind.

----------

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

From report at bugs.python.org  Mon Apr 20 21:57:55 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Apr 2015 19:57:55 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1429559875.27.0.677537236456.issue16574@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Patch LGTM.

----------

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

From report at bugs.python.org  Mon Apr 20 22:47:44 2015
From: report at bugs.python.org (VanL)
Date: Mon, 20 Apr 2015 20:47:44 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <1429562864.7.0.370887999309.issue23989@psf.upfronthosting.co.za>


VanL added the comment:

Given the generally positive comments, here are patches for 2.7, 3.3, 3.4, and 3.5 (3.5 patch updated to also include urllib.request).

----------
Added file: http://bugs.python.org/file39153/recommend_requests_2.patch

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

From report at bugs.python.org  Mon Apr 20 23:25:58 2015
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 20 Apr 2015 21:25:58 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <1429565158.53.0.600138673535.issue23989@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Tue Apr 21 00:22:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Apr 2015 22:22:43 +0000
Subject: [docs] [issue23989] Add recommendation to use requests to the
	documentation, per summit
In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za>
Message-ID: <20150420222241.30337.14281@psf.io>


Roundup Robot added the comment:

New changeset c9239543235e by Benjamin Peterson in branch '3.4':
recommend requests library (closes #23989)
https://hg.python.org/cpython/rev/c9239543235e

New changeset 3cf2990d19ab by Benjamin Peterson in branch '2.7':
recommend requests library (closes #23989)
https://hg.python.org/cpython/rev/3cf2990d19ab

New changeset 65ce1d9eee30 by Benjamin Peterson in branch 'default':
merge 3.4 (#23989)
https://hg.python.org/cpython/rev/65ce1d9eee30

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

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

From report at bugs.python.org  Tue Apr 21 04:30:09 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Apr 2015 02:30:09 +0000
Subject: [docs] [issue23987] docs about containers membership testing wrong
	for	broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1429583409.32.0.576799115894.issue23987@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

There is a separate report for taking care of the identity check for contains:  https://bugs.python.org/issue23986

I think notes about crazy hashes shouldn't spill all over our docs.  At best, it warrants a FAQ entry about how hash tables work.

The risk here is that in an effort to be more precise, it is easy impair the usability of the docs.  The wording in question has been around for a very long time and has overall done a good job of explaining the intent of the in-operator to all but the most pedantic reader, "The operators 'in' and 'not in' test for membership. 'x in s' evaluates to true if x is a member of s, and false otherwise."

If you really want to be precise, the *only* thing that can be broadly stated about the in-operator is that it calls __contains__ on an object that that object can implement whatever logic it wants (hash table lookup, linear search, google search, random result, etc).  But then, this is no different than most magic methods in that regard.

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

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

From report at bugs.python.org  Tue Apr 21 15:42:25 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Apr 2015 13:42:25 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
Message-ID: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In order to work correctly, threading.local() must be run in global scope, yet that tidbit is missing from both the docs and the _threading_local.py file.

Something like:

.. note::
   threading.local() must be run at global scope to function properly.

That would have saved me hours of time.  Thank goodness for SO!  ;)

----------
assignee: docs at python
messages: 241713
nosy: docs at python, ethan.furman
priority: normal
severity: normal
status: open
title: threading.local() must be run at module level (doc improvement)
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 21 16:00:21 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 21 Apr 2015 14:00:21 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429624821.5.0.944414118077.issue24020@psf.upfronthosting.co.za>


eryksun added the comment:

Could you clarify what the problem is? I have no apparent problem using threading.local in a function scope:

    import threading

    def f():
        tlocal = threading.local()
        tlocal.x = 0
        def g():
            tlocal.x = 1
            print('tlocal.x in g:', tlocal.x)
        t = threading.Thread(target=g)
        t.start()
        t.join()
        print('tlocal.x in f:', tlocal.x)

    >>> f()
    tlocal.x in g: 1
    tlocal.x in f: 0

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

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

From report at bugs.python.org  Tue Apr 21 16:27:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Apr 2015 14:27:50 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429626470.53.0.659199633216.issue24020@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also, don't use a ".. note::", regular sentences work fine, especially in documentation that is already very short.

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

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

From report at bugs.python.org  Tue Apr 21 17:43:36 2015
From: report at bugs.python.org (Karl Richter)
Date: Tue, 21 Apr 2015 15:43:36 +0000
Subject: [docs] [issue24021] document urllib.urlretrieve
Message-ID: <1429631016.69.0.328271522633.issue24021@psf.upfronthosting.co.za>


Changes by Karl Richter <krichter722 at aol.de>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: document urllib.urlretrieve
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 21 17:44:53 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Apr 2015 15:44:53 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429631093.8.0.165246986635.issue24020@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Raymond, okay, thanks.

Eryksun, I've written a FUSE file system (for $DAYJOB) and when I switched over to using threads I would occasionally experience errors such as 'thread.local object does not have attribute ...'; as soon as I found the SO answer and moved the call to 'threading.local()' to the global scope, the problem vanished.

To reliably detect the problem I started approximately 10 threads, each getting an os.listdir() 1,000 times of an area on the FUSE.

----------

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

From report at bugs.python.org  Tue Apr 21 17:51:17 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 21 Apr 2015 15:51:17 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429631477.73.0.153678192615.issue24020@psf.upfronthosting.co.za>


Paul Moore added the comment:

Link to the SO answer? Does it explain *why* this is a requirement?

----------
nosy: +paul.moore

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

From report at bugs.python.org  Tue Apr 21 18:19:21 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Apr 2015 16:19:21 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429633161.55.0.0797261151345.issue24020@psf.upfronthosting.co.za>


Ethan Furman added the comment:

http://stackoverflow.com/q/1408171/208880

No, it just says (towards the top):
----------------------------------
> One important thing that everybody seems to neglect to mention is that writing
> threadLocal = threading.local() at the global level is required. Calling
> threading.local() within the worker function will not work.

It is now my experience that "will not work" (reliably) is accurate.

----------

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

From report at bugs.python.org  Tue Apr 21 20:48:09 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 21 Apr 2015 18:48:09 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429642088.98.0.304114133709.issue24020@psf.upfronthosting.co.za>


Paul Moore added the comment:

That seems to merely be saying that each threading.local() object is distinct, so if you want to share threadlocal data between workers, creating local objects won't work.

I think I see what the confusion is (although I can't quite explain it yet, I'll need to think some more about it) but "threading.local() needs to be run at global scope" is not accurate (for example, if I understand correctly, a class attribute which is a threading.local value would work fine, and it's not "global scope".

Basically, each time you call threading.local() you get a brand new object. It looks like a dictionary, but in fact it's a *different* dictionary for each thread. Within one thread, though, you can have multiple threading.local() objects, and they are independent.

The "wrong" code in the SO discussion created a new threading-local() object as a local variable in a function, and tried to use it to remember state from one function call to the next (like a C static variable). That would be just as wrong in a single-threaded program where you used dict() instead of threading.local(), and for the same reasons.

I don't know what your code was doing, so it may well be that the problem you were encountering was more subtle than the one on the wont_work() function. But "threading.local() must be run in global scope" is *not* the answer (even if doing that resulted in your problem going away).

----------

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

From report at bugs.python.org  Tue Apr 21 20:48:59 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 21 Apr 2015 18:48:59 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429642139.64.0.605001315496.issue24020@psf.upfronthosting.co.za>


Paul Moore added the comment:

I should also say, I'll try to work up a doc patch for this, once I've got my head round how to explain it :-)

----------

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

From report at bugs.python.org  Tue Apr 21 21:11:41 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Apr 2015 19:11:41 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429643501.58.0.53381308846.issue24020@psf.upfronthosting.co.za>


Eric Snow added the comment:

FYI, I've used thread-local namespaces with success in several different ways and none of them involved binding the thread-local namespace to global scope.  I don't think anything needs to be fixed here.

The SO answer is misleading and perhaps even wrong.  The problem it describes is about sharing the thread-local NS *between function calls*.  Persisting state between function calls is not a new or mysterious problem, nor unique to thread-local namespaces.  In the example they give, rather than a global they could have put it into a default arg or into a class:

def hi(threadlocal=threading.local()):
    ...

class Hi:
    threadlocal = threading.local()
    def __call__(self):
        ...  # change threadlocal to self.threadlocal

hi = Hi()

This is simply a consequence of Python's normal scoping rules (should be unsurprising) and the fact that threading.local is a class (new instance per call) rather than a function (with the assumption of a singleton namespace per thread).

At most the docs could be a little more clear that threading.local() produces a new namespace each time.  However, I don't think even that is necessary and suggest closing this as won't fix.

----------
nosy: +eric.snow

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

From report at bugs.python.org  Tue Apr 21 21:52:27 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 21 Apr 2015 19:52:27 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429645947.91.0.01405590721.issue24020@psf.upfronthosting.co.za>


Paul Moore added the comment:

You're right, the SO answer is simply wrong. I've posted a (hopefully clearer) answer. If anyone wants to check it for accuracy, that'd be great.

Agreed this can probably be closed as "not a bug". On first reading, I thought the docs could do with clarification, but now I think that was just because I had been confused by the SO posting :-)

----------

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

From report at bugs.python.org  Tue Apr 21 23:53:42 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Apr 2015 21:53:42 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429653222.57.0.419024342923.issue24020@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr 22 00:11:31 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Apr 2015 22:11:31 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429654291.69.0.531040420652.issue24020@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Here's a basic outline of what I was trying:
-------------------------------------------

CONTEXT = None

class MyFUSE(Fuse):

   def __call__(self, op, path, *args):
      global CONTEXT
      ...
      CONTEXT = threading.local()
      # set several CONTEXT vars
      ...
      # dispatch to correct function to handle 'op'

Under stress, I would eventually get threading.local objects that were missing attributes.

Points to consider:
- I have no control over the threads; they just arrive wanting their
  'op's fulfilled
- the same thread can be a repeat customer, but with the above scenario they would/should
  get a new threading.local each time

Hmmm... could my problem be that even though function locals are thread-safe, the globals are not, so trying to create a threading.local via a global statement was clobbering other threading.local instances?  While that would make sense, I'm still completely clueless why having a single global statement, which (apparently) creates a single threading.local object, could be distinct for all the threads... unless, of course, it can detect which thread is accessing it and react appropriately.  Okay, that's really cool.

So I was doing two things wrong:
- calling threading.local() inside a function (although this would
  probably work if I then passed that object around, as I do not
  need to persist state across function calls -- wait, that would
  be the same as using an ordinary, function-local dict, wouldn't
  it?)
- attempting to assign the threading.local object to a global
  variable from inside a function (this won't work, period)

Many thanks for helping me figure that out.

Paul, in your SO answer you state:
---------------------------------
Just like an ordinary object, you can create multiple threading.local instances in your code. They can be local variables, class or instance members, or global variables.

- Local variables are already thread-safe, aren't they?  So there
  would be no point in using threading.local() there.
- Instance members (set from __init__ of someother method): wouldn't
  that be the same problem I was having trying to update a
  non-threadsafe global with a new threading.local() each time?

It seems to me the take-away here is that you only want to create a threading.local() object /once/ -- if you are creating the same threading.local() object more than once, you're doing it wrong.

----------

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

From report at bugs.python.org  Wed Apr 22 00:25:30 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Apr 2015 22:25:30 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429655130.24.0.239549024623.issue24020@psf.upfronthosting.co.za>


Eric Snow added the comment:

@Ethan, it may help you to read through the module docstring in Lib/_threading_local.py.

----------

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

From report at bugs.python.org  Wed Apr 22 00:29:57 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 21 Apr 2015 22:29:57 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429654291.69.0.531040420652.issue24020@psf.upfronthosting.co.za>
Message-ID: <CACac1F96jkkVpY24ckcY+_0m0B9dwbPoRfip7YFZb3D3=DQ=Qg@mail.gmail.com>


Paul Moore added the comment:

On 21 April 2015 at 23:11, Ethan Furman <report at bugs.python.org> wrote:
> Hmmm... could my problem be that even though function locals are thread-safe, the globals are not, so trying to create a threading.local via a global statement was clobbering other threading.local instances?  While that would make sense, I'm still completely clueless why having a single global statement, which (apparently) creates a single threading.local object, could be distinct for all the threads... unless, of course, it can detect which thread is accessing it and react appropriately.  Okay, that's really cool.

You're not creating a single threading object. You're creating one
each call() and overwriting the old one.

> So I was doing two things wrong:
> - calling threading.local() inside a function (although this would
>   probably work if I then passed that object around, as I do not
>   need to persist state across function calls -- wait, that would
>   be the same as using an ordinary, function-local dict, wouldn't
>   it?)

Yes, a dict should be fine if you're only using it within the one function call.

> - attempting to assign the threading.local object to a global
>   variable from inside a function (this won't work, period)

It does work, it's just there isn't *the* object, there's lots and you
keep overwriting.

The thread safety issue is that if you write over the global in one
thread, before another thread has finished, you lose the second
thread's values (because they were on the old, lost, namespace. So
basically you'd see unpredictable, occasional losses of all your
CONTEXT vars in a thread.

> Many thanks for helping me figure that out.

(If you did :-) - hope the clarifications above helped).

> Paul, in your SO answer you state:
> ---------------------------------
> Just like an ordinary object, you can create multiple threading.local instances in your code. They can be local variables, class or instance members, or global variables.
>
> - Local variables are already thread-safe, aren't they?  So there
>   would be no point in using threading.local() there.

Not unless you're going to return them from your function, or
something like that. But yes, it's unlikely they will be needed there.
I only mentioned it to avoid giving any impression that "only set at
global scope" was important.

> - Instance members (set from __init__ of someother method): wouldn't
>   that be the same problem I was having trying to update a
>   non-threadsafe global with a new threading.local() each time?

You'd set vars on the namespace held in the instance variable. It's
much like the local variable case, except you are more likely to pass
an instance around between threads.

> It seems to me the take-away here is that you only want to create a threading.local() object /once/ -- if you are creating the same threading.local() object more than once, you're doing it wrong.

Well, sort of. You can only create *any* object once :-) There seems
to be a confusion (in the SO thread and with you, maybe) that
threading.local objects are somehow singletons in that you "create"
them repeatedly and get the same object. That's just wrong - they are
entirely normal objects, that you can set arbitrary attributes on. The
only difference is that each thread sees an independent set of
attributes on the object.

----------

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

From report at bugs.python.org  Wed Apr 22 00:34:42 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Apr 2015 22:34:42 +0000
Subject: [docs] [issue24020] threading.local() must be run at module level
	(doc	improvement)
In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za>
Message-ID: <1429655682.28.0.603601265872.issue24020@psf.upfronthosting.co.za>


Eric Snow added the comment:

Think of threading.local this way: instances of threading.local are shared between all the threads, but the effective "__dict__" of each instance is per-thread.  Basically, the object stores a dict for each thread.  In __getattribute__, __setattr__, and __delattr__ it swaps the dict for the current thread into place and then does proceeds normally.

----------

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

From report at bugs.python.org  Wed Apr 22 01:47:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Apr 2015 23:47:02 +0000
Subject: [docs] [issue15183] it should be made clear that the statement in
	the	--setup option and the setup kw arg aren't included in the count
In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za>
Message-ID: <20150421234659.18895.73411@psf.io>


Roundup Robot added the comment:

New changeset e0e3d2ec56b6 by Andrew Kuchling in branch '3.4':
#15183: clarify timeit documentation to say that setup statement isn't timed
https://hg.python.org/cpython/rev/e0e3d2ec56b6

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

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

From report at bugs.python.org  Wed Apr 22 01:47:42 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 21 Apr 2015 23:47:42 +0000
Subject: [docs] [issue15183] it should be made clear that the statement in
	the	--setup option and the setup kw arg aren't included in the count
In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za>
Message-ID: <1429660062.5.0.429133472845.issue15183@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Committed to 3.4 and default.  Thanks for your patch!

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

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

From report at bugs.python.org  Wed Apr 22 02:00:28 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 22 Apr 2015 00:00:28 +0000
Subject: [docs] [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <1429660828.44.0.634510288014.issue22785@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

(By the time I got to the source, the word "virtual" had been removed...)

Attached is a patch to make the help read:

 |  range(stop) -> range object
 |  range(start, stop[, step]) -> range object
 |
 |  Return an object that produces a sequence of integers from start (inclusive)
 |  to stop (exclusive) by step.  range(i, j) produces i, i+1, i+2, ..., j-1.
 |  start defaults to 0, and stop is omitted!  range(4) produces 0, 1, 2, 3.
 |  These are exactly the valid indices for a list of 4 elements.
 |  When step is given, it specifies the increment (or decrement).

----------
keywords: +patch
Added file: http://bugs.python.org/file39163/22785.patch

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

From report at bugs.python.org  Wed Apr 22 02:16:10 2015
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 22 Apr 2015 00:16:10 +0000
Subject: [docs] [issue2716] Document license under which audioop is used
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1429661769.59.0.912848639856.issue2716@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Van: what do you think?  I can prepare a patch for Aaron's suggested changes.

----------
nosy: +akuchling, vanl

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

From report at bugs.python.org  Wed Apr 22 04:35:21 2015
From: report at bugs.python.org (Carol Willing)
Date: Wed, 22 Apr 2015 02:35:21 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1429670121.08.0.622118695861.issue16574@psf.upfronthosting.co.za>


Changes by Carol Willing <willingc at willingconsulting.com>:


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

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

From report at bugs.python.org  Wed Apr 22 05:23:46 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Apr 2015 03:23:46 +0000
Subject: [docs] [issue24021] document urllib.urlretrieve
Message-ID: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>


New submission from Berker Peksag:

urllib.urlretrieve is already documented at https://docs.python.org/2.7/library/urllib.html#urllib.urlretrieve Can you please give us more information about your problem with the urllib.urlretrieve documentation?

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

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

From report at bugs.python.org  Wed Apr 22 06:05:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Apr 2015 04:05:41 +0000
Subject: [docs] [issue13814] Document why generators don't support the
	context	management protocol
In-Reply-To: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za>
Message-ID: <1429675541.17.0.23262253856.issue13814@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Wed Apr 22 06:10:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Apr 2015 04:10:12 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>
Message-ID: <1429675812.27.0.9971169163.issue23227@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Wed Apr 22 06:13:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Apr 2015 04:13:39 +0000
Subject: [docs] [issue24021] document urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <1429676019.01.0.670492546889.issue24021@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect the complaint might be about the lack of doc string, but a more specific bug report would be nice to clarify this.

$ pydoc2 urllib.urlretrieve
Help on function urlretrieve in urllib:

urllib.urlretrieve = urlretrieve(url, filename=None, reporthook=None, data=None, context=None)

$

----------
nosy: +vadmium

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

From report at bugs.python.org  Wed Apr 22 06:53:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Apr 2015 04:53:05 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <20150422045302.98628.4693@psf.io>


Roundup Robot added the comment:

New changeset 0c4006b7c7ff by Berker Peksag in branch 'default':
Issue #16574: Clarify that once a PEP has implemented, it needs be
https://hg.python.org/devguide/rev/0c4006b7c7ff

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

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

From report at bugs.python.org  Wed Apr 22 06:53:32 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Apr 2015 04:53:32 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1429678412.44.0.489255996905.issue16574@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

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

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

From vadmium+py at gmail.com  Wed Apr 22 06:01:59 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 22 Apr 2015 04:01:59 -0000
Subject: [docs] Document why generators don't support the context
 management protocol (issue 13814)
Message-ID: <20150422040159.17918.962@psf.upfronthosting.co.za>


https://bugs.python.org/review/13814/diff/14541/Doc/faq/design.rst
File Doc/faq/design.rst (right):

https://bugs.python.org/review/13814/diff/14541/Doc/faq/design.rst#newcode829
Doc/faq/design.rst:829: Why don't generators support the with statement?
Perhaps put quotes around the keyword so that it doesn?t choke my
English grammar parser (consistent with the existing section about
attribute assignments):

Why don't generators support the "with" statement?

https://bugs.python.org/review/13814/diff/14541/Doc/faq/design.rst#newcode832
Doc/faq/design.rst:832: Any time you use generators to create context
managers you have to add a @contextmanager decorator.
Just a technicality, but you don?t _have_ to use that decorator. I
sometimes find myself using closing(generator) directly when I want my
generator-cum-context-manager to have more than one yield step. How
about:

Generators are often used to create context managers with the
:class:`contextlib.contextmanager` decorator.

https://bugs.python.org/review/13814/diff/14541/Doc/faq/design.rst#newcode837
Doc/faq/design.rst:837: lot harder to find and fix. Automatically
closing your generator can just as easily be done with
contextlib.closing()
Please link to :func:`contextlib.closing` and end the sentence with a
full stop.

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

From report at bugs.python.org  Wed Apr 22 09:12:25 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Apr 2015 07:12:25 +0000
Subject: [docs] [issue15657] Error in Python 3 docs for PyMethodDef
In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>
Message-ID: <1429686745.2.0.697043833599.issue15657@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a patch for Python 3.5.

----------
components: +Interpreter Core -Documentation
keywords: +patch
nosy: +berker.peksag, serhiy.storchaka
type:  -> behavior
versions: +Python 3.5 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file39164/issue15657.diff

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

From report at bugs.python.org  Wed Apr 22 11:10:09 2015
From: report at bugs.python.org (Karl Richter)
Date: Wed, 22 Apr 2015 09:10:09 +0000
Subject: [docs] [issue24021] document urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <1429693809.4.0.416894275224.issue24021@psf.upfronthosting.co.za>


Karl Richter added the comment:

> I suspect the complaint might be about the lack of doc string
Exactly. It'd be helpful to figure out the return value and the means of the function arguments in a more compact form than the referenced website docs and to have it available in the interpreter (with `help`), i.e. with docstring documentation.

----------

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

From report at bugs.python.org  Wed Apr 22 12:17:12 2015
From: report at bugs.python.org (Marco Paolini)
Date: Wed, 22 Apr 2015 10:17:12 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>
Message-ID: <1429697832.04.0.661077443795.issue23227@psf.upfronthosting.co.za>


Marco Paolini added the comment:

I think there is an issue in the way you designed your cleanup logic. So I think this issue is invalid.

Usually, the code (funcion, class, ...) that *opens* the file should also be resposible of closing it.

option 1) the caller opens and closes the file and wrapping the logged lines in a try/finally


def logged_lines(f):
    try:
        for line in f:
            logging.warning(line.strip())
            yield line
    finally:
        logging.warning('closing')


f = open('yyy', 'r')
try:
    for l in logged_lines(f):
       print(l)
finally:
    f.close()


option 2) the funcion opens and closes the file

def logged_lines(fname):
    f = open('yyy', 'r')
    try:
        for line in f:
            logging.warning(line.strip())
            yield line
    finally:
        logging.warning('closing')
        f.close()

for l in logged_lines('yyy'):
   print(l)

----------
nosy: +mpaolini

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

From report at bugs.python.org  Wed Apr 22 15:16:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Apr 2015 13:16:38 +0000
Subject: [docs] [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <20150422131634.98630.24478@psf.io>


Roundup Robot added the comment:

New changeset aa6b73823685 by Benjamin Peterson in branch '3.4':
improved range docstring (closes #22785)
https://hg.python.org/cpython/rev/aa6b73823685

New changeset c031fa8e6884 by Benjamin Peterson in branch 'default':
merge 3.4 (#22785)
https://hg.python.org/cpython/rev/c031fa8e6884

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

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

From report at bugs.python.org  Wed Apr 22 17:19:43 2015
From: report at bugs.python.org (Pablo)
Date: Wed, 22 Apr 2015 15:19:43 +0000
Subject: [docs] [issue24027] IMAP library lacks documentation about
	expected	parameter types
Message-ID: <1429715983.31.0.608966950375.issue24027@psf.upfronthosting.co.za>


New submission from Pablo:

I used the IMAP library and I feel it lacks a lot of documentation regarding types and encoding.

Example:
IMAP4.list([directory[, pattern]]):
It doesn't state if it expects the directory argument to be an string (unicode) or a imap_utf7 encoded string or bytes.
It also expects names with spaces to be between double quotation marks and it doesn't state that it returns a bytes raw output.

This is valid for every function that receives a directory or mailbox argument. Also for most return values.

Documentation aside, I think it would be a nice improvement in the implementation to add an imap_utf7 convertion function, and check every directory or mailbox argument to see if it has characters outside the imap_utf7 charset and attempts to convert them automatically.

----------
assignee: docs at python
components: Documentation
messages: 241812
nosy: docs at python, pmoleri
priority: normal
severity: normal
status: open
title: IMAP library lacks documentation about expected parameter types
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 22 18:34:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Apr 2015 16:34:51 +0000
Subject: [docs] [issue24027] IMAP library lacks documentation about
	expected	parameter types
In-Reply-To: <1429715983.31.0.608966950375.issue24027@psf.upfronthosting.co.za>
Message-ID: <1429720491.45.0.511641003195.issue24027@psf.upfronthosting.co.za>


R. David Murray added the comment:

Documentation patches are welcome.  imaplib has not seen much attention for quite some time (though there is currently someone interested in working on it, so that may change).

Please open a separate issue for the utf7 enhancement proposal.

----------
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.5

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

From report at bugs.python.org  Thu Apr 23 01:11:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Apr 2015 23:11:08 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>
Message-ID: <1429744268.0.0.406760319132.issue23227@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This looks logical to me. The "finally" block is only entered if the "try" block is ever entered, but if you don't consume anything in the generator then the generator's code is never actually executed.

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

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

From report at bugs.python.org  Fri Apr 24 02:47:09 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 24 Apr 2015 00:47:09 +0000
Subject: [docs] [issue24045] Behavior of large returncodes  (sys.exit(nn))
Message-ID: <1429836429.07.0.888331603842.issue24045@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Not sure if this is a bug, or just One of Those Things:

sys.exit(large_value) can wrap around if the value is too large, but this is O/S dependent.

linux (ubuntu 14.04)

  $ python
  Python 2.7.8 (default, Oct 20 2014, 15:05:29) 
  [GCC 4.9.1] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  --> import sys
  --> sys.exit(256)
  $ echo $?
  0

  $ python
  Python 2.7.8 (default, Oct 20 2014, 15:05:29) 
  [GCC 4.9.1] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  --> import sys
  --> sys.exit(257)
  $ echo $?
  1

M$ (Windows 7)

  > python
  Python 2.7... 
  --> import sys
  --> sys.exit(65535)
  > echo %errorlevel%
  65535

  > python
  Python 2.7...
  --> import sys
  --> sys.exit(100000)
  > echo %errorlevel%
  100000

Perhaps a minor doc update that talks about return codes and why they might not be exactly what was given to Python?

----------
assignee: docs at python
messages: 241903
nosy: docs at python, ethan.furman
priority: normal
severity: normal
status: open
title: Behavior of large returncodes  (sys.exit(nn))
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Apr 24 07:17:33 2015
From: report at bugs.python.org (Stephen Drake)
Date: Fri, 24 Apr 2015 05:17:33 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>
Message-ID: <1429852653.38.0.0355970967883.issue23227@psf.upfronthosting.co.za>


Stephen Drake added the comment:

Ok, I can accept that.  I think my mistake was to assume that because a generator has a close() method, I could treat it as a lightweight wrapper for another closeable object.

But it's better to regard a generator function that wraps an iterable as something more akin to map() or filter(), and use a class if it's necessary to wrap a file such that close() is passed through.

I happened to take a fresh look at this just the other day and it also occurred to me that the kind of composition I was trying to do can work if it's generators all the way down:

def open_lines(name, mode='rt', buffering=-1):
    with open(name, mode, buffering) as f:
        for line in f:
            yield line

def logged_lines(f):
    try:
        for line in f:
            logging.warning(line.strip())
            yield line
    finally:
        f.close()

lines = open_lines('yyy', 'r')
if verbose:
    lines = logged_lines(lines)
try:
    for line in lines:
        print(line)
finally:
    lines.close()

So a generator can transparently wrap a plain iterable or another generator, but not closeable objects in general.  There's nothing really wrong with that, so I'm happy for this issue to be closed as invalid.

----------

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

From report at bugs.python.org  Fri Apr 24 12:29:04 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Apr 2015 10:29:04 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>
Message-ID: <1429871344.02.0.10861646742.issue23356@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM

----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag
stage:  -> commit review
type: performance -> enhancement
versions: +Python 3.5

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

From report at bugs.python.org  Fri Apr 24 18:22:06 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 24 Apr 2015 16:22:06 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>
Message-ID: <1429892526.01.0.11402320363.issue23356@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


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

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

From report at bugs.python.org  Sat Apr 25 08:55:58 2015
From: report at bugs.python.org (Novice Live)
Date: Sat, 25 Apr 2015 06:55:58 +0000
Subject: [docs] [issue24057] trivial typo in datetime.rst: needing a
	preceding dot
Message-ID: <1429944958.51.0.607005729778.issue24057@psf.upfronthosting.co.za>


New submission from Novice Live:

a non-trivial dot is needed for the hyperlink to make sense, or the link will jump to the start of the documentation, which doesn't make sense. 

the same typo as in http://bugs.python.org/issue23561.

----------
assignee: docs at python
components: Documentation
files: datetime_typo.patch
keywords: patch
messages: 241998
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: trivial typo in datetime.rst: needing a preceding dot
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39202/datetime_typo.patch

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

From report at bugs.python.org  Sat Apr 25 17:09:09 2015
From: report at bugs.python.org (xiaobing jiang)
Date: Sat, 25 Apr 2015 15:09:09 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1429974549.15.0.338353615892.issue15329@psf.upfronthosting.co.za>


Changes by xiaobing jiang <s7v7nislands at gmail.com>:


----------
nosy: +s7v7nislands at gmail.com

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

From report at bugs.python.org  Sat Apr 25 17:09:40 2015
From: report at bugs.python.org (xiaobing jiang)
Date: Sat, 25 Apr 2015 15:09:40 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1429974580.96.0.788076397991.issue15339@psf.upfronthosting.co.za>


Changes by xiaobing jiang <s7v7nislands at gmail.com>:


----------
nosy: +s7v7nislands at gmail.com

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

From report at bugs.python.org  Sat Apr 25 17:29:31 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Apr 2015 15:29:31 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1429975771.33.0.560018314604.issue15339@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> 

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

From report at bugs.python.org  Sat Apr 25 20:16:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Apr 2015 18:16:33 +0000
Subject: [docs] [issue24057] trivial typo in datetime.rst: needing a
	preceding dot
In-Reply-To: <1429944958.51.0.607005729778.issue24057@psf.upfronthosting.co.za>
Message-ID: <20150425181630.27930.89608@psf.io>


Roundup Robot added the comment:

New changeset 875787fee2cc by Benjamin Peterson in branch '3.4':
fix relative link (closes #24057)
https://hg.python.org/cpython/rev/875787fee2cc

New changeset 4e48a55cffb8 by Benjamin Peterson in branch '2.7':
fix relative link (closes #24057)
https://hg.python.org/cpython/rev/4e48a55cffb8

New changeset 0351b0cb31d6 by Benjamin Peterson in branch 'default':
merge 3.4 (#24057)
https://hg.python.org/cpython/rev/0351b0cb31d6

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

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

From report at bugs.python.org  Sat Apr 25 23:17:04 2015
From: report at bugs.python.org (Karl Richter)
Date: Sat, 25 Apr 2015 21:17:04 +0000
Subject: [docs] [issue24060] Clearify necessities for logging with timestamps
Message-ID: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za>


New submission from Karl Richter:

The `Formatter` section of the `logging` module at https://docs.python.org/2/library/logging.html#formatter-objects reads like it's sufficient to create an instance of `Formatter` with default arguments (and set it as formatter of the `Handler` of a `Logger`) to have add timestamps to logging output.

----------
assignee: docs at python
components: Documentation
messages: 242024
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Clearify necessities for logging with timestamps
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 26 00:32:49 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Apr 2015 22:32:49 +0000
Subject: [docs] [issue24060] Clearify necessities for logging with timestamps
In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za>
Message-ID: <1430001169.39.0.18975746184.issue24060@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sun Apr 26 08:10:53 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 26 Apr 2015 06:10:53 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1430028653.17.0.593806861826.issue15339@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

This seems somewhat related to the "We need to document Python's concurrency and memory model" that came out at the language summit this year.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Sun Apr 26 11:10:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Apr 2015 09:10:32 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>
Message-ID: <20150426091029.129430.81031@psf.io>


Roundup Robot added the comment:

New changeset bd8b99034121 by Berker Peksag in branch '3.4':
Issue #23356: Simplify convert_arg_line_to_args example.
https://hg.python.org/cpython/rev/bd8b99034121

New changeset 2d3ed019bc9f by Berker Peksag in branch 'default':
Issue #23356: Simplify convert_arg_line_to_args example.
https://hg.python.org/cpython/rev/2d3ed019bc9f

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

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

From report at bugs.python.org  Sun Apr 26 11:12:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 26 Apr 2015 09:12:47 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>
Message-ID: <20150426091245.21329.63803@psf.io>


Roundup Robot added the comment:

New changeset 050e0c0b3d90 by Berker Peksag in branch '2.7':
Issue #23356: Simplify convert_arg_line_to_args example.
https://hg.python.org/cpython/rev/050e0c0b3d90

----------

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

From report at bugs.python.org  Sun Apr 26 11:14:04 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 26 Apr 2015 09:14:04 +0000
Subject: [docs] [issue23356] In argparse docs simplify example about argline
In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za>
Message-ID: <1430039644.09.0.335687801587.issue23356@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks py.user.

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

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

From report at bugs.python.org  Sun Apr 26 11:19:35 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 26 Apr 2015 09:19:35 +0000
Subject: [docs] [issue24021] Add docstring to urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <1430039975.55.0.987792017583.issue24021@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
title: document urllib.urlretrieve -> Add docstring to urllib.urlretrieve
type:  -> enhancement
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 26 20:47:33 2015
From: report at bugs.python.org (paul rubin)
Date: Sun, 26 Apr 2015 18:47:33 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1430074053.08.0.367265718472.issue5784@psf.upfronthosting.co.za>


paul rubin added the comment:

Hey, thanks for updating this.  I still remember the nasty incident that got me filing this report in the first place.  I'll look at the patch more closely when I get a chance, but the immediate comment I'd make is it's worth adding a sentence saying explicitly to use wbits=-15 if you need to interoperate with some other libraries like PHP, that strip off the header.

----------

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

From report at bugs.python.org  Sun Apr 26 21:14:18 2015
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 26 Apr 2015 19:14:18 +0000
Subject: [docs] [issue24062] links to os.stat() in documentation lead to
	stat module	instead
Message-ID: <1430075658.37.0.617374885608.issue24062@psf.upfronthosting.co.za>


New submission from July Tikhonov:

Documentation of os.fstat()
https://docs.python.org/3/library/os.html#os.fstat
has a "See also:" section, which features a wrong link. The same with os.lstat().

Some of this problem was fixed (among other things) in issue 10960. But since then, two more wrong links appeared.

Attached patch applies to 3.5, although 3.4 has the same problem.

----------
assignee: docs at python
components: Documentation
files: doc-library-os-stat-links.diff
keywords: patch
messages: 242070
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: links to os.stat() in documentation lead to stat module instead
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39209/doc-library-os-stat-links.diff

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

From report at bugs.python.org  Sun Apr 26 23:54:24 2015
From: report at bugs.python.org (Antti Haapala)
Date: Sun, 26 Apr 2015 21:54:24 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
	but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1430085264.7.0.627172810353.issue22057@psf.upfronthosting.co.za>


Antti Haapala added the comment:

+1 for this patch, the current documentation states it very wrong.

----------
nosy: +ztane

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

From report at bugs.python.org  Mon Apr 27 09:41:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Apr 2015 07:41:20 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
	but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1430120480.09.0.499392421051.issue22057@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good (though it would have been easier to check the diff if the text had not be reflowed).

I will apply it when I get a chance.  Or if anyone else wants to grab it, go ahead.

----------

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

From report at bugs.python.org  Mon Apr 27 12:53:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Apr 2015 10:53:59 +0000
Subject: [docs] [issue24062] links to os.stat() in documentation lead to
	stat module	instead
In-Reply-To: <1430075658.37.0.617374885608.issue24062@psf.upfronthosting.co.za>
Message-ID: <20150427105356.21349.19812@psf.io>


Roundup Robot added the comment:

New changeset 5850f0c17c34 by Berker Peksag in branch '3.4':
Issue #24062: Fix os.stat links. Patch by July Tikhonov.
https://hg.python.org/cpython/rev/5850f0c17c34

New changeset 18882c93f4bd by Berker Peksag in branch 'default':
Issue #24062: Fix os.stat links. Patch by July Tikhonov.
https://hg.python.org/cpython/rev/18882c93f4bd

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

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

From report at bugs.python.org  Mon Apr 27 12:55:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 27 Apr 2015 10:55:17 +0000
Subject: [docs] [issue24062] links to os.stat() in documentation lead to
	stat module	instead
In-Reply-To: <1430075658.37.0.617374885608.issue24062@psf.upfronthosting.co.za>
Message-ID: <1430132117.52.0.63374109693.issue24062@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, July.

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

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

From report at bugs.python.org  Mon Apr 27 19:02:43 2015
From: report at bugs.python.org (Davin Potts)
Date: Mon, 27 Apr 2015 17:02:43 +0000
Subject: [docs] [issue21791] Proper return status of os.WNOHANG is not
	always (0, 0)
In-Reply-To: <1403022188.82.0.702725813338.issue21791@psf.upfronthosting.co.za>
Message-ID: <1430154163.16.0.527436485875.issue21791@psf.upfronthosting.co.za>


Davin Potts added the comment:

The man pages for waitpid on OpenBSD 5.x do not suggest any meaningful value will be returned in status when WNOHANG is requested and no child processes have anything to report.

The following session attempts to exercise os.waitpid using Python 2.7.9 on an OpenBSD 5.3 i386 system:
>>> import os
>>> os.spawnl(os.P_NOWAIT, '/bin/sleep', 'sleep', '10')
19491
>>> os.waitpid(-1, os.WNOHANG)
(0, 0)
>>> os.waitpid(-1, os.WNOHANG)   # wait a few seconds, try again
(0, 0)
>>> os.waitpid(-1, os.WNOHANG)   # waited long enough for sleep to exit
(19491, 0)
>>> os.waitpid(-1, os.WNOHANG)   # at this point, no children remain
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 10] No child processes


Can you provide any further information, like:
* OpenBSD docs that explain that we should expect non-zero values for status coming from waitpid?
* Example Python code to provoke the behavior originally described?
* Other suggestion of why OpenBSD's waitpid, which itself depends upon wait4, when called (the way Python calls it) with an already initialized status=0 and WNOHANG should return a modified value for status when the child had nothing to report?

----------
nosy: +davin
status: open -> pending

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

From jacek at ivolution.pl  Wed Apr 29 13:03:38 2015
From: jacek at ivolution.pl (=?ISO-8859-2?Q?Jacek_Osta=F1ski?=)
Date: Wed, 29 Apr 2015 13:03:38 +0200
Subject: [docs] incorrect documentation
Message-ID: <CAC=ORhpqCNfVspvGWisH-9SRCFpg4EBOk1OmVjaBWnK+PZDsEA@mail.gmail.com>

Hello
http://screencast.com/t/sInPpwlQ
This seems to be wrong - there are only 60 seconds in second, according to
my research. And this 60th second is leap second.
Thanks
-- 
Jacek Osta?ski
Internet Evolution - Strony i serwisy Internetowe
608-230-735
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150429/a90985d2/attachment.html>

From report at bugs.python.org  Wed Apr 29 23:43:55 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Apr 2015 21:43:55 +0000
Subject: [docs] [issue24077] man page says -I implies -S. code says -s.
	Should it be	both?
In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za>
Message-ID: <1430343835.92.0.38063416981.issue24077@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From report at bugs.python.org  Wed Apr 29 23:46:43 2015
From: report at bugs.python.org (John Beck)
Date: Wed, 29 Apr 2015 21:46:43 +0000
Subject: [docs] [issue24077] man page says -I implies -S. code says -s.
In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za>
Message-ID: <1430344003.76.0.019611696462.issue24077@psf.upfronthosting.co.za>


John Beck added the comment:

Thank you very much for clarifying that.  I have updated the bug Title
accordingly.

----------
title: man page says -I implies -S. code says -s. Should it be both? -> man page says -I implies -S. code says -s.

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

From report at bugs.python.org  Wed Apr 29 23:54:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Apr 2015 21:54:00 +0000
Subject: [docs] [issue24077] man page says -I implies -S. code says -s.
In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za>
Message-ID: <20150429215357.1915.94928@psf.io>


Roundup Robot added the comment:

New changeset d774401879d8 by Ned Deily in branch '3.4':
Issue #24077: Fix typo in man page for -I command option: -s, not -S.
https://hg.python.org/cpython/rev/d774401879d8

New changeset 493b3310d5d0 by Ned Deily in branch 'default':
Issue #24077: merge from 3.4
https://hg.python.org/cpython/rev/493b3310d5d0

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

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

From report at bugs.python.org  Wed Apr 29 23:55:24 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 29 Apr 2015 21:55:24 +0000
Subject: [docs] [issue24077] man page says -I implies -S. code says -s.
In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za>
Message-ID: <1430344524.21.0.252539835163.issue24077@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report, John!

----------
nosy: +ned.deily
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Apr 29 23:59:26 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 29 Apr 2015 21:59:26 +0000
Subject: [docs] [issue24077] man page says -I implies -S. code says -s.
In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za>
Message-ID: <1430344766.4.0.150682945605.issue24077@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Thu Apr 30 04:35:08 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Apr 2015 02:35:08 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1430361308.06.0.832779387317.issue24079@psf.upfronthosting.co.za>


Ned Deily added the comment:

(This issue is a followup to your Issue24072.)  Again, while the ElementTree documentation is certainly not nearly as complete as it should be, I don't think this is a documentation error per se.  The key issue is: with which element is each text string associated?  Perhaps this example will help:

>>> root4 = ET.fromstring('<a>ATEXT<b>BTEXT</b>BTAIL</a>')
>>> root4
<Element 'a' at 0x10224c228>
>>> root4.text
'ATEXT'
>>> root4.tail
>>> root4[0]
<Element 'b' at 0x1022ab278>
>>> root4[0].text
'BTEXT'
>>> root4[0].tail
'BTAIL'

As in your original example, any text following the element b is associated with b's tail attribute until a new tag is found, pushing or popping the tree stack.  While the description of the "text" attribute does not explicitly state this, the "tail" attribute description immediately following it does.  This is also explained in more detail in the ElementTree resources on effbot.org that are linked to from the Python Standard Library documentation.  Nevertheless, it probably would be helpful to expand the documentation on this point if someone is willing to put together a documentation patch for review.

With regard to your comment about "well formed xml", I don't think there is anything in the documentation that implies (or should imply) that the distinction between the "text" attribute and the "tail" attribute has anything to do with whether it is well-formed XML.  The tutorial for the third-party lxml package, which provides another implementation of ElementTree, goes into more detail about why, in general, both "text" and "tail" are necessary.

https://docs.python.org/3/library/xml.etree.elementtree.html#additional-resources
http://effbot.org/zone/element.htm#text-content
http://lxml.de/tutorial.html#elements-contain-text

----------
assignee:  -> docs at python
components: +Documentation -XML
nosy: +docs at python, ned.deily
stage:  -> needs patch
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Thu Apr 30 06:31:42 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Thu, 30 Apr 2015 04:31:42 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1430368302.48.0.62904252482.issue24005@psf.upfronthosting.co.za>


Jaivish Kothari added the comment:

Thanks for support . I agree it is not a bug at all but just as Tim said it would be easy to copy paste code directly to interpreter with such changes. This was my first contribution in python though not accepted , it is ok :) . I'll try to contribute more towards it .Thanks for commenting . Could you guys suggest some issues i could work on as a beginner :)

----------

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

From report at bugs.python.org  Thu Apr 30 08:38:16 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Apr 2015 06:38:16 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1430375896.72.0.149694489298.issue24079@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> this is well formed xml and has nothing to do with tail.

In fact, it does have something to do with tail.
The 'TEXT' is a captured as the tail of element b:

>>> root3 = ET.fromstring('<a><b/>TEXT</a>')
>>> root3[0].tail
'TEXT'

----------
nosy: +eli.bendersky, rhettinger, scoder

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

From report at bugs.python.org  Thu Apr 30 09:04:40 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 30 Apr 2015 07:04:40 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1430377480.79.0.373009887305.issue24079@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I agree that the wording in the documentation isn't great:

"""
text

    The text attribute can be used to hold additional data associated with the element. As the name implies this attribute is usually a string but may be any application-specific object. If the element is created from an XML file the attribute will contain any text found between the element tags.

tail

    The tail attribute can be used to hold additional data associated with the element. This attribute is usually a string but may be any application-specific object. If the element is created from an XML file the attribute will contain any text found after the element?s end tag and before the next tag.
"""

Special cases that no-one uses (sticking non-string objects into text/tail) are given too much space and the difference isn't explained as needed.

Since the distinction between text and tail is a (great but) rather special feature of ElementTree, it needs to be given more room in the docs.

Proposal:

"""
text

    The text attribute holds the immediate text content of the element. It contains any text found up to either the closing tag if the element has no children, or the next opening child tag within the element. For text following an element, see the `tail` attribute. To collect the entire text content of a subtree, see `tostring`. Applications may store arbitrary objects in this attribute.

tail

    The tail attribute holds any text that directly follows the element. For example, in a document like ``<a>Text<b/>BTail<c/>CTail</a>``, the `text` attribute of the ``a`` element holds the string "Text", and the tail attributes of ``b`` and ``c`` hold the strings "BTail" and "CTail" respectively. Applications may store arbitrary objects in this attribute.
"""

----------

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

From report at bugs.python.org  Thu Apr 30 09:32:55 2015
From: report at bugs.python.org (Tim Golden)
Date: Thu, 30 Apr 2015 07:32:55 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1430368302.48.0.62904252482.issue24005@psf.upfronthosting.co.za>
Message-ID: <5541DAA0.3040805@timgolden.me.uk>


Tim Golden added the comment:

Jaivish Kothari,

Thanks for making the effort to contribute. Can I suggest you have a
look at the Core Mentorship site:

  http://pythonmentors.com/

and perhaps join the Core Mentorship list:

  http://mail.python.org/mailman/listinfo/core-mentorship

TJG

----------

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

From report at bugs.python.org  Thu Apr 30 13:35:53 2015
From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=)
Date: Thu, 30 Apr 2015 11:35:53 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1430393753.35.0.307735780067.issue24079@psf.upfronthosting.co.za>


J?r?me Laurens added the comment:

Since the text and tail notions seem tightly coupled, I would vote for a more detailed explanation in the text doc and a forward link in the tail documentation.


"""
text

    The text attribute holds the text between the element's begin tag and the next tag or None. The tail attribute holds the text between the element's end tag and the next tag or None. For "<a><b>1<c>2<d/>3</c></b>4</a>" xml data, the a element has None for both text and tail attributes, the b element has text '1' and tail '4', the c element has text '2' and tail None, the d element hast text None and tail '3'.

To collect the inner text of an element, see `tostring` with method 'text'.

Applications may store arbitrary objects in this attribute.

tail

    The tail attribute holds the text between the element's end tag and the next tag or None. See `text` for more details.

Applications may store arbitrary objects in this attribute.
"""

It is very important to mention that the 'text' attribute does not always hold a string contrary to what would suggest its name.

BTW, I was not aware of the tostring method with 'text' argument. The fact is that the documentation reads "Returns an (optionally) encoded string containing the XML data." which is misleading because the text is not xml data in general. This also needs to be rephrased or simply removed.

----------

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

From report at bugs.python.org  Thu Apr 30 16:12:35 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 30 Apr 2015 14:12:35 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
Message-ID: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

imp.reload() and importlib.reload() docs state::

    If a module is syntactically correct but its initialization fails, the first
    :keyword:`import` statement for it does not bind its name locally, but does
    store a (partially initialized) module object in ``sys.modules``.  To reload
    the module you must first :keyword:`import` it again (this will bind the name
    to the partially initialized module object) before you can :func:`reload` it.

If I reading that correctly, "initialization" refers to executing the module, so for module containing just::

    uninitialized_variable

the following::

    >>> import sys
    >>> import x
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/tmp/x.py", line 1, in <module>
        uninitialized_variable
    NameError: name 'uninitialized_variable' is not defined

should leave me with a initialized module in sys.modules['x']. However, this is not what happens, in either Python 3.4 or 2.7::

    >>> sys.modules['x']
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    KeyError: 'x'

Here's a patch to remove the caveat in Python 3 docs.
If I missed something, and "initialization" refers to something else, it should be clarified.

----------
assignee: docs at python
components: Documentation
files: 0001-Remove-obsolete-caveat-from-reload-docs.patch
keywords: patch
messages: 242270
nosy: docs at python, encukou
priority: normal
severity: normal
status: open
title: Obsolete caveat in reload() docs
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file39235/0001-Remove-obsolete-caveat-from-reload-docs.patch

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

From report at bugs.python.org  Thu Apr 30 16:19:30 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 30 Apr 2015 14:19:30 +0000
Subject: [docs] [issue24082] Obsolete note in argument parsing
	(c-api/arg.rst)
Message-ID: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

A note in the docs for the "u" format unit saus NULs are not allowed, but the previous sentence says they aren't accepted.

----------
assignee: docs at python
components: Documentation
files: 0002-Remove-obsolete-note-in-argument-parsing-docs.patch
keywords: patch
messages: 242271
nosy: docs at python, encukou
priority: normal
severity: normal
status: open
title: Obsolete note in argument parsing (c-api/arg.rst)
versions: Python 3.4
Added file: http://bugs.python.org/file39236/0002-Remove-obsolete-note-in-argument-parsing-docs.patch

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

From report at bugs.python.org  Thu Apr 30 17:43:08 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Apr 2015 15:43:08 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430408588.66.0.0584119739512.issue24081@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, eric.snow, ncoghlan

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

From report at bugs.python.org  Thu Apr 30 19:49:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Apr 2015 17:49:30 +0000
Subject: [docs] [issue24060] Clearify necessities for logging with timestamps
In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za>
Message-ID: <1430416170.51.0.970042303374.issue24060@psf.upfronthosting.co.za>


R. David Murray added the comment:

Not to my eyes.  It clearly says that if no formatting string is specified, the default is used, and that formatTime is used only if the message string contains asctime.  Up to Vinay whether he thinks it is worth adding something like "which does not include a reference to the date/time" after the mention of using the default message if fmt is not supplied.

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

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

From report at bugs.python.org  Thu Apr 30 19:56:16 2015
From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=)
Date: Thu, 30 Apr 2015 17:56:16 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1430416576.79.0.147338541378.issue24079@psf.upfronthosting.co.za>


J?r?me Laurens added the comment:

The totsstring(..., method='text') is not suitable for the inner text because it adds the tail of the top element.

A proper implementation would be

def innertext(elt):
    return (elt.text or '') +''.join(innertext(e)+e.tail for e in elt)

that can be included in the doc instead of the mention of the to string trick

----------

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

From report at bugs.python.org  Thu Apr 30 20:03:22 2015
From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=)
Date: Thu, 30 Apr 2015 18:03:22 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1430417001.99.0.444648464011.issue24079@psf.upfronthosting.co.za>


J?r?me Laurens added the comment:

Erratum

def innertext(elt):
    return (elt.text or '') +''.join(innertext(e)+(e.tail or '') for e in elt)

----------

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

From report at bugs.python.org  Thu Apr 30 21:52:59 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 30 Apr 2015 19:52:59 +0000
Subject: [docs] [issue23495] The writer.writerows method should be
	documented as	accepting any iterable (not only a list)
In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za>
Message-ID: <1430423579.04.0.00961906621945.issue23495@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

I'd be happy to provide a patch for the DictWriter.writerows code; I was naively counting on it accepting an iterable and that it would not pull the whole sequence into memory (while feeding it gigabytes of CSV data).

----------
nosy: +mjpieters

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

From report at bugs.python.org  Thu Apr 30 22:25:52 2015
From: report at bugs.python.org (Paul Moore)
Date: Thu, 30 Apr 2015 20:25:52 +0000
Subject: [docs] [issue24087] Documentation doesn't explain the term
	"coroutine" (PEP	342)
Message-ID: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za>


New submission from Paul Moore:

Although the new generator methods introduced in PEP 342 are documented, the term "coroutine" is not defined anywhere. In particular, the fact that Python coroutines work in conjunction with an event loop rather than transferring control directly between each other is not mentioned.

----------
assignee: docs at python
components: Documentation
files: coroutine_docs.patch
keywords: needs review, patch
messages: 242286
nosy: docs at python, gvanrossum, paul.moore
priority: normal
severity: normal
stage: patch review
status: open
title: Documentation doesn't explain the term "coroutine" (PEP 342)
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39239/coroutine_docs.patch

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

From report at bugs.python.org  Thu Apr 30 22:57:27 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 30 Apr 2015 20:57:27 +0000
Subject: [docs] [issue24060] Clearify necessities for logging with timestamps
In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za>
Message-ID: <1430427447.6.0.155579653019.issue24060@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Perhaps I'll just change it to say 

... the default value of '%(message)s' is used, which just includes the message in the logging call. To have additional items of information in the formatted output (such as a timestamp), see other placeholder variables ...

and then link to the "LogRecord Attributes" section.

----------

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

From jimjjewett at gmail.com  Thu Apr 30 23:22:31 2015
From: jimjjewett at gmail.com (jimjjewett at gmail.com)
Date: Thu, 30 Apr 2015 21:22:31 -0000
Subject: [docs] Documentation doesn't explain the term "coroutine" (PEP 342)
	(issue 24087)
Message-ID: <20150430212231.31906.35783@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/24087/diff/14757/Doc/glossary.rst#newcode150
Doc/glossary.rst:150: A generator function that works along with an
event loop or trampoline
Is it a "generator function" or just a "generator", with "generator
function" being the thing you call to create it?  For reference, I'm
looking at
https://docs.python.org/3/reference/expressions.html#yield-expressions

http://bugs.python.org/review/24087/diff/14757/Doc/glossary.rst#newcode151
Doc/glossary.rst:151: function to allow it to yield control to other
generators without
I think "without blocking" should be "while it is blocked"

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