From report at bugs.python.org  Thu Oct  1 06:07:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 04:07:07 +0000
Subject: [docs] [issue25275] Documentation v/s behaviour mismatch wrt
 integer literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443672427.44.0.203367539851.issue25275@psf.upfronthosting.co.za>


Martin Panter added the comment:

Related discussion and background in Issue 10581, although that report seems to be geared at extending the Unicode support even further (disallowing mixed scripts, allowing proper minus signs, full-width characters, Roman numerals, etc).

The existing support is actually documented if you know where to look; see the sixth note under the table at <https://docs.python.org/dev/library/stdtypes.html#typesnumeric>. I agree that the references for each constructor should also document this as well.

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

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

From report at bugs.python.org  Thu Oct  1 07:18:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 05:18:01 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443676681.7.0.199385994899.issue16701@psf.upfronthosting.co.za>


Martin Panter added the comment:

?For the most part? works for me. Here is the patch.

----------
Added file: http://bugs.python.org/file40637/seq-inplace.v3.patch

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

From report at bugs.python.org  Thu Oct  1 07:31:31 2015
From: report at bugs.python.org (Akira Li)
Date: Thu, 01 Oct 2015 05:31:31 +0000
Subject: [docs] [issue25286] views are not sequences
Message-ID: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>


New submission from Akira Li:

The entry for *dict view* in the glossary may be clarified, to avoid
confusion with collection.abc.Sequence i.e., from:

  They are lazy sequences that will see changes in the underlying
  dictionary.

to something like:

  They provide a dynamic view on the dictionary?s entries, which means
  that when the dictionary changes, the view reflects these changes.

See https://mail.python.org/pipermail/python-ideas/2015-October/036682.html

I've attached the corresponding doc patch.

----------
assignee: docs at python
components: Documentation
files: dict-views-glossary.patch
keywords: patch
messages: 251995
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: views are not sequences
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40638/dict-views-glossary.patch

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

From report at bugs.python.org  Thu Oct  1 08:16:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 06:16:58 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1443680218.81.0.892974449691.issue25286@psf.upfronthosting.co.za>


Martin Panter added the comment:

If changing the glossary heading, make sure it is kept in alphabetical order and incoming links still work (e.g. look for `view` and <view>). And maybe ?dictionary view? (full spelling, and singular) would be a more accurate heading.

The text changes look good however.

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

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

From report at bugs.python.org  Thu Oct  1 08:50:33 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 01 Oct 2015 06:50:33 +0000
Subject: [docs] [issue25284] Spec for BaseEventLoop.run_in_executor(executor,
 callback, *args) is outdated in documentation
In-Reply-To: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>
Message-ID: <1443682233.61.0.400493315103.issue25284@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in 9a10055e12fa d7d18ef3e05c 1465b18ef4fc

----------
nosy: +asvetlov
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Thu Oct  1 11:33:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 09:33:09 +0000
Subject: [docs] [issue21995] Idle: pseudofiles have no buffer attribute.
In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za>
Message-ID: <1443691989.62.0.780395123508.issue21995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one example of test stream that has no buffer - stdprinter used as sys.stderr on early stage of Python startup.

----------

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

From report at bugs.python.org  Thu Oct  1 13:15:33 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 01 Oct 2015 11:15:33 +0000
Subject: [docs] [issue25123] Logging Documentation - dictConfig
 disable_existing_loggers
In-Reply-To: <1442312912.97.0.962237041326.issue25123@psf.upfronthosting.co.za>
Message-ID: <1443698133.71.0.117045233493.issue25123@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This is mentioned in the documentation for dictConfig - see the bottom of the section at https://docs.python.org/2.7/library/logging.config.html#dictionary-schema-details

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

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

From report at bugs.python.org  Thu Oct  1 15:46:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2015 13:46:08 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443707168.38.0.937438747369.issue16701@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Fri Oct  2 01:59:25 2015
From: report at bugs.python.org (Akira Li)
Date: Thu, 01 Oct 2015 23:59:25 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1443743965.6.0.192048380226.issue25286@psf.upfronthosting.co.za>


Akira Li added the comment:

Thank you for `view`, <view> hint. I did look for :term:`view` that was
obviously not enough.

The new patch contains the renamed entry in the correct place. All `view`, <view>`
occurrences dictionary view are updated now.

----------
Added file: http://bugs.python.org/file40654/dict-views-glossary-2.patch

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

From report at bugs.python.org  Fri Oct  2 04:23:44 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Fri, 02 Oct 2015 02:23:44 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
Message-ID: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>


New submission from Patrick Maupin:

PEP 8 recommends absolute imports over relative imports, and section 5.4.2 of the import documentation says that an import will cause a binding to be placed in the imported module's parent's namespace.

However, since (with all current Python versions) this binding is not made until _after_ the module body has been executed, there are cases where relative imports will work fine but absolute imports will fail.  Consider the simple case of these five files:

xyz.py: import x
x/__init__.py:  import x.y
x/y/__init__.py:  import x.y.a
x/y/a/__init__.py:  import x.y.b; foo = x.y.b.foo
x/y/b/__init__.py:  foo = 1

This will fail in a fashion that may be very surprising to the uninitiated.  It will not fail on any of the import statements; rather it will fail with an AttributeError on the assignment statement in x.y.a, because the import of y has not yet finished, so y has not yet been bound into x.

This could conceivably be fixed in the import machinery by performing the binding before performing the exec.  Whether it can be done cleanly, so as not to cause compatibility issues with existing loaders, is a question for core maintainers.

But if it is decided that the current behavior is acceptable, then at a minimum both the PEP 8 and the import documentation should have an explanation of this corner case and how it can be solved with relative imports.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 252078
nosy: Patrick Maupin, docs at python
priority: normal
severity: normal
status: open
title: Absolute imports fail in some cases where relative imports would work
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct  2 06:43:43 2015
From: report at bugs.python.org (aj guy)
Date: Fri, 02 Oct 2015 04:43:43 +0000
Subject: [docs] [issue20476] If new email policies are used,
 default message factory should be EmailMessage
In-Reply-To: <1391292485.67.0.381493162498.issue20476@psf.upfronthosting.co.za>
Message-ID: <1443761023.89.0.28767912134.issue20476@psf.upfronthosting.co.za>


Changes by aj guy <ftfr4life at aol.com>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +aj guy, docs at python
type: behavior -> resource usage

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

From report at bugs.python.org  Fri Oct  2 07:27:49 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 05:27:49 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
Message-ID: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Katie McLaughlin recently pointed me at PHP's summary page for the End-of-Life dates for their various releases: http://php.net/eol.php

That seems like a useful thing to offer, but we unfortunately don't currently have a great place for this kind of documentation:

- the main docs are version specific, while this kind of page should be version independent
- the update process, access control model and reader experience for python.org is too different from that for the main documentation
- ditto for the wiki
- informational PEPs are closer from an access control perspective, but aren't generated with Sphinx and are still disconnected from the main docs from a reader perspective
- it's off-topic for the developer guide

The "right" answer seems to be setting up a separate "docs" project on hg.python.org to use as the landing page for docs.python.org and for version independent information like this (the redirects already defined as part of PEP 430 should continue to handle unqualified deep links into the Python 2 docs).

I'm not sure how much reconfiguration work such a change would entail, though.

----------
assignee: docs at python
components: Documentation
messages: 252084
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Simple End-of-life guide covering all unsupported versions
type: enhancement

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

From report at bugs.python.org  Fri Oct  2 08:09:56 2015
From: report at bugs.python.org (Matt C)
Date: Fri, 02 Oct 2015 06:09:56 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443766196.79.0.315129589589.issue25294@psf.upfronthosting.co.za>


Changes by Matt C <matt at engineered.software>:


----------
nosy: +freshquiz

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

From report at bugs.python.org  Fri Oct  2 08:50:14 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 06:50:14 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443768614.46.0.91930377637.issue25296@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Adding Georg directly to the nosy, as I think this kind of structural question falls under his domain as the docs lead :)

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

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

From report at bugs.python.org  Fri Oct  2 09:09:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 07:09:50 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443769790.56.0.973730183073.issue25296@psf.upfronthosting.co.za>


STINNER Victor added the comment:

We now putting the such page on python.org website, as PHP did?

I like the idea of being very explicit on EOL. It's a FAQ on mailing lists. Even for me, being involved in Python developments, it's not always easy to know the status of each branch. For example, I recently asked the question for Python 3.4 :-) The answer was that it will switch to security fixes only after the next 3.4.x release.

The EOL page must explain each stage of maintenance:

* development branch: any kind of change including new features
* bugfix: no new feature, only bugfixes including security fixes
* security fixes only: no more binary release, only source code release, only security fixes and some execeptional bugfixes (sorry, I don't know the exact rule for bugfixes at this stage)
* end of life: dead, no change at all

Python 2.6 reached its EOL or security fixes are still accepted?

I guess that Python <= 2.5, Python 3.0 and Python 3.1 are dead, right?

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

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

From report at bugs.python.org  Fri Oct  2 09:30:29 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 07:30:29 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443771029.01.0.938305595516.issue25296@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The branch status is captured in the release PEPs:

2.6 (& 3.0): https://www.python.org/dev/peps/pep-0361/
2.7: https://www.python.org/dev/peps/pep-0373/
3.1: https://www.python.org/dev/peps/pep-0375/
3.2: https://www.python.org/dev/peps/pep-0392/
3.3: https://www.python.org/dev/peps/pep-0398/
3.4: https://www.python.org/dev/peps/pep-0429/
3.5: https://www.python.org/dev/peps/pep-0478/
3.6: https://www.python.org/dev/peps/pep-0494/

The "devcycle" page in the developer guide captures the details of the difference phases: https://docs.python.org/devguide/devcycle.html

So perhaps the expedient near term solution would be to put this info on the devcycle page, and move it later?

----------

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

From report at bugs.python.org  Fri Oct  2 09:33:57 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 07:33:57 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443771237.06.0.260762882378.issue25296@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Items to capture for each unsupported or security fix only release series:

* date & version of last binary release (maintenance -> security fix only transition)
* date & version of last source-only security release (commercial redistributors are on their own for ongoing support from this point)
* link to the release PEP
* link to the upgrade guide in the next What's New doc once the next version is released

----------

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

From report at bugs.python.org  Fri Oct  2 09:55:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2015 07:55:10 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443772510.49.0.365939557651.issue25296@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> - the main docs are version specific, while this kind of page
> should be version independent

They could still be included in the main docs with a clear link at the top that says "For the most-recently updated schedule see d.p.o/3/eol.html.".  Each version should still be correct -- it will just lack the eol dates for the newest releases.
The Unicode Consortium and the W3C do something similar (see e.g. http://www.unicode.org/reports/tr29/tr29-23.html and http://www.w3.org/TR/2014/WD-html5-20140617/).

Another option is to create a new repo where to put version-independent docs (e.g. the whatsnew, maybe even Misc/NEWS).  It shouldn't be difficult to then include these pages in the main docs.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Fri Oct  2 10:23:19 2015
From: report at bugs.python.org (Nicholas H.Tollervey)
Date: Fri, 02 Oct 2015 08:23:19 +0000
Subject: [docs] [issue19006] UnitTest docs should have a single list of
	assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1443774199.84.0.0774060564923.issue19006@psf.upfronthosting.co.za>


Changes by Nicholas H.Tollervey <ntoll at ntoll.org>:


----------
nosy: +kushal.das, ntoll

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

From report at bugs.python.org  Fri Oct  2 11:45:02 2015
From: report at bugs.python.org (Davey Shafik)
Date: Fri, 02 Oct 2015 09:45:02 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443779102.17.0.0448662950062.issue25296@psf.upfronthosting.co.za>


Davey Shafik added the comment:

We (PHP) also have a more visual guide at http://php.net/supported-versions.php which updates dynamically to show the current status.

It shows the current status (EOL, Security only, Active) of releases from PHP 5.3, which is still the default for many LTS distros and still in common use.

----------
nosy: +dshafik

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

From report at bugs.python.org  Fri Oct  2 11:48:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 09:48:21 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443779102.17.0.0448662950062.issue25296@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb5CQ8gisKZ32M2cw8_qcegBA9hefwDpK43PcR9vHRHrQ@mail.gmail.com>


STINNER Victor added the comment:

Davey Shafik added the comment:
> We (PHP) also have a more visual guide at http://php.net/supported-versions.php which updates dynamically to show the current status.

Great job! It's much easier to see the status with the summary in a
single picture.

----------

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

From report at bugs.python.org  Fri Oct  2 12:04:25 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2015 10:04:25 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443780265.85.0.153446133276.issue25296@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I like that, in fact I used the same format in my talk "The development process of Python": http://wolfprojects.altervista.org/talks/development-process-of-python-2011/ (slides 20/21).

The main problem is where to put all this though.

----------

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

From report at bugs.python.org  Fri Oct  2 13:25:46 2015
From: report at bugs.python.org (A. Skrobov)
Date: Fri, 02 Oct 2015 11:25:46 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
Message-ID: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>


New submission from A. Skrobov:

Python 2.7.3 (default, Dec 18 2014, 19:10:20) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> parser.add_argument("--foo", help="foo", action='store_const')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/argparse.py", line 1281, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() takes at least 4 arguments (4 given)
>>> 



First, the exception message is entirely unhelpful (you wanted at least 4, you got 4, what's your problem?)

Second, adding "const=None" to the invocation makes it succeed; but,  according to https://docs.python.org/2/library/argparse.html#const this argument defaults to "None", so it shouldn't be necessary to specify it explicitly. Thus, either the documentation or the implementation is wrong.

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 252106
nosy: A. Skrobov, docs at python
priority: normal
severity: normal
status: open
title: TypeError: __init__() takes at least 4 arguments (4 given)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  2 13:47:14 2015
From: report at bugs.python.org (Bar Harel)
Date: Fri, 02 Oct 2015 11:47:14 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1443786433.86.0.857244499736.issue16802@psf.upfronthosting.co.za>


Bar Harel added the comment:

Here you go.

----------
nosy: +bar.harel
Added file: http://bugs.python.org/file40656/Issue16802_rev2.patch

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

From report at bugs.python.org  Fri Oct  2 14:13:36 2015
From: report at bugs.python.org (J Richard Snape)
Date: Fri, 02 Oct 2015 12:13:36 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443788016.5.0.825119655404.issue25294@psf.upfronthosting.co.za>


Changes by J Richard Snape <snapey1979 at googlemail.com>:


----------
nosy: +J Richard Snape

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

From report at bugs.python.org  Fri Oct  2 14:22:40 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 02 Oct 2015 12:22:40 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443788560.28.0.720630923549.issue25294@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/issue25294>
_______________________________________

From report at bugs.python.org  Fri Oct  2 15:58:49 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 02 Oct 2015 13:58:49 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443794329.46.0.544804124146.issue25296@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/issue25296>
_______________________________________

From report at bugs.python.org  Fri Oct  2 16:45:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 14:45:48 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443797148.28.0.78535777665.issue25296@psf.upfronthosting.co.za>


R. David Murray added the comment:

It seems to me a link to this version independent info could logically appear on the docs front page.  I think we ought to add the devguide there already, for instance.  The 'Meta information' section seems perfectly appropriate...even though all the docs currently in there are maintained in the Docs directory, both 'about' and 'reporting bugs' are currently version-independent information.

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

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

From report at bugs.python.org  Fri Oct  2 16:55:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 14:55:15 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443797715.28.0.835497360735.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, the python2 TypeErrors for mimatched arguments are sub-optimal.  This has been fixed in python3:

>>> parser.add_argument('--foo', help="foo", action='store_const')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/p36/Lib/argparse.py", line 1336, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() missing 1 required positional argument: 'const'

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 16:56:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 14:56:25 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443797785.45.0.13722669499.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oops, sorry, I missed the fact that you were pointing out a doc issue.

----------
resolution: out of date -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Fri Oct  2 17:02:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:02:11 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443798131.13.0.650301520877.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  After looking at the code, it may also be desirable to improve that error message at the argparse level, since there's a bit of not-immediately-obvious indirection going on there.

----------

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

From report at bugs.python.org  Fri Oct  2 17:05:34 2015
From: report at bugs.python.org (A. Skrobov)
Date: Fri, 02 Oct 2015 15:05:34 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443798334.09.0.268723874893.issue25299@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Thank you for confirming that the mismatch between the documentation and the behaviour is preserved in Python 3!

Adding it to the list of affected versions.

----------
versions: +Python 3.5

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

From report at bugs.python.org  Fri Oct  2 17:15:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:15:15 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443798915.31.0.393790807771.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify this for other readers: the issue here is that the arguments to add_argument are passed through the action routine, which in this case is store_const, and store_const is the one that requires 'const' be specified...which isn't made clear by either the docs or the error message.

----------

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

From report at bugs.python.org  Fri Oct  2 17:16:16 2015
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Oct 2015 15:16:16 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443798976.83.0.883335575857.issue25296@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> It seems to me a link to this version independent info could logically appear on the docs front page.

Yes, that sounds good. I do like the PHP graph of versions too...

----------

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

From report at bugs.python.org  Fri Oct  2 17:32:16 2015
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Oct 2015 15:32:16 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443799936.48.0.184309641255.issue25296@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It should also be linked from the downloads page.

----------

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

From report at bugs.python.org  Fri Oct  2 17:55:00 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 02 Oct 2015 15:55:00 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443801300.59.0.437002145254.issue25299@psf.upfronthosting.co.za>


paul j3 added the comment:

A related issue is

http://bugs.python.org/issue24754
argparse add_argument with action="store_true", type=bool should not crash

In this case the user specified a parameter that the 'store_true' subclass did not accept.

In both cases, 'parser.add_argument' does minimal error checking (or catching), so the user ends up seeing the '__init__' argument error.

This line in the 'store_const' documentation is clearly wrong.  There's no default.

    (Note that the const keyword argument defaults to the rather
    unhelpful None.)

Possible fixes to the bigger issue:

- major addition to the documentation, documenting allowable subclass parameters (but the subclasses aren't part of the API).

- major addition to add_argument that filters parameters before passing them to the subclasses.  But can that be done without replicating information that is implicit in the subclass __init__?  Can we use advanced inspection?  What about user defined Action classes?

- minor addition to add_argument that catches the __init__ parameter errors and adds a mollifing explanation.

- somehow make Action (and its subclasses) responsible for a nice error message.  But how do you override the normal behavior of Python regarding function parameters?

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

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

From report at bugs.python.org  Fri Oct  2 17:58:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:58:55 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443801535.5.0.755186326243.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think your second to last choice (catch the error) is the only practical solution.  It is also probably the best, since we need to support user-written action routines.

----------

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

From report at bugs.python.org  Fri Oct  2 18:15:53 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 02 Oct 2015 16:15:53 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443802553.39.0.447260758735.issue25296@psf.upfronthosting.co.za>


Carol Willing added the comment:

+1 to adding the EOF info to the Docs front page and a link from the downloads page.

Also, +1 to David's suggestion to adding the devguide as well to the front page. In the future, it would be nice to add the devguide to the CPython repo instead of having it as a standalone. It would consolidate things in to one workflow instead of a different workflow for the devguide.

P.S. Ezio - nice slide deck content :)

----------
nosy: +willingc

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

From report at bugs.python.org  Fri Oct  2 18:17:12 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 02 Oct 2015 16:17:12 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443802632.18.0.478757698931.issue25296@psf.upfronthosting.co.za>


Carol Willing added the comment:

And that would be EOL (end of life) not EOF. More coffee please...

----------

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

From report at bugs.python.org  Fri Oct  2 18:31:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 02 Oct 2015 16:31:37 +0000
Subject: [docs] [issue25290] csv.reader: minor docstring typo
In-Reply-To: <1443710545.32.0.660901120379.issue25290@psf.upfronthosting.co.za>
Message-ID: <1443803497.01.0.406647830906.issue25290@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Johannes! I forgot to update 2.7 docs, but should be OK now.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +berker.peksag, docs at python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  2 18:52:08 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 02 Oct 2015 16:52:08 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1443804727.81.0.441739667079.issue16802@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Patch looks good.

----------

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

From report at bugs.python.org  Fri Oct  2 23:38:35 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:38:35 +0000
Subject: [docs] [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1443821915.33.0.875436632633.issue10021@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6 -Python 3.2

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

From report at bugs.python.org  Fri Oct  2 23:43:06 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:43:06 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
	years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1443822186.69.0.531985777228.issue13305@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Can someone recap the status of this issue?  It is classified as a documentation bug, but I don't see a clear statement of what is wrong with the documentation.

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

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

From report at bugs.python.org  Sat Oct  3 06:17:08 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 04:17:08 +0000
Subject: [docs] [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443845828.8.0.587326264441.issue25238@psf.upfronthosting.co.za>


Martin Panter added the comment:

What are you proposing? I think you will find both cases are true. The change was made in 3.4 (but only in time for 3.4.3+) and 3.5 (starting at 3.5.0). If the documentation failed to mention 3.5 and only mentioned 3.4.3, it would not be obvious if that change made it into 3.5.0, or only the upcoming 3.5.1, etc.

See the ?Changed in version 3.3.1? notice at <https://docs.python.org/3/library/subprocess.html#subprocess.Popen> for a similar case, which mentions both versions.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, martin.panter

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

From report at bugs.python.org  Sat Oct  3 06:53:45 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 04:53:45 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443848025.64.0.420161293456.issue25299@psf.upfronthosting.co.za>


paul j3 added the comment:

A fix that I am exploring would wrap the Action instantiation call in add_argument with a try/except block

That is replace:

    def add_argument(...)
        ....
        action = action_class(**kwargs)
        ...

with

        ....
        try:
            action = action_class(**kwargs)
        except TypeError:
            msg = str(_sys.exc_info()[1])
            msg = msg.replace('__init__','add_argument')
            msg = [msg]
            msg.append('Wrong argument(s) for Action subclass: %s'%action_class.__name__)
            # action_class is now a class, rather than the input string
            msg.append('kwargs: %s'%kwargs)
            sig = getattr(action_class, 'action_sig',None)
            if sig is not None:
                msg = sig(msg)
            raise ValueError(msg)
       ....

This collects information on the error, the action class and arguments, and passes them to a class method of the Action.  That customizes the message, and returns it for reraising.

In 'class Action' I define:

    @classmethod
    def action_sig(cls, msg=[]):
        # return the signature
        # subclasses may return custom version
        import inspect
        try:
            name = cls.__name__
            sig = inspect.signature(cls.__init__)
            sig = str(sig)
        except AttributeError:
            spec = inspect.getfullargspec(cls.__init__)
            sig = inspect.formatargspec(*spec)
        # remove self, option_strings, dest
        dstr='dest,'
        ind = sig.find(dstr)
        if ind>=0:
            sig = '(...'+sig[(ind+len(dstr)+1):]
        sig = 'class args: %s'%sig
        msg.append(sig)
        return '\n'.join(msg)

This adds inspect.signature information from the subclass __init__ method to the message from add_argument.  Subclasses (including the user defined ones) could customize this.

So a missing 'const' error would display as:

ValueError: add_argument() missing 1 required positional argument: 'const'
Wrong argument(s) for Action subclass: _StoreConstAction
kwargs: {'option_strings': ['--bar'], 'dest': 'bar'}
class args: (...const, default=None, required=False, help=None, metavar=None)

This may be overkill, but it gives an idea of the information that we can add to the original TypeError.

Done right this action_sig() could also serve as a usage function for an Action class.

----------
keywords: +3.5regression

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

From report at bugs.python.org  Sat Oct  3 09:38:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 07:38:07 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443857887.14.0.34155508073.issue16701@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct  3 10:02:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 08:02:24 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <20151003080221.483.288@psf.io>


Roundup Robot added the comment:

New changeset ec373d762213 by Martin Panter in branch '2.7':
Issue #16701: Document += and *= for mutable sequences
https://hg.python.org/cpython/rev/ec373d762213

New changeset f83db23bec7f by Martin Panter in branch '3.4':
Issue #16701: Document += and *= for mutable sequences
https://hg.python.org/cpython/rev/f83db23bec7f

New changeset 6e43a3833293 by Martin Panter in branch '3.5':
Issue #16701: Merge sequence docs from 3.4 into 3.5
https://hg.python.org/cpython/rev/6e43a3833293

New changeset a92466bf16cc by Martin Panter in branch 'default':
Issue #16701: Merge sequence docs from 3.5
https://hg.python.org/cpython/rev/a92466bf16cc

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

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

From report at bugs.python.org  Sat Oct  3 10:05:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 08:05:10 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443859510.91.0.956888882997.issue16701@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct  3 11:23:14 2015
From: report at bugs.python.org (desbma)
Date: Sat, 03 Oct 2015 09:23:14 +0000
Subject: [docs] [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443864194.28.0.535173916385.issue25238@psf.upfronthosting.co.za>


desbma added the comment:

In my mind 3.4.3 < 3.5, so unless mentioned otherwise it is implied that  the change is in all versions of the 3.5 branch.

----------

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

From report at bugs.python.org  Sat Oct  3 11:24:40 2015
From: report at bugs.python.org (desbma)
Date: Sat, 03 Oct 2015 09:24:40 +0000
Subject: [docs] [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443864280.91.0.371594524181.issue25238@psf.upfronthosting.co.za>


desbma added the comment:

Previous sentence is if we only mention 3.4.3 of course.

----------

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

From report at bugs.python.org  Sat Oct  3 11:45:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 09:45:41 +0000
Subject: [docs] [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443865541.34.0.824782680508.issue22413@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a suggested patch. I did include details of the initializer and getvalue(); this is the heart of the problem IMO. In a limited sense the newline flag _is_ similar to TextIOWrapper, but more broadly this implied to me that newlines should be encoded in the buffer, just like in TextIOWrapper?s wrapped ?buffer? and on disk.

My patch also adds to a comment in the C code and removes another comment made out of date by Argument Clinic.

In the documentation I didn?t mention the problem with split CRLFs; I think that is a separate bug.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review
status: closed -> open
versions: +Python 2.7, Python 3.6
Added file: http://bugs.python.org/file40665/newline-doc.patch

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

From report at bugs.python.org  Sat Oct  3 14:54:38 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Oct 2015 12:54:38 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443876878.67.0.147066133898.issue25294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 992389 is the previous incarnation of this bug report, while issue 17636 made the change so that from imports will resolve in some situations where this error will occur.

That fact that "from x.y.b import foo" may now resolve in cases where "import x.y.b; foo = x.y.b.foo" will fail should indeed be covered in the documentation.

If PEP 8 were to be updated at all, it should just say "Don't use circular imports. If you can't refactor your design to move the common components out to a shared helper module, then move everything into the same module - the irremovable circular dependency indicates the code is too tightly coupled to live in different modules".

----------

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

From report at bugs.python.org  Sat Oct  3 17:38:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 15:38:48 +0000
Subject: [docs] [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443886728.16.0.92905098817.issue25238@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with desbma, but would not consider it unreasonable to mention both versions in the 3.5+ docs in order to avoid any ambiguity.

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

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

From report at bugs.python.org  Sat Oct  3 21:21:22 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Sat, 03 Oct 2015 19:21:22 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443900082.33.0.0454540957331.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

The PEP 8 recommendation to "use absolute imports" is completely, totally, unambiguously meaningless absent the expectation that packages refer to parts of themselves.  And it works, too!  (For a single level of package.)

As soon as packages are nested, this recommendation falls over, with the most innocuous code:

    x/__init__.py: import x.y
    x/y/__init__.py: import x.y.z; x.y.z
    x/y/z/__init__.py: <empty>

The ability to nest packages is an attractive nuisance from a programmer's perspective.  He's neatly organized his code, and now he finds that there are two ways to make it work:  (1) Use the disparaged relative imports; or (2) flatten his package to a single level, because importing X.Z from within X.Y will work fine.

IMO, the language that Nick proposes for PEP 8 will either (a) not be understood at all by the frustrated junior programmer -- sure, the import system views it as a circular import, but he's not seeing it that way; or (b) be understood to expose a huge wart on the side of Python:  Even though Z is only used by Y/__init__, and doesn't itself use anything else in Y, it cannot live alongside Y/__init__. Instead, unless Y is a top level module or the programmer uses denigrated relative imports, he will now have to move it to a different place, so that from Y he can then "import X.Y_HELPER.Z".

Another PEP 8 prescription is that "Standard library code should avoid complex package layouts and always use absolute imports."  Here's a serious offer -- I'll give $200 to whoever gets the patch accepted that makes lib2to3 conformant without breaking it.

----------

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

From report at bugs.python.org  Sat Oct  3 23:13:17 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 21:13:17 +0000
Subject: [docs] [issue25299] TypeError: __init__() takes at least 4
 arguments (4 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443906797.23.0.140315886069.issue25299@psf.upfronthosting.co.za>


paul j3 added the comment:

The unittest file test_argparse.py tests add_argument parameters in 

    class TestInvalidArgumentConstructors(TestCase)

It looks at a dozen different categories of errors, mostly checking that they return the correct TypeError or ValueError.  It does not check the content of error messages.  

If I change the code I described yesterday to return a TypeError again (but with an enhanced message), it passes this unittest.

Most of the test_argparse.py tests just check for error type.  There just a couple of late additions that check error message content:

    TestMessageContentError
    TestAddArgumentMetavar

----------

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

From report at bugs.python.org  Sun Oct  4 05:43:37 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Oct 2015 03:43:37 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443900082.33.0.0454540957331.issue25294@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eWwvGds0R8UmZun1stQ8N3zNmJpNn7wX-698bn3q5J5A@mail.gmail.com>


Nick Coghlan added the comment:

If that's the concern, then the relevant guidance is to avoid running code
at package import time (which many new developers will now do by default
with __init__.py becoming optional).

----------

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

From report at bugs.python.org  Sun Oct  4 06:25:14 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Sun, 04 Oct 2015 04:25:14 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443932712.32.0.293585846769.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

I'm a big fan of stitching things together at the top myself -- maybe that's partly an unconscious reaction to this very issue.

But I'm not sanguine about how easy it is to express this practice in the docs.

This issue arose in the context of me answering a question on Stack Overflow.  My initial response was "well, duh, obviously relative imports are more Pythonic here because that's the obvious way to do it (that works)."

But then, of course, PEP 8 disagrees.

For that actual question on Stack Overflow, you would have to carefully define the scope of "executing" so that it was fully understood to include "subclassing a class defined in a peer module or submodule" -- because that's what was breaking.

Just as most people don't think of imports that can be placed in a DAG as circular, most people also don't think of subclassing as "executing."

But the Python interpreter sometimes vehemently disagrees in both cases.  I'm not surprised at its behavior, but I'm also not surprised that some people who haven't thought deeply about the behavior find it surprising.

I'm not fully convinced that this even can be documented in a way that renders observed behavior unsurprising in the general case, but I am convinced that doing so would require a lot of care.

----------

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

From report at bugs.python.org  Sun Oct  4 23:04:53 2015
From: report at bugs.python.org (Julien Baley)
Date: Sun, 04 Oct 2015 21:04:53 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
Message-ID: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>


New submission from Julien Baley:

The documentation of the action `store_const` states that it defaults to None. In turn, the documentation of `store_true` and `store_false` states that "[t]hese are special cases of 'store_const'", suggesting that they would also default to None.

Thankfully, `store_true` defaults to False and `store_false` to True, but this is not documented. That would be useful, as I keep seeing people writing `action='store_true' default=False` and vice-versa.

----------
assignee: docs at python
components: Documentation
files: store_true_false_doc.patch
keywords: patch
messages: 252288
nosy: Julien Baley, docs at python
priority: normal
severity: normal
status: open
title: Documentation: argparse's actions store_{true,false} default to False/True (undocumented)
type: enhancement
Added file: http://bugs.python.org/file40676/store_true_false_doc.patch

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

From report at bugs.python.org  Mon Oct  5 00:11:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2015 22:11:55 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1443996715.79.0.364672789948.issue25314@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is another issue to fix the documentation for store_const, which does not in fact default to anything.  The 'default" in this case is the default for the value stored when the option is specified.  So if store_true also implies 'default=False', that should indeed be documented.

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

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

From report at bugs.python.org  Mon Oct  5 00:28:59 2015
From: report at bugs.python.org (Julien Baley)
Date: Sun, 04 Oct 2015 22:28:59 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1443997739.66.0.901449929584.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

That's true, store_const has no default and will throw an exception if const is not provided. Updated the patch consequently.

----------
Added file: http://bugs.python.org/file40677/store_const_true_false_doc.patch

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

From report at bugs.python.org  Mon Oct  5 00:29:22 2015
From: report at bugs.python.org (Julien Baley)
Date: Sun, 04 Oct 2015 22:29:22 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1443997762.1.0.0164020051399.issue25314@psf.upfronthosting.co.za>


Changes by Julien Baley <julien.baley at gmail.com>:


Removed file: http://bugs.python.org/file40676/store_true_false_doc.patch

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

From jonathan10029 at yahoo.com  Sun Oct  4 14:42:29 2015
From: jonathan10029 at yahoo.com (Jonathan Klemm)
Date: Sun, 4 Oct 2015 08:42:29 -0400
Subject: [docs] Tutorial   9.11. Generator Expressions Example
Message-ID: <4ED49076-AC3C-4226-AB9F-E71D4741392B@yahoo.com>

When I run the example here I get a NameError for the unique_words line  page not defined and for valedictorian i get a NameError for graduates not defined.
I am running python 3.4 on a Mac mini 


From z015o621 at gmail.com  Sun Oct  4 17:07:32 2015
From: z015o621 at gmail.com (wei zhang)
Date: Sun, 4 Oct 2015 23:07:32 +0800
Subject: [docs] where is the chinese documents?
Message-ID: <CAPKmhtkf6=WHfKy+yrGTbGLPYzOWCY_cxHZNHeoT+9vsULV91w@mail.gmail.com>

i'm new one.
tks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151004/c9a127a6/attachment.html>

From report at bugs.python.org  Mon Oct  5 12:13:54 2015
From: report at bugs.python.org (Bar Harel)
Date: Mon, 05 Oct 2015 10:13:54 +0000
Subject: [docs] [issue25175] Documentation-Tkinter Clarify module spelling
 change in Python 3 docs
In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za>
Message-ID: <1444040034.15.0.332921572134.issue25175@psf.upfronthosting.co.za>


Bar Harel added the comment:

I guess you're correct, a simple mistake one time mistake shouldn't require the changing of the docs.

----------

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

From lac at openend.se  Mon Oct  5 12:55:38 2015
From: lac at openend.se (Laura Creighton)
Date: Mon, 05 Oct 2015 12:55:38 +0200
Subject: [docs] where is the chinese documents?
In-Reply-To: <CAPKmhtkf6=WHfKy+yrGTbGLPYzOWCY_cxHZNHeoT+9vsULV91w@mail.gmail.com>
References: <CAPKmhtkf6=WHfKy+yrGTbGLPYzOWCY_cxHZNHeoT+9vsULV91w@mail.gmail.com>
Message-ID: <201510051055.t95Atc1X028868@fido.openend.se>

In a message of Sun, 04 Oct 2015 23:07:32 +0800, wei zhang writes:
>i'm new one.
>tks!

http://docspy3zh.readthedocs.org/en/latest/

Have fun!

Laura Creighton


From report at bugs.python.org  Mon Oct  5 16:19:09 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Mon, 05 Oct 2015 14:19:09 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444054749.88.0.333634324057.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

concurrent/futures/__init__.py may be a better example than 2to3 for this issue.  It's relatively new code, it's part of the standard library, it's fairly small and self-contained, and it doesn't follow the promulgated standard.

If it's bad code, it should be modified.  If it's not bad code, then the docs shouldn't denigrate the coding style (especially not to the extent of requiring absolute imports in standard library code), because a lot of newbies take the docs to heart and spend a lot of time and energy beating up themselves and others about conformance.

----------

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

From report at bugs.python.org  Mon Oct  5 18:30:32 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Oct 2015 16:30:32 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444062632.45.0.509504940006.issue25294@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't quite follow what you think is wrong with https://hg.python.org/cpython/file/tip/Lib/concurrent/futures/__init__.py . It looks totally fine to me.

And I should mention that you shouldn't follow PEP 8 like it's in stone and the only way to format code. The PEP is a set of guidelines only and not rules (this is a long-standing position of python-dev on PEP 8). For instance, I don't agree with the absolute import recommendation and do not follow it in my own code nor in importlib (it makes vendoring impossible without modifying the import statements).

I think the key thing to take away from this whole discussion is "don't have circular imports" is the key practice to follow. And if someone wants to propose a patch to update some documentation to point out that `from ... import ...` may work in some situations where `import ...; ... = ...` doesn't then I will personally review such a patch.

----------

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

From report at bugs.python.org  Mon Oct  5 18:38:20 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 16:38:20 +0000
Subject: [docs] [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444063100.36.0.58652618349.issue22413@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The patch fails to apply in the 2.7 branch. It works in 3.4. Could you look into the 2.7 issue?

----------

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

From report at bugs.python.org  Mon Oct  5 19:11:44 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Mon, 05 Oct 2015 17:11:44 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444065104.49.0.886294230925.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

I don't think anything is wrong with that code.  But PEP 8 prescribes a way of doing something that often won't work (which is unusual for PEP 8), with no discussion of this fact.

> I think the key thing to take away from this whole discussion is "don't have circular imports" is the key practice to follow.

If this is a "key practice" then why the heck is the recommended way to do things the one that is guaranteed to break it?

I have empirical evidence that it is surprising to some users that the semantics of "from .z import foo" and "from x.y.z import foo" are not identical -- in other words, some of them have a hard time classifying the second as a circular import but not the first.  And the documentation is silent on this.

> And if someone wants to propose a patch to update some documentation

I'll try to get to this in the next couple of weeks.

Thanks,
Pat

----------

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

From report at bugs.python.org  Mon Oct  5 19:12:04 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 17:12:04 +0000
Subject: [docs] [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444065124.24.0.673160480681.issue22413@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It looks like we don't merge 2.7 into 3.4 any more, so that will have to be a separate patch anyway.

So you can commit the patch to 3.4, merge into 3.5 and 3.6. Good luck! And thanks for your perseverance.

----------

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

From report at bugs.python.org  Mon Oct  5 19:53:31 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Oct 2015 17:53:31 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444067611.63.0.465301215049.issue25294@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You have to realize, Patrick, that the ability for `from ... import ...` to work in some situations that `import ...` won't is an age-old problem -- they are different at the bytecode level as well as how __import__ handles them -- and starting in Python 3.5 it got tweaked to potentially make the differences more pronounced by making a certain situation involving circular imports not trip users up as much where it was technically feasible to make the change without backwards-compatibility issues. It was a "practicality over purity" decision.

You also said that "PEP 8 prescribes a way of doing something that often won't work" which I disagree with. I think you're reading "absolute import" as synonymous with `import ...` which is not what the term means. In actuality, absolute imports means no leading dot in the name, e.g. `from .x import y` is a relative import while `from z.x import y` is an absolute one (as is `import z.x.y`). If you are using the term "absolute import" in the correct way then I still don't see how PEP 8 is suggesting any practice "that won't often work".

Circular imports are just plain hard to deal with. Due to the long-standing design of import being nothing more than syntactic sugar around exec() we don't get to know statically that a circular import is going to happen, so we can't error out early to tell the user that they *may* be in trouble. And not everyone gets themselves in a position where a circular import dependencies is a problem since it only causes issues when module-level code depends on each other in a circular way (which does include import statements which is where people typically trip themselves up when they get in this situation). I realize you're trying to do the right thing here and get the docs clarified to help newcomers out, but please realize it's just a difficult subject to explain succinctly, especially since a vast majority of people don't get themselves into a position where they have to deal with a circular import.

----------

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

From report at bugs.python.org  Mon Oct  5 20:55:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2015 18:55:25 +0000
Subject: [docs] [issue25175] Documentation-Tkinter Clarify module spelling
 change in Python 3 docs
In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za>
Message-ID: <1444071325.56.0.159385418225.issue25175@psf.upfronthosting.co.za>


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


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

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

From horshack at live.com  Mon Oct  5 21:23:02 2015
From: horshack at live.com (Horshack Horshack)
Date: Mon, 5 Oct 2015 19:23:02 +0000
Subject: [docs] Suggestion for improving {} vs {:s} in Format Specification
 Mini-Language
Message-ID: <CY1PR13MB0127833DBAFF5EED32B4ED97A4480@CY1PR13MB0127.namprd13.prod.outlook.com>

In the 3.x documentation for the format string specification https://docs.python.org/3/library/string.html#formatspec, the string representation table indicates that 's' and None are the same - {} vs {:s} for example. In practice the two are different with respect to how the argument is converted, which is especially important for objects that have no __format__ method defined. In 2.7x an object's __str__ method is called if there is no __format__ method, even if a format string like {:s} is specified. In 3.x if there is no __format__ method and any format string is specified, including just {:s}, a TypeError exception is thrown for a "non-empty format string passed to object.__format__". This difference may be documented elsewhere since it's not a format-string specific behavior pe-se but it would very helpful for those learning Python to reference this difference in the 3.x format string documentation as well, esp since the existing documentation's statement that the two are the same may be confusing to readers who see the different behavior between {} and {:s} on 2.7 vs 3.x, the latter causing an exception on 3.x


Thanks,


-adam
<https://docs.python.org/3/library/string.html#formatspec>

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

From report at bugs.python.org  Mon Oct  5 23:05:42 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Mon, 05 Oct 2015 21:05:42 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444079142.05.0.394464571167.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

You are correct that I have conflated two issues, but they are not orthogonal -- if you choose to use relative imports, you will never encounter this issue, because your imports will all be of the 'from ... import' form.

(And, as you point out, the fact that you don't have this issue with absolute "from ... import" statements is due to some special-casing in the import logic that doesn't help the other kind of import statement.)

But PEP 8 denigrates relative imports, and then goes on to describe the use of the "import x.y.z; x.y.z.foo" form as a way to avoid name clashes.

So PEP 8 promotes absolute imports, and then it presents using "import" instead of "from ... import" as a solution to some problems.  It never mentions that the 'as' clause could also solve those problems, and also never mentions that "import x.y.z" can actually cause problems in some cases.

And the importlib documentation is also a bit sparse on where things can fail.

We're in agreement that it will be difficult to document properly, and maybe I overstated my case, but my opinion remains that the current documentation promotes practices that _will_ sometimes get people in trouble.

----------

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

From report at bugs.python.org  Tue Oct  6 22:16:23 2015
From: report at bugs.python.org (paul j3)
Date: Tue, 06 Oct 2015 20:16:23 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1444162583.26.0.352775518515.issue25314@psf.upfronthosting.co.za>


paul j3 added the comment:

I have seen questions on StackOverflow with 'store_true' and explicit `default=False` parameters.  I don't recall any where this was a problem.  Usually it's as harmless as users specifying other defaults like `action='store'`, or a dest that echos a long option, etc.

But if we are going to fix the wrong default statement in `store_const`, we might as well clarify this case as well.

I wonder if this is the time and place to add a note that specifying 'type' is not necessary (and even wrong) - re. this closed issue: http://bugs.python.org/issue24754 

Is the line  'These are special cases of ``'store_const'``' useful?   The statement echos the class definition

    class _StoreTrueAction(_StoreConstAction)

but I'm not sure it adds much to the user's understanding.  'store_true' and 'store_false' are used frequently; 'store_const' is much less common (based on SO questions).

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

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

From report at bugs.python.org  Wed Oct  7 03:51:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 01:51:04 +0000
Subject: [docs] [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1444182664.57.0.925523025009.issue22865@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you return null bytes, they will be written to the parent process?s stdout file descriptor, rather than being ignored. I do not think it is possible to ignore output with the spawn() API, unless perhaps you previously set up stdout write to /dev/null or similar.

Do you have a reference for your fact about terminals ignoring null input bytes? I?m skeptical because a basic serial terminal can send arbitrary data including nulls, but I am not so familiar with pseudo-terminals.

However the bit about interpreting an empty string could be useful. I would drop the ?or any falsey value?; is that a typo? I suspect that the functions have to return byte strings (not text). It would be nice to say what the consequences of the EOF condition is, e.g. I can see for the child?s output it would stop copying, but not actually close the parent?s stdout to signal EOF. What about in the other direction? Can you signal multiple EOFs with data in between?

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

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

From report at bugs.python.org  Wed Oct  7 04:34:43 2015
From: report at bugs.python.org (Geoff Shannon)
Date: Wed, 07 Oct 2015 02:34:43 +0000
Subject: [docs] [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1444185283.54.0.821676340433.issue22865@psf.upfronthosting.co.za>


Geoff Shannon added the comment:

Hmm, I spoke improperly.  I think you are entirely correct in your statements.  What I meant by "terminals ignore null bytes" is that returning a string consisting of only a null byte doesn't cause anything observable to happen, including anything to be written to the screen.  But I have no idea why this is.

My basis for this is limited to empirical observation of how my terminal behaves (I use the iTerm2 terminal emulator on Mac OS X), and I don't recall whether I checked it with other terminals like the regular terminal on Mac and terminal emulators on Linux.

Re: "or any falsey value".  In general, the _read_ functions should return byte strings yes, but since the check for EOF in python is whether a stream returned an empty string, and the way that pty.spawn() currently checks for that is `if not data` then any falsey value will cause pty.spawn to think that the underlying fd was closed.

I agree that the documentation on this could use more fleshing out in general, especially regarding what happens when certain values are returned.  I'm not very familiar with this code any more, but I might have time to play with it and try to add some more information in the coming weeks.

----------

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

From report at bugs.python.org  Wed Oct  7 05:52:06 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Oct 2015 03:52:06 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444189926.83.0.233354206198.issue25294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

We seem to be talking past each other, so let's take a step back and ensure we have a common understanding of the absolute/relative terminology:

"import x.y.z" is an absolute import
"from x.y import z" is still an absolute import.
"from . import z" is an explicit relative import of a child or sibling module
"from .y import z" is also an explicit relative import

The relevant change in behaviour is between the "import x.y.z" form and the "from x.y import z" form due to the change in the way the related name binding (and name lookup in 3.5+) works, not between absolute and relative imports.

The relevant terminology to distinguish between "from ... import ..." vs "import ..." is just "from import" vs "non-from import", and there are definitely cases where from imports will work, but non-from imports will fail. That's not a style issue, it's a use-whichever-one-works for your code issue.

----------

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

From report at bugs.python.org  Wed Oct  7 06:08:36 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Oct 2015 04:08:36 +0000
Subject: [docs] [issue25294] Absolute imports fail in some cases where
 relative imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444190916.13.0.862692679891.issue25294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(Oops, it seems Brett already clarified the terminology. My apologies for the noise).

Modularity and module design is hard. It's one of the hardest problems in software engineering, which is why folks invent entire new vocabularies to attempt to describe the problem space effectively: http://connascence.io/

The simplest way to avoid these kinds of import related problems as a beginner in Python is to just put all your code in one module, and only factor it out into multiple modules when the single file becomes difficult to maintain.

Unfortunately, Java's "one public class per file" restriction, it's lack of standalone module level functions, and it's popularity as a university level teaching level has given a lot of people a lot of bad ideas as to what good multi-level modularity looks like, as Java throws out the notion of using modules to group closely related public classes and standalone functions into a single file, and instead makes you jump almost directly from classes to packages.

So perhaps that's the currently unwritten rule that would be worth documenting? That Python has 3 levels of namespacing (classes, modules, packages), and that flat namespaces are preferred in the standard library. If the namespace is broken up internally into multiple files for maintainability reasons, we prefer to still present a flat *public* API, as unittest, asyncio and concurrent.futures do.

----------

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

From report at bugs.python.org  Wed Oct  7 08:46:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 06:46:27 +0000
Subject: [docs] [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1444200387.06.0.572230946001.issue22865@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would avoid suggesting one can return non-byte-strings; treat that as an implementation detail. Maybe something like:

The functions *master_read* and *stdin_read* are passed a file descriptor which they should read from, and should return a byte string. The defaults try to read 1024 bytes each time they are called. Returning an empty string is be interpreted as an EOF condition, and the *_read* function will no longer be called.

----------

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

From report at bugs.python.org  Wed Oct  7 11:47:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 09:47:54 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1444211274.62.0.952625737442.issue25286@psf.upfronthosting.co.za>


Martin Panter added the comment:

Will commit this patch, except for the :dfn:`view` part. That isn?t a hyperlink, it just emphasizes the term.

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

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

From report at bugs.python.org  Wed Oct  7 12:09:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 10:09:32 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <20151007100928.97710.72773@psf.io>


Roundup Robot added the comment:

New changeset 92429e01f444 by Martin Panter in branch '3.4':
Issue #25286: Dictionary views are not sequences
https://hg.python.org/cpython/rev/92429e01f444

New changeset c29f1114ef65 by Martin Panter in branch '3.5':
Issue #25286: Merge dictionary view glossary from 3.4 into 3.5
https://hg.python.org/cpython/rev/c29f1114ef65

New changeset d43c33f032a2 by Martin Panter in branch '3.5':
Issue #25286: Update dictionary view link; patch by Akira Li
https://hg.python.org/cpython/rev/d43c33f032a2

New changeset 7067420c3e72 by Martin Panter in branch 'default':
Issue #25286: Merge dictionary view glossary from 3.5
https://hg.python.org/cpython/rev/7067420c3e72

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

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

From report at bugs.python.org  Wed Oct  7 12:24:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 10:24:01 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <20151007102357.18382.80158@psf.io>


Roundup Robot added the comment:

New changeset 41e1f2500047 by Martin Panter in branch '2.7':
Issue #25286: Dictionary views are not sequences
https://hg.python.org/cpython/rev/41e1f2500047

----------

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

From report at bugs.python.org  Wed Oct  7 12:36:38 2015
From: report at bugs.python.org (Laura Creighton)
Date: Wed, 07 Oct 2015 10:36:38 +0000
Subject: [docs] [issue25331] https://docs.python.org/3.5/using/windows.html
 should list whcih windows service packs are
Message-ID: <1444214198.22.0.92198325395.issue25331@psf.upfronthosting.co.za>


New submission from Laura Creighton:

https://docs.python.org/3.5/using/windows.html should list which
windows service packs are needed to install Python.  Could somebody knowledgable please add this information.

----------
assignee: docs at python
components: Documentation, Windows
messages: 252460
nosy: docs at python, lac, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: https://docs.python.org/3.5/using/windows.html should list whcih windows service packs are

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

From report at bugs.python.org  Wed Oct  7 12:40:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 10:40:55 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <20151007104052.70994.13482@psf.io>


Roundup Robot added the comment:

New changeset 04815b55227f by Martin Panter in branch '2.7':
Issue #25286: Accidentally dropped "the"
https://hg.python.org/cpython/rev/04815b55227f

----------

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

From report at bugs.python.org  Wed Oct  7 12:46:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 10:46:32 +0000
Subject: [docs] [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1444214792.5.0.838066607573.issue25286@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Akira

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Thu Oct  8 04:20:40 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 08 Oct 2015 02:20:40 +0000
Subject: [docs] [issue25337] weakref.finalize documentation refers to old
 interpreter shutdown behavior
Message-ID: <1444270840.16.0.813580393824.issue25337@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

In weakref.finalize's documentation ( https://docs.python.org/3/library/weakref.html#weakref.finalize ), it says:

"A finalizer will never invoke its callback during the later part of the interpreter shutdown when module globals are liable to have been replaced by None."

While it may not invoke its callback during shutdown (I don't know if it does, or if it should), as of Python 3.4 (which is when weakref.finalize was introduced), module globals aren't set to None anymore, right? https://docs.python.org/3/whatsnew/3.4.html#whatsnew-pep-442

Presumably the docs should be updated not to mention a behavior that no longer occurs (and if it will or should be invoked, weakref.finalizer should have documentation or code updated).

----------
assignee: docs at python
components: Documentation
messages: 252504
nosy: docs at python, josh.r
priority: normal
severity: normal
status: open
title: weakref.finalize documentation refers to old interpreter shutdown behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct  8 05:35:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 03:35:07 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <20151008033504.3281.97119@psf.io>


Roundup Robot added the comment:

New changeset f4606117d571 by Berker Peksag in branch '3.4':
Issue #16802: Document fileno parameter of socket.socket()
https://hg.python.org/cpython/rev/f4606117d571

New changeset 1d14675c6050 by Berker Peksag in branch '3.5':
Issue #16802: Document fileno parameter of socket.socket()
https://hg.python.org/cpython/rev/1d14675c6050

New changeset 9115c63cf3d2 by Berker Peksag in branch 'default':
Issue #16802: Document fileno parameter of socket.socket()
https://hg.python.org/cpython/rev/9115c63cf3d2

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

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

From report at bugs.python.org  Thu Oct  8 05:36:07 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 08 Oct 2015 03:36:07 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1444275367.4.0.843577896842.issue16802@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

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

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

From report at bugs.python.org  Thu Oct  8 17:43:17 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 08 Oct 2015 15:43:17 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444318997.95.0.470101159956.issue25343@psf.upfronthosting.co.za>


Changes by Dima Tisnek <dimaqq at gmail.com>:


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

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

From report at bugs.python.org  Thu Oct  8 17:55:49 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Thu, 08 Oct 2015 15:55:49 +0000
Subject: [docs] [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444319746.95.0.768076912444.issue25161@psf.upfronthosting.co.za>


TAKASE Arihiro added the comment:

Thank you for reviewing.

This is an updated patch for 3.x.

----------
Added file: http://bugs.python.org/file40718/periods_v2.patch

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

From report at bugs.python.org  Thu Oct  8 18:05:00 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Thu, 08 Oct 2015 16:05:00 +0000
Subject: [docs] [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444320299.18.0.929378291444.issue25161@psf.upfronthosting.co.za>


TAKASE Arihiro added the comment:

And this is an updated patch for 2.7.

----------
Added file: http://bugs.python.org/file40720/periods-2.7_v2.patch

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

From report at bugs.python.org  Thu Oct  8 19:14:47 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Oct 2015 17:14:47 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444324486.94.0.999093910412.issue25343@psf.upfronthosting.co.za>


Brett Cannon added the comment:

We actually don't have any guarantees written down because we have never formalized them. It was discussed at the PyCon language summit this past year -- https://lwn.net/Articles/640177/ -- but it didn't lead to anyone writing a proposal to formalize the memory model.

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

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

From report at bugs.python.org  Thu Oct  8 19:29:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2015 17:29:21 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444325361.8.0.782477157949.issue25343@psf.upfronthosting.co.za>


R. David Murray added the comment:

I wonder...personally I prefer to program in asyncio style rather than threading style, where one doesn't have to worry about atomicity.  Maybe Python shouldn't make any atomicity guarantees.

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

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

From report at bugs.python.org  Fri Oct  9 02:37:35 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 00:37:35 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444351054.9.0.260589730505.issue25343@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> what set() operations are atomic?

The language doesn't make any guarantees about set operation atomicity.  Different implementations such as PyPy, Jython, and IronPython are free to make different choices than CPython.  In general, users should make no assumptions about atomicity unless explicitly documented and tested.  The wise course of action is to use mutexes when there is any doubt.

FWIW, it is difficult to make blanket statements about the methods on sets because the atomicity depends on the objects looked up or stored in the sets rather than the set itself.   Aside from trivial calls to __sizeof__ and __len__, most set methods potentially call __hash__ or __eq__ on the set elements either of which could make a callback into pure python code.  Likewise, any reference count decrement can potentially make a callback as well.

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

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

From report at bugs.python.org  Fri Oct  9 20:55:55 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 18:55:55 +0000
Subject: [docs] [issue25331] Using Windows doc should list service packs
 needed to install
In-Reply-To: <1444214198.22.0.92198325395.issue25331@psf.upfronthosting.co.za>
Message-ID: <1444416955.45.0.883825220128.issue25331@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
title: https://docs.python.org/3.5/using/windows.html should list whcih windows service packs are -> Using Windows doc should list service packs needed to install
type:  -> enhancement
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct  9 22:23:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 20:23:19 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444422199.05.0.874183765023.issue25343@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This question has been asked multiple times before.  I think it should be documented that as far as the language goes, there is no answer.  Raymond's answer is a start.  Dima, where would you expect to find such a disclaimer (other than in the FAQ)?

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

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

From report at bugs.python.org  Fri Oct  9 22:32:05 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Fri, 09 Oct 2015 20:32:05 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444422725.35.0.227913307912.issue25343@psf.upfronthosting.co.za>


Dima Tisnek added the comment:

Ideally I'd like 2 sources:

1. a whole section on atomic operations in language and CPython implementation

2. annotation of standard library methods, e.g.:
set().add(element)  [atomic] or [CPython: atomic(*)]
(*) assuming basic types, note about what custom methods would break this guarantee; the reference could be to 1.

----------

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

From report at bugs.python.org  Fri Oct  9 22:42:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 20:42:01 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444423321.72.0.194772992044.issue25343@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think what Terry was asking was, where would you expect to see the disclaimer that *no* operations are guaranteed to be atomic?  That's what we're inclining toward (though we'll probably need a signoff from Guido).

----------

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

From report at bugs.python.org  Fri Oct  9 22:56:57 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Fri, 09 Oct 2015 20:56:57 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444424217.1.0.321121377898.issue25343@psf.upfronthosting.co.za>


Dima Tisnek added the comment:

To clarify, Python language disclaimer can be in the general atomic operations or multithreading section.

What I'd really like to see is documented, practical CPython and stdlib behaviour.

I'm under the impression that there's quite a bit of code out there that relies on what's actually atomic in CPython.

d.

----------

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

From report at bugs.python.org  Fri Oct  9 23:31:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 21:31:07 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444426267.48.0.600647018276.issue25343@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think you are correct, and I wouldn't be surprised if there is some in the stdlib as well.

----------

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

From report at bugs.python.org  Sat Oct 10 00:40:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 22:40:32 +0000
Subject: [docs] [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444430432.5.0.336263896176.issue25343@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Yes, I was asking where to put the disclaimer.  The thread docs would be approriate if there is nothing already.

Guido has been very reluctant to put any performance guarantees in the language reference.  I believe he said that O(f(n)) info even for CPython should be in the wiki -- and taken as a guideline, not a iron guarantee.

Further discussion might be better directed to python-ideas, after a search of the pydev and python-ideas archives (most easily done with the gmane mirrors, I believe).

----------

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

From report at bugs.python.org  Sat Oct 10 04:21:45 2015
From: report at bugs.python.org (Sebastian A. Brachi)
Date: Sat, 10 Oct 2015 02:21:45 +0000
Subject: [docs] [issue24978] Contributing to Python 2x and 3x Documentation.
 Translation to Russian.
In-Reply-To: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za>
Message-ID: <1444443705.12.0.236559630099.issue24978@psf.upfronthosting.co.za>


Sebastian A. Brachi added the comment:

> I wrote a proposal to the board a while ago
I couldn't find that proposal, could you post a link to it? Thanks!

----------
nosy: +Sebastian A. Brachi

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

From report at bugs.python.org  Sat Oct 10 04:39:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 02:39:45 +0000
Subject: [docs] [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444444785.29.0.791560051507.issue22413@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the feedback. Yeah, 2.7 is an independent branch, but I will try porting the changes there.

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

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

From john.wu at bcdtravel.cn  Fri Oct  9 01:51:49 2015
From: john.wu at bcdtravel.cn (john wu)
Date: Thu, 8 Oct 2015 23:51:49 +0000
Subject: [docs] A small mistake in tutorial of docs.python 3.4
Message-ID: <e8e8fd30e61d469592936a647703b959@CASMBX01.bcdtravel.cn>

Dear,

The space between "C>" and "print('Yuck!") makes an error, "unexpected indent".
Hope it will help you.

(pic1)
[cid:image001.png at 01D10267.4DAD5FF0]

(pic2)
[cid:image002.png at 01D10267.7F10CEB0]



Thank you.
Best regards,

John  Wu
Product Manager - China | BCD Travel
6/F, Building 3B, South Section
Shanghai TianHua Info. Science and Tech. Park
No.195 Long Tian Road | Shanghai, 200235 |China

T +86 6132 8586
This message and any attachment(s) are intended only for the use of the person or entity to which it is addressed and may contain confidential and/or proprietary information.  Any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this message and any attachment(s) by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply email and delete this message, including any attachments. Sender accepts no liability for any damages caused by any virus transmitted by this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151008/345f691e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20192 bytes
Desc: image001.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151008/345f691e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 17312 bytes
Desc: image002.png
URL: <http://mail.python.org/pipermail/docs/attachments/20151008/345f691e/attachment-0003.png>

From report at bugs.python.org  Sat Oct 10 12:31:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 10:31:03 +0000
Subject: [docs] [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444473063.49.0.129327166863.issue25161@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct 10 12:31:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 10:31:23 +0000
Subject: [docs] [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <20151010103120.2695.35465@psf.io>


Roundup Robot added the comment:

New changeset 57fc950298bb by Martin Panter in branch '2.7':
Issue #22413: Document newline effect on StringIO initializer and getvalue
https://hg.python.org/cpython/rev/57fc950298bb

New changeset cba4bf2a1721 by Martin Panter in branch '3.4':
Issue #22413: Document newline effect on StringIO initializer and getvalue
https://hg.python.org/cpython/rev/cba4bf2a1721

New changeset 451da3327f68 by Martin Panter in branch '3.5':
Issue #22413: Merge StringIO doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/451da3327f68

New changeset 46df76819b79 by Martin Panter in branch '3.5':
Issue #22413: Remove comment made out of date by Argument Clinic
https://hg.python.org/cpython/rev/46df76819b79

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

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

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

From report at bugs.python.org  Sat Oct 10 12:37:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 10:37:49 +0000
Subject: [docs] [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444473469.67.0.704882783926.issue22413@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct 10 12:43:24 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 10:43:24 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
Message-ID: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>


New submission from Laura Creighton:

Another report in to webmaster:
I tried to install Python 3.5.0 from [1]https://www.python.org/ftp/python/
3.5.0/python-3.5.0.exe but I get an error and I'm not able to install, is
this exe compiled with SSE2 instructions? Apparently no msi available

Does this need a mention somewhere?

----------
assignee: docs at python
components: Documentation, Installation, Windows
messages: 252703
nosy: docs at python, lac, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Is python-3-5-0.exe compiled with SSE2 instrutions? If so should we mention this?
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 12:53:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 10:53:42 +0000
Subject: [docs] [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <20151010105339.471.42988@psf.io>


Roundup Robot added the comment:

New changeset 4dfead9635e5 by Martin Panter in branch '3.4':
Issue #25161: Add full stops in documentation; patch by Takase Arihiro
https://hg.python.org/cpython/rev/4dfead9635e5

New changeset be34d96e2184 by Martin Panter in branch '3.5':
Issue #25161: Merge full stops from 3.4 into 3.5
https://hg.python.org/cpython/rev/be34d96e2184

New changeset fe87a6f9caa7 by Martin Panter in branch 'default':
Issue #25161: Merge full stops from 3.5
https://hg.python.org/cpython/rev/fe87a6f9caa7

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

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

From report at bugs.python.org  Sat Oct 10 12:57:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 10:57:55 +0000
Subject: [docs] [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <20151010105751.477.39453@psf.io>


Roundup Robot added the comment:

New changeset b9a0ecae02cb by Martin Panter in branch '2.7':
Issue #25161: Add full stops in documentation; patch by Takase Arihiro
https://hg.python.org/cpython/rev/b9a0ecae02cb

----------

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

From report at bugs.python.org  Sat Oct 10 13:41:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 11:41:53 +0000
Subject: [docs] [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444477313.61.0.177654429538.issue25161@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks very much for the patches.

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

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

From report at bugs.python.org  Sat Oct 10 14:10:17 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 12:10:17 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444479017.05.0.0332061077722.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

With Visual Studio 2010 and earlier, SSE support had to be explicitly enabled. Starting with VS2012 it's on by default [1]:

    Because the x86 compiler generates code that uses SSE2 
    instructions by default, you must specify /arch:IA32 to 
    disable generation of SSE and SSE2 instructions for x86 
    processors.

For 3.5, the 32-bit build does use SSE2 instructions. For example, float_add uses the addsd instruction (opcode F2 0F 58):

    0:000> s python35!float_add l100 f2 0f 58
    71f6c5d8  f2 0f 58 44 24 08 8b 0d-84 11 18 72 f2 0f 11 44  ..XD$......r...D
    0:000> u 71f6c5d8 l3
    python35!float_add+0x98:
    71f6c5d8 f20f58442408    addsd   xmm0,mmword ptr [esp+8]
    71f6c5de 8b0d84111872    mov     ecx,dword ptr [python35!free_list (72181184)]
    71f6c5e4 f20f11442410    movsd   mmword ptr [esp+10h],xmm0

Thus 3.5 doesn't support older CPUs that lack SSE2, such as the AMD Athlon XP. I didn't check the installer itself, but that would be a pointless exercise.

[1]: https://msdn.microsoft.com/en-us/library/7t5yh4fd

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

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

From report at bugs.python.org  Sat Oct 10 14:42:34 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 12:42:34 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444480954.61.0.59283288583.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Okay then, wherever we put the -- Beginning with 3.5 we are not
supporting 3.5 we need to also tell people whose CPUs lack SSE2
that they are out of luck, as well.

----------

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

From report at bugs.python.org  Sat Oct 10 16:03:45 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 10 Oct 2015 14:03:45 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444485825.09.0.727204336268.issue25361@psf.upfronthosting.co.za>


Steve Dower added the comment:

Did that report come with any reason for SSE to be relevant, such as an error message or log file?

Windows requires SSE these days, since Vista IIRC, so the problem is probably someone on XP.

----------

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

From report at bugs.python.org  Sat Oct 10 19:06:30 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 17:06:30 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444496790.06.0.76910603436.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Further conversation has confirmed that the person is on XP.

----------

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

From report at bugs.python.org  Sat Oct 10 19:08:55 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 17:08:55 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444496935.76.0.0399261128747.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

He says that he got an error saying something was compiled SSE2 and needed to be SSE, but if we are going to detect XP then that will be
a better error message.

----------

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

From report at bugs.python.org  Sat Oct 10 21:29:43 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 19:29:43 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444505383.8.0.295992074886.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

> Windows requires SSE these days, since Vista IIRC, so the problem 
> is probably someone on XP.

Windows 8 is the first to require SSE2 [1][2]. I'm sure it's no coincidence that this became the default in VS 2012. 

There is probably a small minority of users that upgraded to 32-bit Windows 7 on old hardware. Python 3.5 excludes them, but I don't think the build should switch to using /arch:IA32 just to support them. If a user on such a system really needs 3.5, it's possible to create a private build without SSE2. Most packages that have extension modules will also have to be built from source instead of using prebuilt wheels.

[1]: http://windows.microsoft.com/en-us/windows7/products/system-requirements
[2]: http://windows.microsoft.com/en-US/windows-8/system-requirements

----------

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

From report at bugs.python.org  Sat Oct 10 21:41:39 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 19:41:39 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444506099.01.0.629729670885.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Ok, where do we put the info about how to create a private build?  And
who will write it?  (I lack the understanding.) Does it belong in:
https://docs.python.org/3/using/windows.html

or some place else?

----------

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

From report at bugs.python.org  Sat Oct 10 22:06:33 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 20:06:33 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444507593.14.0.343695432563.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

Building Python 3.5 requires Visual Studio 2015 and Windows 8.1, so this would be a vanishingly small audience that's building to deploy on old 32-bit Windows 7 machines. I don't think the PSF needs to worry about this. Anyway, the "/arch (x86)" docs [1] explain how to configure a project to use IA32, and PCBuild/readme.txt [2] explains how to build Python using Visual Studio 2015. I know this doesn't really help a novice user; just tell them to install Python 3.4!

[1]: https://msdn.microsoft.com/en-us/library/7t5yh4fd

----------

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

From report at bugs.python.org  Sat Oct 10 22:08:47 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 20:08:47 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444507727.65.0.355380098708.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

Sorry, I forgot to include the link to readme.txt:

[2]: https://hg.python.org/cpython/file/v3.5.0/PCbuild/readme.txt

----------

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

From report at bugs.python.org  Sun Oct 11 01:53:39 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 10 Oct 2015 23:53:39 +0000
Subject: [docs] [issue25371] select.select docstring needs comma
Message-ID: <1444521219.18.0.906188853689.issue25371@psf.upfronthosting.co.za>


New submission from Chris Angelico:

The grammar of the IMPORTANT NOTICE on the select module and the select.select function wants a comma, I think. Patch attached.

----------
assignee: docs at python
components: Documentation
files: add_comma.patch
keywords: patch
messages: 252750
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: select.select docstring needs comma
Added file: http://bugs.python.org/file40745/add_comma.patch

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

From report at bugs.python.org  Sun Oct 11 04:32:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 02:32:51 +0000
Subject: [docs] [issue25371] select.select docstring needs comma
In-Reply-To: <1444521219.18.0.906188853689.issue25371@psf.upfronthosting.co.za>
Message-ID: <20151011023246.128826.30464@psf.io>


Roundup Robot added the comment:

New changeset 99c82576bb70 by Benjamin Peterson in branch '3.4':
add a missing comma (closes #25371)
https://hg.python.org/cpython/rev/99c82576bb70

New changeset ae98209ff69a by Benjamin Peterson in branch '3.5':
merge 3.4 (#25371)
https://hg.python.org/cpython/rev/ae98209ff69a

New changeset d2d8c1c8c258 by Benjamin Peterson in branch 'default':
merge 3.5 (#25371)
https://hg.python.org/cpython/rev/d2d8c1c8c258

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

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

From report at bugs.python.org  Sun Oct 11 06:46:16 2015
From: report at bugs.python.org (John Michael Lafayette)
Date: Sun, 11 Oct 2015 04:46:16 +0000
Subject: [docs] [issue25374] Deficiencies in type hint usage in Python
 standard libraries
Message-ID: <1444538776.34.0.720036996405.issue25374@psf.upfronthosting.co.za>


New submission from John Michael Lafayette:

I love the new type hint feature in Jetbrains IDE (PEP 0484). Now when my user defined methods return a value, I can press (Crtl+space) and see the type of that value and all its methods. Also, when I pass the wrong type in, I get a warning. 

Oddly, this does not happen with Python standard library functions. I can't get the auto-complete on objects returned by the Python standard library. The Python standard library doesn't warn me in advance if I put the wrong type in a method. How does that make sense? Please support PEP 0484 by using it in the Python standard library where appropriate.

----------
assignee: docs at python
components: Documentation
messages: 252758
nosy: John Michael Lafayette, docs at python
priority: normal
severity: normal
status: open
title: Deficiencies in type hint usage in Python standard libraries
type: behavior

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

From report at bugs.python.org  Sun Oct 11 08:15:03 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 06:15:03 +0000
Subject: [docs] [issue25375] Don't mention 2.2 in the 3.x docs
Message-ID: <1444544103.53.0.168517351377.issue25375@psf.upfronthosting.co.za>


New submission from Chris Angelico:

See: https://mail.python.org/pipermail/python-list/2015-October/697818.html

Saying "In Python 2.2" is not helpful in the 3.x docs. Even in the 2.x docs, it's pretty safe to assume by now that everyone's on 2.2+. (At very least, "Since" would be better than "If".) Patch attached.

I suspect that a lot of that FAQ is outdated now, though.

----------
assignee: docs at python
components: Documentation
files: no_mention_2.2.patch
keywords: patch
messages: 252769
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: Don't mention 2.2 in the 3.x docs
Added file: http://bugs.python.org/file40750/no_mention_2.2.patch

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

From report at bugs.python.org  Sun Oct 11 08:25:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 06:25:04 +0000
Subject: [docs] [issue25375] Don't mention 2.2 in the 3.x docs
In-Reply-To: <1444544103.53.0.168517351377.issue25375@psf.upfronthosting.co.za>
Message-ID: <20151011062501.18376.75897@psf.io>


Roundup Robot added the comment:

New changeset a81b47fb5848 by Benjamin Peterson in branch '2.7':
don't mention Python 2.2 (closes #25375)
https://hg.python.org/cpython/rev/a81b47fb5848

New changeset 275d388ca1fc by Benjamin Peterson in branch '3.4':
don't mention Python 2.2 (closes #25375)
https://hg.python.org/cpython/rev/275d388ca1fc

New changeset 0017245ff5ce by Benjamin Peterson in branch 'default':
merge 3.5 (#25375)
https://hg.python.org/cpython/rev/0017245ff5ce

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

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

From report at bugs.python.org  Sun Oct 11 16:20:47 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Oct 2015 14:20:47 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444573247.39.0.803847698017.issue25361@psf.upfronthosting.co.za>


Steve Dower added the comment:

Since we officially support platforms that don't require SSE, I'll disable those instructions for 3.5.1.

As eryksun points out, this doesn't affect 64-bit builds, which are the standard for most performance critical uses anyway.

----------
assignee: docs at python -> steve.dower
components: +Build, Distutils -Documentation, Installation
keywords: +3.5regression
nosy: +dstufft, eric.araujo

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

From report at bugs.python.org  Sun Oct 11 16:39:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 14:39:39 +0000
Subject: [docs] [issue25374] Deficiencies in type hint usage in Python
 standard libraries
In-Reply-To: <1444538776.34.0.720036996405.issue25374@psf.upfronthosting.co.za>
Message-ID: <1444574379.55.0.93033162922.issue25374@psf.upfronthosting.co.za>


R. David Murray added the comment:

You need to install the (currently externally maintained) type hints files from https://github.com/python/typeshed.  I don't think a decision has been made about if/when these files will be incorporated into the distribution.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Oct 11 17:36:26 2015
From: report at bugs.python.org (Karl Richter)
Date: Sun, 11 Oct 2015 15:36:26 +0000
Subject: [docs] [issue25377] Mention octal format of mode argument of
	os.chmod
Message-ID: <1444577786.91.0.966567920628.issue25377@psf.upfronthosting.co.za>


New submission from Karl Richter:

`help(os.chmod)` doesn't explain that it expects an octal number for its `mode` argument. This is very confusing for beginners and people who are not involved with filesystems and permissions every day. It doesn't need to be explained, just mentioned, maybe with a link to an extended explanation.

Example for confusion: http://stackoverflow.com/questions/15607903/python-module-os-chmodfile-664-does-not-change-the-permission-to-rw-rw-r-bu

----------
assignee: docs at python
components: Documentation
messages: 252817
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Mention octal format of mode argument of os.chmod
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 11 17:46:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 15:46:55 +0000
Subject: [docs] [issue25377] Mention octal format of mode argument of
	os.chmod
In-Reply-To: <1444577786.91.0.966567920628.issue25377@psf.upfronthosting.co.za>
Message-ID: <1444578415.69.0.983788091857.issue25377@psf.upfronthosting.co.za>


R. David Murray added the comment:

The main docs do not mention octal, but instead point to the constants in the stat module.  The help text currently says "Operating-system mode bitfield", which is in fact accurate.  A decimal number is *not* a bitfield (although it can be interpreted as one, giving the unexpected results).  

However, the help doc could be enhanced to say "Operating-system mode bitfield, see stat module for symbolic constants.".

Basically, the fact that octal works is an historical accident due to it working that way on unix, but ideally should not be relied upon by python code (though of course it will be :).

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

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

From report at bugs.python.org  Sun Oct 11 18:34:26 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Oct 2015 16:34:26 +0000
Subject: [docs] [issue25377] Mention octal format of mode argument of
	os.chmod
In-Reply-To: <1444577786.91.0.966567920628.issue25377@psf.upfronthosting.co.za>
Message-ID: <1444581266.12.0.464865917425.issue25377@psf.upfronthosting.co.za>


Georg Brandl added the comment:

A short sentence like 

Be careful when using number literals for *mode*. The conventional UNIX notation for numeric modes uses an octal base, which needs to be indicated with a ``0o`` prefix in Python.

should be a good addition here.  (I wonder why it isn't there, I seem to recall an earlier issue about this.)

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

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

From report at bugs.python.org  Sun Oct 11 20:39:02 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sun, 11 Oct 2015 18:39:02 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444588742.31.0.80924778937.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Another 2 bits of data:

I now know of 2 separate users from a Swedish teenager mailing list, whose machines (in each case 'my father's old laptop') didn't have SSE2.  One youth was running XP but spent today successfully migrating to windows 7 with help from her father.  The other was already running windows 7.

Neither of them had ever used Python before.  They are now running 
3.4.

----------

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

From ahmad.shrif at icloud.com  Sat Oct 10 16:16:51 2015
From: ahmad.shrif at icloud.com (Ahmad Shrif)
Date: Sat, 10 Oct 2015 15:16:51 +0100
Subject: [docs] Learning Python
Message-ID: <9E75C6B2-D6A2-4AFB-9694-30C915DE0506@icloud.com>

Hi Python 

I would like to learn programming and I was advised to start with Python. I started with your documentation but I find it difficult to grasp the information since I am non programmer and most of your documentation are for high level programmers.

Kindly, please advise the best documentation to start with as non programmer.

Your prompt reply is highly appreciated.

Regards,

Ahmad Shrif 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151010/52f8f5d8/attachment-0001.html>

From johnmichaelreedfas at gmail.com  Sun Oct 11 06:43:57 2015
From: johnmichaelreedfas at gmail.com (John Michael Lafayette)
Date: Sun, 11 Oct 2015 00:43:57 -0400
Subject: [docs] Deficiencies in type hint usage in Python standard libraries
Message-ID: <CACxkjvYrVdgVk8QCdqx1qrCvKYhrmtZ_WmdnOyT-d0Whf2Z9jw@mail.gmail.com>

I love the new type hint feature in Jetbrains IDE (PEP 0484). Now when my
user defined methods return a value, I can press (Crtl+space) and see the
type of that value and all its methods. Also, when I pass the wrong type
in, I get a warning.

Oddly, this does not happen with Python standard library functions. I can't
get the auto-complete on objects returned by the Python standard library.
The Python standard library doesn't warn me in advance if I put the wrong
type in a method. How does that make sense? Please support PEP 0484 by
using it in the Python standard library where appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151011/4cd699e4/attachment.html>

From lac at openend.se  Sun Oct 11 21:48:59 2015
From: lac at openend.se (Laura Creighton)
Date: Sun, 11 Oct 2015 21:48:59 +0200
Subject: [docs] Learning Python
In-Reply-To: <9E75C6B2-D6A2-4AFB-9694-30C915DE0506@icloud.com>
References: <9E75C6B2-D6A2-4AFB-9694-30C915DE0506@icloud.com>
Message-ID: <201510111948.t9BJmxqr011120@fido.openend.se>

In a message of Sat, 10 Oct 2015 15:16:51 +0100, Ahmad Shrif writes:
>Hi Python 
>
>I would like to learn programming and I was advised to start with Python. I started with your documentation but I find it difficult to grasp the information since I am non programmer and most of your documentation are for high level programmers.
>
>Kindly, please advise the best documentation to start with as non programmer.
>
>Your prompt reply is highly appreciated.
>
>Regards,
>
>Ahmad Shrif 

Welcome to Python.

Start here:
https://wiki.python.org/moin/BeginnersGuide/NonProgrammers

Also consider joining the tutor mailing list:
https://mail.python.org/mailman/listinfo/tutor


Laura Creighton


From report at bugs.python.org  Mon Oct 12 00:16:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 22:16:38 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <20151011221635.128836.40158@psf.io>


Roundup Robot added the comment:

New changeset 15f6bbe944fa by Steve Dower in branch '3.5':
Issue #25361: Disables use of SSE2 instructions in Windows 32-bit build
https://hg.python.org/cpython/rev/15f6bbe944fa

New changeset 3cf8c2930373 by Steve Dower in branch 'default':
Issue #25361: Disables use of SSE2 instructions in Windows 32-bit build
https://hg.python.org/cpython/rev/3cf8c2930373

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

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

From report at bugs.python.org  Mon Oct 12 00:17:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Oct 2015 22:17:40 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444601860.65.0.232069040723.issue25361@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Mon Oct 12 10:11:36 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Oct 2015 08:11:36 +0000
Subject: [docs] [issue25381] Use old description of raise in Python3
Message-ID: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

In the first paragraph of https://docs.python.org/3/extending/extending.html#intermezzo-errors-and-exceptions,
it is wrong to use the sentence "the second argument to raise" since
the raise syntax has been changed in Python3.

----------
assignee: docs at python
components: Documentation
files: doc_extending.patch
keywords: patch
messages: 252848
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Use old description of raise in Python3
Added file: http://bugs.python.org/file40754/doc_extending.patch

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

From report at bugs.python.org  Mon Oct 12 10:18:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 08:18:55 +0000
Subject: [docs] [issue25381] Doc: Use old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444637935.71.0.507092999924.issue25381@psf.upfronthosting.co.za>


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


----------
title: Use old description of raise in Python3 -> Doc: Use old description of raise in Python3

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

From Connor.Wood at controlsdata.com  Mon Oct 12 15:25:47 2015
From: Connor.Wood at controlsdata.com (Wood, Connor)
Date: Mon, 12 Oct 2015 13:25:47 +0000
Subject: [docs] Possible exceptions not clearly detailed in Python 2.7.10
 documentation
Message-ID: <68383677daf34da4b807036a2a09a512@BHM1EX02.controlsdata.com>

Hi,

Today, I had difficulty outfitting my code with error detection and handling, owing primarily to the fact that, in the documentation, there is little indication of what the possible errors, and sub-error codes, can be thrown with each function. In many circumstances, I had to resort to various tidbits of knowledge around the Web.

I appreciate that, in many cases, the errors thrown are common sense (file doesn't exist, directory is read only, etc.), however there are a lot of cases where this is not immediately clear, and there is no clear place wherein the common errors are clearly detailed.

I do not know the state of more recent versions of the documentation, as I was solely working with the 2.7.10 version. That said, fixes with Python 3+ docs aren't as useful to myself and many others, as I am using version 2.7, and am unable to switch.

Many thanks,

Connor Wood
Software Engineering Intern

Rolls-Royce Controls and Data Services Limited
York Road
Hall Green
Birmingham
B28 8LN


This e-mail and any attachments may contain confidential or privileged information. If you are not the intended recipient or have received this e-mail in error, please notify the sender immediately by reply of e-mail and destroy all paper and electronic copies of the message.  If assistance is required please contact  it.security at controlsdata.com.  Please note distribution, disclosure of content or copying of this e-mail is prohibited.

Rolls-Royce Controls and Data Services Limited may intercept or monitor email traffic, data and also the content of email for operational reasons or for lawful business practices.

Registered office at Moor Lane, PO Box 31, Derby, DE24 8BJ. Company number 6686268. Registered in England.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151012/512191c0/attachment.html>

From report at bugs.python.org  Mon Oct 12 17:17:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:17:04 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444663024.62.0.523311920732.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

----------
nosy: +r.david.murray
stage:  -> commit review
title: Doc: Use old description of raise in Python3 -> Doc: Use of old description of raise in Python3
versions: +Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Oct 12 17:21:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:21:20 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444663280.55.0.631498792935.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

Actually, I take that back.  Shouldn't it be "the object passed *as* the exception object to raise?

----------

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

From report at bugs.python.org  Mon Oct 12 17:22:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:22:58 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444663378.32.0.763945940773.issue25381@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Oct 12 17:49:50 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Oct 2015 15:49:50 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444664990.57.0.849596125895.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

With this sentence

A second global variable stores the ?associated value? of the exception (the second argument to raise).

I think the phrase inside the parentheses is to explain the "associated value", which is usually a string passed to the exception object, not the exception object itself.

Do I misunderstand anything?

----------

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

From report at bugs.python.org  Mon Oct 12 17:57:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:57:28 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444665448.77.0.076000369867.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes.  The second element of the sys.exc_info result is the exception instance, not the argument to the exception constructor.  The old raise syntax allowed you to specify the exception instance as the second argument to raise, but if you specified a string it converted it to an exception instance using the first argument as the constructor to call.  So, the 2.7 docs aren't entirely accurate, since it isn't the second argument to raise that is stored, but the object that results from raise *processing* its second argument.

----------

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

From report at bugs.python.org  Mon Oct 12 18:34:17 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Oct 2015 16:34:17 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444667657.77.0.336196194985.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Oops, I misunderstand sys.exc_info all the time, sad :(

Now, both versions of doc are not correct. Please make them fixed.

----------

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

From lac at openend.se  Mon Oct 12 19:18:36 2015
From: lac at openend.se (Laura Creighton)
Date: Mon, 12 Oct 2015 19:18:36 +0200
Subject: [docs] Possible exceptions not clearly detailed in Python
	2.7.10 documentation
In-Reply-To: <68383677daf34da4b807036a2a09a512@BHM1EX02.controlsdata.com>
References: <68383677daf34da4b807036a2a09a512@BHM1EX02.controlsdata.com>
Message-ID: <201510121718.t9CHIaPO006866@fido.openend.se>

In a message of Mon, 12 Oct 2015 13:25:47 -0000, "Wood, Connor" writes:

>Hi, Today, I had difficulty outfitting my code with error detection
>and handling, owing primarily to the fact that, in the documentation,
>there is little indication of what the possible errors, and sub-error
>codes, can be thrown with each function. In many circumstances, I had
>to resort to various tidbits of knowledge around the Web.

Did you find this page?  
https://docs.python.org/2.7/library/exceptions.html

If so, was the problem that the documentation was too terse?  Or 
that it missed telling you waht you wanted to know? or something else?

Laura Creighton




From report at bugs.python.org  Tue Oct 13 05:18:14 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 03:18:14 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444706294.93.0.104170764692.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I fix my patch with David's comment.

----------
Added file: http://bugs.python.org/file40766/doc_extending2.patch

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

From report at bugs.python.org  Tue Oct 13 07:07:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 05:07:24 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444712844.69.0.815914782156.issue25381@psf.upfronthosting.co.za>


Martin Panter added the comment:

?Associated value? still seems a bit weird. I wonder if it would be clearer to say

The exception type is stored in a static global variable .?.?. A second global variable stores the exception instance passed to :keyword:`raise` .?.?.

Also further down that section it looks like there are other problems. ?Exception object? is perhaps actually a C object referencing the exception class (type). ?Python string object .?.?. stored as the "associated value"?? should perhaps be the exception instance (object). I think a long time ago Python may have actually worked this way, but not any more, and the whole section probably needs updating.

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

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

From report at bugs.python.org  Tue Oct 13 07:38:44 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 05:38:44 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444714724.26.0.370077841537.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Yes, you are right martin. It seems the whole chapter needs more updates, not only the bits I mentioned. I won't provide a new patch since I am not an English native and I am not sure I can provide an accurate and right description. Hope someone else may help.

----------

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

From report at bugs.python.org  Tue Oct 13 15:20:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 13:20:22 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444742422.77.0.980349516824.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

There's also the fact that the argument to raise can be an exception class, but the second element of sys.exc_info is still an instance of that class, which only occurred to me while reading your revised patch.

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

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

From report at bugs.python.org  Tue Oct 13 16:03:09 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 14:03:09 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444744988.95.0.337906406969.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Actually what I intend is that the exception object passed to raise is the exception instance raise finally throws (what is stored in the second variable). So it seems wise not to do any more for me. A single sentence has lead to confusion, not to mention more.

----------

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

From report at bugs.python.org  Tue Oct 13 16:29:02 2015
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vv?= =?utf-8?q?rgiou=29?=)
Date: Tue, 13 Oct 2015 14:29:02 +0000
Subject: [docs] [issue25393] 'resource' module documentation error
Message-ID: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou):

https://docs.python.org/3.5/library/resource.html

https://docs.python.org/3.5/library/resource.html#resource.RLIMIT_FSIZE ends with the sentence "This only affects the stack of the main thread in a multi-threaded process."

I believe this sentence should be appended to https://docs.python.org/3.5/library/resource.html#resource.RLIMIT_STACK

This error also exists in previous versions of python documentation.

----------
assignee: docs at python
components: Documentation
messages: 252935
nosy: docs at python, tzot
priority: normal
severity: normal
status: open
title: 'resource' module documentation error
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 14 18:21:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 16:21:53 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1444839712.81.0.22166557142.issue8952@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue is now 5 years old and it doesn't contain much information. It's more a TODO item, and I'm not more interested to work on it. So I close the issue. If you want to work on the doc, please write a patch ;-)

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

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

From report at bugs.python.org  Thu Oct 15 10:23:39 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Oct 2015 08:23:39 +0000
Subject: [docs] [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444897419.19.0.437888055324.issue25006@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Hi,

just another ping regarding this ticket. Since the last message, pybind11 now has:

- Documentation on readthedocs: http://pybind11.readthedocs.org/en/latest/
- Continuous integration tests: https://travis-ci.org/wjakob/pybind11
- A first stable release: https://github.com/wjakob/pybind11/releases

It would be fantastic if the Python documentation referenced it as an option for binding C++ code to Python.

Thanks,
Wenzel

----------

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

From report at bugs.python.org  Thu Oct 15 16:38:32 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2015 14:38:32 +0000
Subject: [docs] [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444919912.12.0.525254028644.issue25006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You could perhaps start by creating a PyPI entry for your package:
https://pypi.python.org/pypi?%3Aaction=search&term=pybind11&submit=search

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

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

From report at bugs.python.org  Thu Oct 15 16:55:24 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Oct 2015 14:55:24 +0000
Subject: [docs] [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444920924.3.0.778227819323.issue25006@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Dear Antoine,

I wonder if this makes sense, as pybind11 is a collection of C++ header files using the Python C API.

The library is meant to be used by other projects but does not generate any installable code by itself. (i.e. it isn't clear what pip install pybind11 should even do) I haven't seen any PyPI packages of this type, though I'm happy to be told otherwise.

Best,
Wenzel

----------

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

From report at bugs.python.org  Thu Oct 15 18:30:54 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Oct 2015 16:30:54 +0000
Subject: [docs] [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444926654.43.0.333073183591.issue25006@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Never mind -- I made an entry for it.

See https://pypi.python.org/pypi/pybind11/1.0

Thanks,
Wenzel

----------

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

From report at bugs.python.org  Thu Oct 15 18:40:17 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2015 16:40:17 +0000
Subject: [docs] [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444927217.53.0.148979836623.issue25006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, I think it doesn't hurt to advertise your project there.
As for the official Python docs, I can't answer -- someone who maintains them would have to chime in.

Perhaps you can also submit an addition to the packaging guide:
https://packaging.python.org/en/latest/extensions/

----------

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

From report at bugs.python.org  Fri Oct 16 00:16:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 15 Oct 2015 22:16:41 +0000
Subject: [docs] [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1444947401.87.0.0691246000567.issue25415@psf.upfronthosting.co.za>


Martin Panter added the comment:

?No public constructor? to me means that it is not defined how or if you can construct instances other than by the public subclasses. What do you expect to happen? How do you expect the public subclasses such as FileIO and BufferedReader to work if the base constructor does not work?

The other three base classes (RawIOBase, BufferedIOBase, TextIOBase) also say ?there is no public constructor?. However allowing custom subclasses of these is very useful, so I would actually be for removing these restrictions from the documentation, and instead saying that each constructor accepts no arguments.

----------
assignee:  -> docs at python
components: +Documentation, IO -Library (Lib)
nosy: +docs at python, martin.panter

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

From report at bugs.python.org  Fri Oct 16 01:05:33 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Thu, 15 Oct 2015 23:05:33 +0000
Subject: [docs] [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1444950333.36.0.620009592675.issue25415@psf.upfronthosting.co.za>


Gerrit Holl added the comment:

When the documentation says there is no public constructor, I expected it would be impossible to create instances, as in:

TypeError: cannot create 'builtin_function_or_method' instances

Perhaps I misunderstand the documentation.

----------

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

From report at bugs.python.org  Fri Oct 16 08:16:42 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Fri, 16 Oct 2015 06:16:42 +0000
Subject: [docs] [issue25418] Minor markup issue in reference/datamodel docs
Message-ID: <1444976202.25.0.459794059719.issue25418@psf.upfronthosting.co.za>


New submission from TAKASE Arihiro:

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

The closing parenthesis of "isinstance(obj, collections.Hashable)" is outside the markup.

The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: datamodel.patch
keywords: patch
messages: 253068
nosy: artakase, docs at python
priority: normal
severity: normal
status: open
title: Minor markup issue in reference/datamodel docs
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40792/datamodel.patch

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

From 94singhakanksha at gmail.com  Wed Oct 14 20:14:33 2015
From: 94singhakanksha at gmail.com (Akanksha Singh)
Date: Wed, 14 Oct 2015 23:44:33 +0530
Subject: [docs] (no subject)
Message-ID: <CANzy2MnfdcEzwgWjZYCHmWiKqDYWg7bVx3TwN-2_USrjWtAaYw@mail.gmail.com>

-2**4 gives answer -16 which should be positive ie ans=16.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151014/e4b9c927/attachment-0001.html>

From report at bugs.python.org  Fri Oct 16 10:22:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Oct 2015 08:22:59 +0000
Subject: [docs] [issue25418] Minor markup issue in reference/datamodel docs
In-Reply-To: <1444976202.25.0.459794059719.issue25418@psf.upfronthosting.co.za>
Message-ID: <20151016082255.471.28484@psf.io>


Roundup Robot added the comment:

New changeset 389c78c2c031 by Berker Peksag in branch '3.4':
Issue #25418: Fix markup in object.__hash__ documentation
https://hg.python.org/cpython/rev/389c78c2c031

New changeset f56006107a4b by Berker Peksag in branch '3.5':
Issue #25418: Fix markup in object.__hash__ documentation
https://hg.python.org/cpython/rev/f56006107a4b

New changeset 0aaadc1c60fd by Berker Peksag in branch 'default':
Issue #25418: Fix markup in object.__hash__ documentation
https://hg.python.org/cpython/rev/0aaadc1c60fd

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

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

From report at bugs.python.org  Fri Oct 16 10:24:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 16 Oct 2015 08:24:01 +0000
Subject: [docs] [issue25418] Minor markup issue in reference/datamodel docs
In-Reply-To: <1444976202.25.0.459794059719.issue25418@psf.upfronthosting.co.za>
Message-ID: <1444983841.91.0.380648153063.issue25418@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, thanks!

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

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

From zachary.ware+pydocs at gmail.com  Fri Oct 16 17:26:09 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 16 Oct 2015 10:26:09 -0500
Subject: [docs] (no subject)
In-Reply-To: <CANzy2MnfdcEzwgWjZYCHmWiKqDYWg7bVx3TwN-2_USrjWtAaYw@mail.gmail.com>
References: <CANzy2MnfdcEzwgWjZYCHmWiKqDYWg7bVx3TwN-2_USrjWtAaYw@mail.gmail.com>
Message-ID: <CAKJDb-O1Em4KzNscP3pOqDGhA2-Va9+cBMkM-GjzU+3T=vMmXg@mail.gmail.com>

Hi,

On Wed, Oct 14, 2015 at 1:14 PM, Akanksha Singh
<94singhakanksha at gmail.com> wrote:
> -2**4 gives answer -16 which should be positive ie ans=16.

This is not the correct place to report behavioral bugs; this list is
for discussion of the Python documentation (including bug reports
about the docs).  Better would be either a post to python-list
(python-list at python.org) or a bug report on bugs.python.org.

However, in this case, there is no bug.  You're running into a common
misconception with operator precedence.  `-2**4` is evaluated as
`-(2**4)`, that is, "the negation of 2 to the power of 4."  To get
"the 4th power of negative 2", you'd need to do `(-2)**4`.  See
https://docs.python.org/3/reference/expressions.html#operator-precedence
for more information.

Hope this helps,
-- 
Zach

From zachary.ware+pydocs at gmail.com  Fri Oct 16 17:28:35 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 16 Oct 2015 10:28:35 -0500
Subject: [docs] A small mistake in tutorial of docs.python 3.4
In-Reply-To: <e8e8fd30e61d469592936a647703b959@CASMBX01.bcdtravel.cn>
References: <e8e8fd30e61d469592936a647703b959@CASMBX01.bcdtravel.cn>
Message-ID: <CAKJDb-MbLb-9n5MnZ=fOeJ=SofJytTqHZc4ro_CGPQ6vdjpNwA@mail.gmail.com>

Hi John,

On Thu, Oct 8, 2015 at 6:51 PM, john wu <john.wu at bcdtravel.cn> wrote:
> The space between ?C>? and ?print(?Yuck!?) makes an error, ?unexpected
> indent?.

Look carefully: the unexpected indent actually came from a mis-copy
when you assigned to sys.ps1.  The example shows "sys.ps1 = 'C> '"
(note the space after the >), while in your trial you did "sys.ps1 =
'C>'" (no space), then added the space when typing in the next line of
the example.  If you add the space in the assignment to sys.ps1, as in
the example, there is no error.

Hope this helps,
-- 
Zach

From report at bugs.python.org  Fri Oct 16 22:52:11 2015
From: report at bugs.python.org (Nan Wu)
Date: Fri, 16 Oct 2015 20:52:11 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445028731.75.0.964986876288.issue25017@psf.upfronthosting.co.za>


Nan Wu added the comment:

Added a small patched for this change.

----------
keywords: +patch
nosy: +Nan Wu
Added file: http://bugs.python.org/file40796/htmllib_deprecation_warning.patch

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

From report at bugs.python.org  Sat Oct 17 03:23:08 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2015 01:23:08 +0000
Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1445044988.04.0.267926829858.issue25381@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct 17 03:34:14 2015
From: report at bugs.python.org (leewz)
Date: Sat, 17 Oct 2015 01:34:14 +0000
Subject: [docs] [issue25428] Have `datetime` understand integer arguments
 for timezones
Message-ID: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>


New submission from leewz:

Current: If I want to create a datetime object with a particular timezone offset, I have to do this:
    
    import datetime
    mytime = datetime.datetime(2015, 10, 16, 9, 13, 0, tzinfo=datetime.timezone(datetime.timedelta(hours=-7)))

Or with imports:

    from datetime import datetime, timezone, timedelta
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=timezone(timedelta(hours=-7)))

That's two extra imports and two extra objects created.


Requested way:
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=-7)
    # mytime.tzinfo == -7

Or if someone doesn't like the `tzinfo` keyword:
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7)
    # mytime.tzinfo == timezone(timedelta(-7))


For timezones, hours are the normal unit of time. At least, I think about time zones in hours, and I don't know who would think about them in minutes. There are half-hour offsets, so floats make sense to have.

Imagine you have about a year of experience dabbling in Python, and you're trying to do a relatively simple task, like reading PDT times and converting them to local time. You would go to the datetime docs, see that you need to pass in a tzinfo object. You look that up, and run into this:
"""tzinfo is an abstract base class, meaning that this class should not be instantiated directly. You need to derive a concrete subclass, and (at least) supply implementations of the standard tzinfo methods needed by the datetime methods you use."""

Well, great. If you want to convert times, you'll have to subclass an abstract base class, and implement five methods. You'd probably have to read the whole docs for this class, too. (The docs for tzinfo take nine Page Downs for me to scroll past.)

If you're not frightened off by the first two sentences, you'll see that there's the concrete subclass `datetime.timezone`. We're two levels down, now. Going there, you'll see that you need to pass in a timedelta object. Three levels. You need to learn about three classes just to specify an hour offset.

Timezones are something that many non-programmers understand, and the rules are pretty simple (barring DST, but the library doesn't really deal with it anyway). Ideally, it should be simple to do simple things.


PS: There seems to be unnecessary inconsistency with `.astimezone`, `fromtimestamp`, and `now` taking a `tz` kwarg rather than a `tzinfo` kwarg.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 253111
nosy: docs at python, leewz
priority: normal
severity: normal
status: open
title: Have `datetime` understand integer arguments for timezones
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 17 03:48:18 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2015 01:48:18 +0000
Subject: [docs] [issue25428] Have `datetime` understand integer arguments
 for timezones
In-Reply-To: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>
Message-ID: <1445046498.0.0.757879768933.issue25428@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky, lemburg
versions:  -Python 3.5

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

From report at bugs.python.org  Sat Oct 17 04:15:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Oct 2015 02:15:12 +0000
Subject: [docs] [issue25428] Have `datetime` understand integer arguments
 for timezones
In-Reply-To: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>
Message-ID: <1445048112.15.0.137937767622.issue25428@psf.upfronthosting.co.za>


R. David Murray added the comment:

timezone is relatively new.  Work is in progress to add better timezone support to datetime, but it is a complicated subject and may or may not make it into 3.6.  In any case I think it is too soon to talk about this kind of API change, before the other work gets farther along.  That's probably also true for changes to the docs, although a concrete proposal there might have some chance.

There's a mailing list for talking specifically about datetime issues, you might want to post there (see mail.python.org, datetime-sig).

----------
nosy: +r.david.murray
resolution:  -> later
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct 17 05:37:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2015 03:37:21 +0000
Subject: [docs] [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1445053041.13.0.828117082873.issue25415@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Martin, I agree with changing the doc. Gerrit misunderstood because 'no public constructors' is either meaningless or wrong.  We do not usually talk about public versus private constructors.  This sounds more like C++ than Python.

For Python namespaces, names that start with '_' are private by convention unless documented otherwise.  Special names (__x__) are private in the sense that they are not usually used except by methods of the class; special methods are usually accessed by syntax or public names.  For class C, the default constructor is C.__new__, accessed by calling C.  (Let us not worry about other methods here.)  If C is a public name, with no '_', as is 'IOBase', then to me it has/is a public constructor.  Like other classes, IOBase has .__new__ and calling it produces an instance, as Gerrit discovered.  In that sense, it is not truly abstract.

I believe 'has no public constructor' is intended to mean 'has no documented signature and should not be *directly* called."  (If subclasses do call the base, then the signature should be documented.)

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

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

From report at bugs.python.org  Sat Oct 17 16:46:04 2015
From: report at bugs.python.org (Michael Crouch)
Date: Sat, 17 Oct 2015 14:46:04 +0000
Subject: [docs] [issue25432] isinstance documentation doesn't explain what
 happens when type is tuple
Message-ID: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>


New submission from Michael Crouch:

In the section on isinstance() in the Python Standard Library documentation Chapter 2 (https://docs.python.org/3.6/library/functions.html#isinstance) , it says that classinfo "may be a tuple of type objects", but it doesn't explain what the semantics are in that case (e.g., that it will return true iff it is an instance of any of the types in the tuple).

----------
assignee: docs at python
components: Documentation
messages: 253130
nosy: Michael Crouch, docs at python
priority: normal
severity: normal
status: open
title: isinstance documentation doesn't explain what happens when type is tuple
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Sat Oct 17 19:06:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Oct 2015 17:06:21 +0000
Subject: [docs] [issue25432] isinstance documentation doesn't explain what
 happens when type is tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445101581.52.0.712167579249.issue25432@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't see any ambiguity here.  There are other Python APIs with the same behavior, and all we say is that it can be a tuple (eg: str.startswith).  That is, I don't see any other way a tuple could be interpreted that would make any sense.

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

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

From report at bugs.python.org  Sat Oct 17 19:25:21 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 17 Oct 2015 17:25:21 +0000
Subject: [docs] [issue25432] isinstance documentation doesn't explain what
 happens when type is tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445102721.74.0.669873112683.issue25432@psf.upfronthosting.co.za>


eryksun added the comment:

Since Python has multiple inheritance, it could be misconstrued as a conjunctive test. For example, if c is an instance of C, which subclasses both A and B, then someone might think isinstance(c, (A, B)) requires c to be an instance of both A and B. The description could clarify that it's a disjunctive test with short circuiting.

    class MetaA(type):
        def __instancecheck__(self, other):
            print('MetaA.__instancecheck__')
            return False

    class A(metaclass=MetaA): pass

    >>> isinstance(1, (A, int))
    MetaA.__instancecheck__
    True
    >>> isinstance(1, (int, A))
    True

----------
keywords: +easy
nosy: +eryksun

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

From report at bugs.python.org  Sun Oct 18 14:15:36 2015
From: report at bugs.python.org (Dimitri Papadopoulos Orfanos)
Date: Sun, 18 Oct 2015 12:15:36 +0000
Subject: [docs] [issue25433] whitespace in strip()/lstrip()/rstrip()
Message-ID: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>


New submission from Dimitri Papadopoulos Orfanos:

The documentation of strip() / lstrip() / rstrip() should define "whitespace" more precisely.

The Python 3 documentation refers to "ASCII whitespace" for bytes.strip() / bytes.lstrip() / bytes.rstrip() and "whitespace" for str.strip() / str.lstrip() / str.rstrip(). I suggest the following improvements:
* add a link from "ASCII whitespace" to string.whitespace or bytes.isspace(),
* define plain "whitespace" more precisely (possibly with a link to str.isspace()).

The Python 2 documentation refers to plain "whitespace". As far as I know strip() removes ASCII whitespaces only. If so, please:
* add a link to string.whitespace or str.isspace(),
* improve the string.whitespace documentation and explain that it is locale-dependent (see documentation of str.isspace()).

----------
assignee: docs at python
components: Documentation
messages: 253152
nosy: Dimitri Papadopoulos Orfanos, docs at python
priority: normal
severity: normal
status: open
title: whitespace in strip()/lstrip()/rstrip()
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun Oct 18 14:27:58 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Oct 2015 12:27:58 +0000
Subject: [docs] [issue25432] isinstance documentation doesn't explain what
 happens when type is tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445171277.98.0.0832500969103.issue25432@psf.upfronthosting.co.za>


Georg Brandl added the comment:

But without using the word "disjunctive".

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

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

From report at bugs.python.org  Sun Oct 18 19:11:13 2015
From: report at bugs.python.org (Louis Sautier)
Date: Sun, 18 Oct 2015 17:11:13 +0000
Subject: [docs] [issue25434] Fix typo in whatsnew/3.5
Message-ID: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>


New submission from Louis Sautier:

Hi,
I noticed a typo in the doc for What?s New In Python 3.5, here's a patch.

----------
assignee: docs at python
components: Documentation
files: fixtypo.patch
keywords: patch
messages: 253155
nosy: docs at python, omelette
priority: normal
severity: normal
status: open
title: Fix typo in whatsnew/3.5
versions: Python 3.5
Added file: http://bugs.python.org/file40811/fixtypo.patch

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

From report at bugs.python.org  Sun Oct 18 19:22:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Oct 2015 17:22:44 +0000
Subject: [docs] [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <20151018172239.18366.43207@psf.io>


Roundup Robot added the comment:

New changeset 04ce28b11467 by Berker Peksag in branch '3.5':
Issue #25434: Fix typo in whatsnew/3.5rst
https://hg.python.org/cpython/rev/04ce28b11467

New changeset 93a1b79d0b19 by Berker Peksag in branch 'default':
Issue #25434: Fix typo in whatsnew/3.5rst
https://hg.python.org/cpython/rev/93a1b79d0b19

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

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

From report at bugs.python.org  Sun Oct 18 19:23:53 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Oct 2015 17:23:53 +0000
Subject: [docs] [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <1445189033.52.0.422843054267.issue25434@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Louis.

----------
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/issue25434>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:27:05 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 18 Oct 2015 17:27:05 +0000
Subject: [docs] [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <1445189225.43.0.607502436095.issue25434@psf.upfronthosting.co.za>


SilentGhost added the comment:

Shouldn't the line above read "now accepts" rather than "how accepts"?

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

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

From report at bugs.python.org  Sun Oct 18 20:49:49 2015
From: report at bugs.python.org (David Becher)
Date: Sun, 18 Oct 2015 18:49:49 +0000
Subject: [docs] [issue25435] Wrong function calls and referring to not
 removed concepts in descriptor HowTo (documentation)
Message-ID: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>


New submission from David Becher:

Since Python 3 removed unbound methods, I found some references using the old terminology in this HowTo about descriptors (https://docs.python.org/3/howto/descriptor.html). Also, since unbound methods have been removed, the function call types.MethodType now only takes two arguments, namely the function to bind and the object to bind to. In the current documentation, however, the old function call with three arguments is still being used.

I made a pull request on github, then I realized that it is just a mirror repo. Attached you will see a patch file with some of the obvious changes that could me made to the document

----------
assignee: docs at python
components: Documentation
files: 21.diff.txt
messages: 253159
nosy: David Becher, docs at python
priority: normal
severity: normal
status: open
title: Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
versions: Python 3.6
Added file: http://bugs.python.org/file40812/21.diff.txt

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

From report at bugs.python.org  Sun Oct 18 20:54:57 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 18 Oct 2015 18:54:57 +0000
Subject: [docs] [issue25435] Wrong function calls and referring to not
 removed concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445194497.75.0.63502892191.issue25435@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Oct 18 23:58:28 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Oct 2015 21:58:28 +0000
Subject: [docs] [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <1445205508.93.0.635291572257.issue25434@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, fixed in 530846c3ebb4 and f020a27b5391. Thanks SilentGhost.

----------

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

From report at bugs.python.org  Mon Oct 19 02:40:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 00:40:46 +0000
Subject: [docs] [issue25435] Wrong function calls and referring to not
 removed concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445215246.73.0.49963561092.issue25435@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch. I left a few comments on the code review. I think the class is meant to represent a real function object, not a wrapper. And it would be good to update the following paragraphs about unbound methods.

Also, it looks like the rest of that page could do with some other updates. E.g. no need for explicit Function(object) base class, no need to mention that a method exists in Python 2.3, code could use @classmethod decorator syntax. But these are a slightly separate issues.

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

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

From report at bugs.python.org  Mon Oct 19 03:21:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 01:21:59 +0000
Subject: [docs] [issue13195] subprocess: args with shell=True is not
 documented on Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1445217719.57.0.113241956515.issue13195@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the documentation changes made for Issue 16115 should address your first question (shell=False). For shell=True, see the discussion at Issue 20344. Perhaps you can review my patch.

----------
dependencies: +test the executable arg to Popen() and improve related docs
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> subprocess.check_output() docs misrepresent what shell=True does

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

From vadmium+py at gmail.com  Mon Oct 19 02:39:20 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 19 Oct 2015 00:39:20 -0000
Subject: [docs] Wrong function calls and referring to not removed concepts
 in descriptor HowTo (documentation) (issue 25435)
Message-ID: <20151019003920.14607.64509@psf.upfronthosting.co.za>


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

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode283
Doc/howto/descriptor.rst:283: self.f = f
I reckon leave this bit out. It is meant to represent the actual
function class, not a wrapper.

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode287
Doc/howto/descriptor.rst:287: if obj is Null:
None not Null

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode289
Doc/howto/descriptor.rst:289: return self.f
return self

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode292
Doc/howto/descriptor.rst:292: return types.MethodType(self.f, obj)
MethodType(self, obj)

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode303
Doc/howto/descriptor.rst:303: >>> D.f             # Get from a class
becomes a function as well
Get from a class returns the same function

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode308
Doc/howto/descriptor.rst:308: The output suggests that bound and unbound
methods are two different types.
This whole paragraph could be removed IMO. In Python 3, ?self? is not
allowed to be None, and unbound methods are the original function
object.

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode315
Doc/howto/descriptor.rst:315: field. If set (meaning bound), the
original function (stored in the
The only Python 3 relevant bit is the second sentence I think. The rest
could be dropped.

http://bugs.python.org/review/25435/diff/15789/Doc/howto/descriptor.rst#newcode318
Doc/howto/descriptor.rst:318: function. The actual C implementation of
:func:`instancemethod_call()` is only
instancemethod_call seems to be a method of PyInstanceMethod_Type, which
is part of the C API, but doesn?t seem to be used at all. Don?t think it
is worth mentioning.

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

From john.wu at bcdtravel.cn  Mon Oct 19 03:16:02 2015
From: john.wu at bcdtravel.cn (john wu)
Date: Mon, 19 Oct 2015 01:16:02 +0000
Subject: [docs] =?utf-8?b?562U5aSNOiAgQSBzbWFsbCBtaXN0YWtlIGluIHR1dG9yaWFs?=
 =?utf-8?q?_of_docs=2Epython_3=2E4?=
In-Reply-To: <CAKJDb-MbLb-9n5MnZ=fOeJ=SofJytTqHZc4ro_CGPQ6vdjpNwA@mail.gmail.com>
References: <e8e8fd30e61d469592936a647703b959@CASMBX01.bcdtravel.cn>
 <CAKJDb-MbLb-9n5MnZ=fOeJ=SofJytTqHZc4ro_CGPQ6vdjpNwA@mail.gmail.com>
Message-ID: <9253bd945d034d9c82ebd4a650ec319b@CASMBX01.bcdtravel.cn>

Hi Zach,

I'm so sorry for the email with double question.
When I resend the email to you, I found the mistake you told me. But I can't withdraw the last email. Hope it will not disturb you a lot.

Thanks for your help again!


Thank you.
Best regards,
?
John? Wu
T +86 6132 8586

-----????-----
???: zachary.ware at gmail.com [mailto:zachary.ware at gmail.com] ?? Zachary Ware
????: 2015?10?16? 23:29
???: docs at python.org
??: john wu
??: Re: [docs] A small mistake in tutorial of docs.python 3.4

Hi John,

On Thu, Oct 8, 2015 at 6:51 PM, john wu <john.wu at bcdtravel.cn> wrote:
> The space between ?C>? and ?print(?Yuck!?) makes an error, ?unexpected 
> indent?.

Look carefully: the unexpected indent actually came from a mis-copy when you assigned to sys.ps1.  The example shows "sys.ps1 = 'C> '"
(note the space after the >), while in your trial you did "sys.ps1 = 'C>'" (no space), then added the space when typing in the next line of the example.  If you add the space in the assignment to sys.ps1, as in the example, there is no error.

Hope this helps,
--
Zach


From report at bugs.python.org  Mon Oct 19 05:26:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 03:26:19 +0000
Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still
 refers to "unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1445225178.93.0.83318896289.issue23702@psf.upfronthosting.co.za>


Martin Panter added the comment:

Current patch for Issue 25435 addresses the code example. Changes to the text are also needed though.

----------
dependencies: +Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
nosy: +martin.panter

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

From report at bugs.python.org  Mon Oct 19 05:29:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 03:29:04 +0000
Subject: [docs] [issue25435] Wrong function calls and referring to not
 removed concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445225344.05.0.331480606267.issue25435@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also further up the page, ?unbound methods . . . are . . . based on the descriptor protocol? is probably not really correct or useful. Issue 23702 is already open about mentioning unbound methods.

----------

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

From report at bugs.python.org  Mon Oct 19 06:09:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 04:09:06 +0000
Subject: [docs] [issue16785] Document the fact that constructing OSError
 with erron returns subclass if possible
In-Reply-To: <1356521712.57.0.0819210166931.issue16785@psf.upfronthosting.co.za>
Message-ID: <1445227746.62.0.6649329681.issue16785@psf.upfronthosting.co.za>


Martin Panter added the comment:

My proposed patch at Issue 23391 addresses this

----------
dependencies: +Documentation of EnvironmentError (OSError) arguments disappeared
nosy: +martin.panter

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

From report at bugs.python.org  Mon Oct 19 07:40:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:40:18 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233218.35.0.881893943202.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps you missed my comments to previous patch on Rietveld. Besides this the patch LGTM.

May be we should change weird behavior for 6+ arguments. But this is different issue.

----------

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

From report at bugs.python.org  Mon Oct 19 07:42:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:42:04 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233324.37.0.179537346401.issue23391@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg253170

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

From report at bugs.python.org  Mon Oct 19 07:43:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:43:09 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233389.08.0.958426725049.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM. We should handle the problem with extra arguments in separate issue.

----------

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

From report at bugs.python.org  Mon Oct 19 07:43:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:43:41 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233421.53.0.202286261497.issue23391@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Oct 19 08:42:04 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 19 Oct 2015 06:42:04 +0000
Subject: [docs] [issue25438] document what codec PyMemberDef T_STRING
 decodes the char * as
Message-ID: <1445236924.11.0.92849861938.issue25438@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

https://docs.python.org/3/c-api/structures.html#c.PyMemberDef

T_STRING members are turned into str objects in Python.  The documentation needs updating to mention which codec the char * bytes are treated as.

Solving this issue involves code inspection and leaving pointers to that code here in the issue, then updating the docs to mention the requirements for the char * member data as well as what happens upon assignment for non-READONLY T_STRING data (a different restriction?  or encoding to the same codec?)

My _guess_ would be UTF-8 or ASCII but I'll let someone else dive in and find out.  This is a Python 3 specific documentation clarification.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 253172
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: document what codec PyMemberDef T_STRING decodes the char * as
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Oct 19 21:52:28 2015
From: report at bugs.python.org (Yanyan Jiang)
Date: Mon, 19 Oct 2015 19:52:28 +0000
Subject: [docs] [issue25442] Shelve consistency issues
Message-ID: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>


New submission from Yanyan Jiang:

I am currently working on the file system reliability issues. I have a disk driver that is able to simulate crash disk sites after injected power failures. This disk is totally compatible with the Linux block driver semantics (refer to  https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt), and may create many crash sites that pending blocks are partially flushed into the disk which is a common behavior of a commodity disk with write buffer.

Our automated tool confirms the corruptions could happen on a crash site at an unclean shutdown (Linux with default ext4 setting). We also found that there are some discussions on [Stackoverflow](http://stackoverflow.com/questions/4226580/prevent-python-shelve-corruption) concerning this issue. I am suggesting to explicitly remind the developers of such behaviors.

Suggested documentation enhancement
--------------------------------------
As a minimal database library, `shelve` does not offer as strong ACID (atomicity, consistency, isolation and durability) guarantee as a database (like SQLite). On certain system configurations, a system crash would lead to a corrupted shelve file. If you are using shelve to persistent precious data like user's document, we suggest using the following steps to ensure data is not lost:

1. Create a copy of the file, say, the temporary.
2. Operate on a copy of the temporary file. Closing a shelve db implies data to be flushed to the disk.
3. Rename the temporary file to replace the original file. Renaming is carefully treated by a journaled filesystem to be atomic.

----------
assignee: docs at python
components: Documentation
messages: 253188
nosy: Yanyan Jiang, docs at python
priority: normal
severity: normal
status: open
title: Shelve consistency issues
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/issue25442>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:21:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Oct 2015 21:21:30 +0000
Subject: [docs] [issue25442] Shelve consistency issues
In-Reply-To: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>
Message-ID: <1445289690.56.0.105073880535.issue25442@psf.upfronthosting.co.za>


R. David Murray added the comment:

Shelve does not itself implement any database, but it does *use* a database[*].  Any aspects of this must be directed toward the underlying database library used.  In particular, it is not part of the shelve API to know anything about any possible underlying file or files, nor is it *necessarily* the case that there is pending data to be flushed on close.

So, if you want to suggest a documentation enhancement, it should to make reference to the issue and point the user at the documentation for the underlying database they choose to use for more information.

[*] There is an open issue proposing an sqlite backend for shelve, but no one so far has had the motivation to finish it.

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

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

From report at bugs.python.org  Tue Oct 20 02:58:07 2015
From: report at bugs.python.org (Yanyan Jiang)
Date: Tue, 20 Oct 2015 00:58:07 +0000
Subject: [docs] [issue25442] Shelve consistency issues
In-Reply-To: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>
Message-ID: <1445302687.68.0.160711308631.issue25442@psf.upfronthosting.co.za>


Yanyan Jiang added the comment:

Thanks for reminding. It is originally reported with the default setting. We conducted further tests with other options of anydbm (dbhash, dbm, gdbm), none of them survived crash testing. For the detailed reasoning please refer to an OSDI'14 research paper: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf
 This paper discussed vulnerabilities of GDBM implementation in that paper, and these lightweight db implementations have similar problems. We also have tests SQLite, and it is much more robust that we have not found ACID violation yet.

Personally I think it is reasonable to have an SQLite backend, as it is much safer (plus providing thread safety). Just to see what I can do for that.

----------

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

From report at bugs.python.org  Tue Oct 20 04:54:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Oct 2015 02:54:39 +0000
Subject: [docs] [issue25435] Wrong function calls and referring to not
 removed concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445309679.58.0.67573944844.issue25435@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/issue25435>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:55:22 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Oct 2015 02:55:22 +0000
Subject: [docs] [issue25435] Wrong function calls and referring to not
 removed concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445309722.27.0.11629147255.issue25435@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll update this document to reflect the current state of the world.

----------

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

From report at bugs.python.org  Tue Oct 20 13:56:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 11:56:04 +0000
Subject: [docs] [issue25442] Shelve consistency issues
In-Reply-To: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>
Message-ID: <1445342164.2.0.547882006044.issue25442@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, if we had an sqlite backend I think we'd make it the default if sqlite was available.  There's a proof of concept implementation in the open issue 3783.  I'm not sure what remains to be done (other than docs)...I didn't read through the issue and there's a fair bit of discussion.

----------

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

From 94singhakanksha at gmail.com  Tue Oct 20 15:26:45 2015
From: 94singhakanksha at gmail.com (Akanksha Singh)
Date: Tue, 20 Oct 2015 18:56:45 +0530
Subject: [docs] (no subject)
In-Reply-To: <CAKJDb-O1Em4KzNscP3pOqDGhA2-Va9+cBMkM-GjzU+3T=vMmXg@mail.gmail.com>
References: <CANzy2MnfdcEzwgWjZYCHmWiKqDYWg7bVx3TwN-2_USrjWtAaYw@mail.gmail.com>
 <CAKJDb-O1Em4KzNscP3pOqDGhA2-Va9+cBMkM-GjzU+3T=vMmXg@mail.gmail.com>
Message-ID: <CANzy2Mk859vDJ4PwHA=B--yQ9N6VkKK-YG=GncYw4occj8ZYsA@mail.gmail.com>

Thanks for clearing the doubt.

On Oct 16, 2015 8:56 PM, "Zachary Ware" <zachary.ware+pydocs at gmail.com>
wrote:
>
> Hi,
>
> On Wed, Oct 14, 2015 at 1:14 PM, Akanksha Singh
> <94singhakanksha at gmail.com> wrote:
> > -2**4 gives answer -16 which should be positive ie ans=16.
>
> This is not the correct place to report behavioral bugs; this list is
> for discussion of the Python documentation (including bug reports
> about the docs).  Better would be either a post to python-list
> (python-list at python.org) or a bug report on bugs.python.org.
>
> However, in this case, there is no bug.  You're running into a common
> misconception with operator precedence.  `-2**4` is evaluated as
> `-(2**4)`, that is, "the negation of 2 to the power of 4."  To get
> "the 4th power of negative 2", you'd need to do `(-2)**4`.  See
> https://docs.python.org/3/reference/expressions.html#operator-precedence
> for more information.
>
> Hope this helps,
> --
> Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151020/5b494f37/attachment.html>

From report at bugs.python.org  Wed Oct 21 05:17:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 21 Oct 2015 03:17:45 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445397465.25.0.0613366410162.issue25017@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch.

I think we can move the Python 3 part of the patch to a new note directive (similar to the example in httplib documentation: https://docs.python.org/2/library/httplib.html)

For example:

.. deprecated:: 2.6
   Use :mode:`HTMLParser` instead.

.. note::
   The :mod:`htmllib` module has been removed in Python 3.  Use :mod:`html.parser` (equivalent of :mode:`HTMLParser`) instead.

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

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

From report at bugs.python.org  Wed Oct 21 05:22:07 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 21 Oct 2015 03:22:07 +0000
Subject: [docs] [issue25438] document what codec PyMemberDef T_STRING
 decodes the char * as
In-Reply-To: <1445236924.11.0.92849861938.issue25438@psf.upfronthosting.co.za>
Message-ID: <1445397727.49.0.837717038173.issue25438@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Checking the source ( https://hg.python.org/cpython/file/tip/Python/structmember.c#l51 ), it calls PyUnicodeFromString ( https://docs.python.org/3/c-api/unicode.html?highlight=pyunicode_fromstring#c.PyUnicode_FromString ), so it's always interpreted as UTF-8.

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

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

From report at bugs.python.org  Wed Oct 21 10:02:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 21 Oct 2015 08:02:37 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445414557.63.0.240517922396.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also beware it should be :mod: not :mode: :)

----------

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

From report at bugs.python.org  Wed Oct 21 14:56:55 2015
From: report at bugs.python.org (Nan Wu)
Date: Wed, 21 Oct 2015 12:56:55 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445432215.32.0.678106372467.issue25017@psf.upfronthosting.co.za>


Nan Wu added the comment:

Updated the patch. The typo was fixed too. Thanks for the catching.

----------
Added file: http://bugs.python.org/file40831/htmllib_deprecation_warning_2.patch

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

From report at bugs.python.org  Thu Oct 22 16:18:15 2015
From: report at bugs.python.org (Vikas)
Date: Thu, 22 Oct 2015 14:18:15 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1445523494.87.0.915127442366.issue17468@psf.upfronthosting.co.za>


Vikas added the comment:

I see this comment :
>> When iteration over a queryset raised an exception, the result cache remained initialized with an empty list, so subsequent iterations returned an empty list instead of raising an exception>>

What if we catch the exceptions? Will that cause not to leak memory?

----------
nosy: +Vikas

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

From report at bugs.python.org  Thu Oct 22 19:05:38 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 22 Oct 2015 17:05:38 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
Message-ID: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna:

At least for me (non-english speaker), the following is confusing:

"Modifying dirnames when topdown is False is ineffective, because in bottom-up mode the directories in dirnames are generated before dirpath itself is generated."

I suggest to replace "is ineffective" with "has no effect".

Ineffective could also mean: "Has low performance", could it not?

----------
assignee: docs at python
components: Documentation
messages: 253338
nosy: Bernt.R?skar.Brenna, docs at python
priority: normal
severity: normal
status: open
title: Unclear language (the word ineffective) in the documentation for os.walk
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Thu Oct 22 19:10:02 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Oct 2015 17:10:02 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445533802.01.0.795112537095.issue25461@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the report.
This sounds like a reasonable request to me.
Would you like to make a patch?
(If so, you can check the devguide.)

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Thu Oct 22 19:15:39 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 22 Oct 2015 17:15:39 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445534139.75.0.0950249807918.issue25461@psf.upfronthosting.co.za>


Bernt R?skar Brenna added the comment:

OK, I'll submit a patch

----------

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

From report at bugs.python.org  Fri Oct 23 06:15:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 10:15:21 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445595321.68.0.53636159242.issue25461@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Oct 23 06:51:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 10:51:12 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445597472.92.0.320948061076.issue25461@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> If you want to avoid ineffective because its meaning is subtle (a reasonable request), the correct replacement would be "modifying dirnames has no effect on the behavior of the walk", which is wordier but clearer.

I prefer the new sentence, it's more explicit. Maybe I pushed the change too fast.

@David: are you ok with the change?

----------

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

From report at bugs.python.org  Fri Oct 23 09:10:58 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Oct 2015 13:10:58 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445605857.97.0.46756907162.issue25461@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Usually docstrings are short and to the point, and serve more as a remainder, whereas the online docs explain everything in detail.
Also rst markup in docstrings would be distractings, so we keep docstrings and online docs separated, even though there is often some overlapping.

----------

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

From report at bugs.python.org  Fri Oct 23 13:23:25 2015
From: report at bugs.python.org (Tony R.)
Date: Fri, 23 Oct 2015 17:23:25 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
Message-ID: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>


New submission from Tony R.:

Python has wonderful, detailed documentation.  I love it!

Unfortunately, I have often found myself reading the otherwise-excellent documentation on a class/function/whatever, only to find out at the END of my reading that it is deprecated.

This is frustrating, and counter-intuitive.  If something is deprecated, I want to know it before I read any further.  

I have attached a patch with the relevant changes.  I hope it helps!

----------
assignee: docs at python
components: Documentation
files: 0001-Move-deprecated-blocks-to-the-beginning-of-their-doc.patch
keywords: patch
messages: 253391
nosy: Tony R., docs at python
priority: normal
severity: normal
status: open
title: Put ?deprecated? warnings first
type: enhancement
Added file: http://bugs.python.org/file40851/0001-Move-deprecated-blocks-to-the-beginning-of-their-doc.patch

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

From report at bugs.python.org  Fri Oct 23 06:39:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Oct 2015 10:39:32 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <20151023103929.416.97988@psf.io>


Roundup Robot added the comment:

New changeset 0286bb18a351 by Victor Stinner in branch '3.4':
Issue #25461: Rephrase os.walk() doc
https://hg.python.org/cpython/rev/0286bb18a351

New changeset 9f68e41fb4a7 by Victor Stinner in branch '3.5':
Merge 3.4 (Issue #25461)
https://hg.python.org/cpython/rev/9f68e41fb4a7

New changeset db07937b3e49 by Victor Stinner in branch 'default':
Merge 3.4 (Issue #25461)
https://hg.python.org/cpython/rev/db07937b3e49

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

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

From report at bugs.python.org  Fri Oct 23 06:42:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Oct 2015 10:42:55 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <20151023104252.27532.13647@psf.io>


Roundup Robot added the comment:

New changeset 8247dff49113 by Victor Stinner in branch '2.7':
Issue #25461: Rephrase os.walk() doc
https://hg.python.org/cpython/rev/8247dff49113

----------

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

From report at bugs.python.org  Fri Oct 23 09:04:34 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 23 Oct 2015 13:04:34 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445605473.94.0.865181371832.issue25461@psf.upfronthosting.co.za>


Bernt R?skar Brenna added the comment:

A question/comment:

In this case (and there are probably other cases like it) - it seems to me that the docstring (in os.py) and the docs (in os.rst) are similar enough that the docstring from the code could be included in the docs (using Sphinx's autodoc).

What is the preferred way? Is there a reason to have it the way it is? I notice the .rst docs have some formatting applied, is it considered not OK to put formatting in docstrings?

----------

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

From report at bugs.python.org  Fri Oct 23 08:30:33 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 23 Oct 2015 12:30:33 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445603433.26.0.359176310193.issue25461@psf.upfronthosting.co.za>


Bernt R?skar Brenna added the comment:

Yet another patch, this time including changes to os.walk()'s docstring as well.

Ignore the two other files.

----------
Added file: http://bugs.python.org/file40849/os_walk_doc.patch

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

From report at bugs.python.org  Fri Oct 23 09:07:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 13:07:45 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445605473.94.0.865181371832.issue25461@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaBMxOVBfYifnbXEn-qhx2GE9zFRqRf780Rz6iATX+gHA@mail.gmail.com>


STINNER Victor added the comment:

We don't use autodoc. It would be "nice" to have a tool to update .rst
files from .py and .c files, but it's not the case right now :-/

----------

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

From report at bugs.python.org  Fri Oct 23 09:15:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 13:15:30 +0000
Subject: [docs] [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445606130.63.0.681872236662.issue25461@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Also rst markup in docstrings would be distractings, so we keep docstrings and online docs separated, even though there is often some overlapping."

Ah yes, and the doc in Doc/ directory contains more information like ".. versionchanged:: (...)", ".. versionadded:: (...)", links to other doc using reST markups, etc.

In general, the doc in Doc/ is higher quality than docstrings ;)

----------

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

From report at bugs.python.org  Fri Oct 23 09:18:17 2015
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 23 Oct 2015 13:18:17 +0000
Subject: [docs] [issue21593] Clarify re.search documentation first match
In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za>
Message-ID: <1445606297.05.0.0649418069717.issue21593@psf.upfronthosting.co.za>


Changes by Joshua Landau <joshua.landau.ws at gmail.com>:


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

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

From report at bugs.python.org  Sun Oct 25 20:52:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 00:52:32 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445820751.91.0.358306247853.issue25432@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps add after third sentence (ending with "not accepted)."), "If classinfo is a tuple, isinstance(x, classinfo) is the same as any(isinstance(x, C) for C in flatten(classinfo))".

----------
nosy: +terry.reedy
stage:  -> needs patch
title: isinstance documentation doesn't explain what happens when type is tuple -> isinstance documentation: explain behavior when type is a tuple
type:  -> enhancement
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Oct 26 07:31:07 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 11:31:07 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445859067.16.0.232994760849.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the report and the patch.

I think a better way to handle this would be to add a "tag" next to the function name for both deprecations and "new in", and leave the actual deprecation/new-in notes at the bottom, something like:

funcname(args)  [new in 3.2] [deprecated in 3.5]
  Func description here.

  New in 3.2: the funcname() function was added.
  Deprecated in 3.5: funcname() has been deprecated.  Use anotherfunc() instead.

I've seen other docs doing it, however I'm not sure how easy it would be to implement something similar for Sphinx (maybe it's necessary to redefine the func/meth/class roles).

----------
nosy: +eric.araujo, ezio.melotti, georg.brandl

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

From report at bugs.python.org  Mon Oct 26 08:40:28 2015
From: report at bugs.python.org (Tony R.)
Date: Mon, 26 Oct 2015 12:40:28 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445859067.16.0.232994760849.issue25467@psf.upfronthosting.co.za>
Message-ID: <563E2139-7033-4C9C-A4F3-F98B86EE4825@gmail.com>


Tony R. added the comment:

> Thanks for the report and the patch.

Thank you for the review!

> I think a better way to handle this would be to add a "tag" next to the function name for both deprecations and "new in", and leave the actual deprecation/new-in notes at the bottom, something like:
> 
> funcname(args)  [new in 3.2] [deprecated in 3.5]
>  Func description here.
> 
>  New in 3.2: the funcname() function was added.
>  Deprecated in 3.5: funcname() has been deprecated.  Use anotherfunc() instead.

I?m not sure I understand what you mean by ?tag?.

(ASIDE: I?m only marginally familiar with Sphinx, so I don?t know if ?tag? has a specific meaning here.  I dabble across lots of markup-to-full-docs generation tools; Sphinx is just one that I happen to know the least.)

Are you saying that the source documentation would remain as-is, but something during the Sphinx _transformation_ would generate the new/deprecated tags?  

As long as those tags are clearly visible at-or-near the start, then I?m all for it.  If that is what you propose, then I can think of several possible ways to structure the generated HTML & CSS?and from there I would just need to dive into the Sphinx transformations and figure out where to sprinkle the ?tags?.

----------

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

From report at bugs.python.org  Mon Oct 26 09:11:00 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 13:11:00 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445865060.5.0.385670324933.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I?m not sure I understand what you mean by ?tag?.

>> funcname(args)  [new in 3.2] [deprecated in 3.5]
>>   Func description here.

I mean some kind of tag/label next to the name of the function in the documentation (red/orange for deprecations, green for new-in)  -- it's not a Sphinx-specific term.
I saw it in some other documentation but I can't find it anymore, however if you look at the [task] and [assigned] tags/labels at the top of https://twistedmatrix.com/trac/ticket/5000 you can get a pretty close idea of what I'm thinking about.

> Are you saying that the source documentation would remain as-is,
> but something during the Sphinx _transformation_ would generate
> the new/deprecated tags?  

That's the idea.  Ideally the func/meth/class directives [0] would add the tags/labels if they contain version-added/version-changed/deprecated/deprecated-remove directives.

[0]: directives look like ".. function:: foo(args)", whereas roles look like :func:`foo`.  Functions are defined using directives.  In the previous message I mistakenly said "roles".  See also https://docs.python.org/devguide/documenting.html#directives

----------

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

From report at bugs.python.org  Mon Oct 26 12:14:02 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Oct 2015 16:14:02 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445876042.88.0.667421141151.issue25467@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Oct 26 13:33:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 17:33:45 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445880825.33.0.945225763091.issue25467@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think Ezio's idea is great.  I would not want to see the notices at the top, but a label would make things clear (and the label could be hyperlinked to the note, since sometimes they are a bit of a distance away).

Someone has to figure out the Sphinx programming, though.

Note that the 'new' label should only appear for stuff that is new in that release.  It's not clear to me if it should appear at all in the docs for maintenance releases...that should be discussed.

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

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

From report at bugs.python.org  Mon Oct 26 13:49:46 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 17:49:46 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445881786.52.0.901717620528.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Note that the 'new' label should only appear for stuff that is new
> in that release.

This is not a problem if it says [new in x.y] explicitly.  This way for each version-added/version-changed/deprecated/deprecated-remove directive we will also have a label.

As for the implementation, I'm pretty sure it can be done by changing/redefining all the function/method/class directives.  The directives should then be able to inspect the nodes they contain and see if there are any of the aforementioned directives and turn them into labels.  Not sure if there's a clever way to do it though (maybe a CSS class can be added to the directives and the labels can be added with CSS :after).

----------

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

From report at bugs.python.org  Mon Oct 26 13:52:51 2015
From: report at bugs.python.org (Tony R.)
Date: Mon, 26 Oct 2015 17:52:51 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445881786.52.0.901717620528.issue25467@psf.upfronthosting.co.za>
Message-ID: <091205E7-7CD2-4875-A0C7-E283D745F1A6@gmail.com>


Tony R. added the comment:

> On Oct 26, 2015, at 1:49 PM, Ezio Melotti <report at bugs.python.org> wrote:
> 
> Not sure if there's a clever way to do it though (maybe a CSS class can be added to the directives and the labels can be added with CSS :after).

I was thinking something along these lines.  Other possibilities come to mind, also.

----------

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

From report at bugs.python.org  Mon Oct 26 14:22:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 18:22:28 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445883748.06.0.532190146286.issue25467@psf.upfronthosting.co.za>


R. David Murray added the comment:

Insert "in my opinion" into that sentence.  I don't want to be distracted by "new in 3.1" tags when reading the 3.6 documentation.  It isn't new from my POV :)

----------

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

From report at bugs.python.org  Mon Oct 26 16:27:29 2015
From: report at bugs.python.org (feliep)
Date: Mon, 26 Oct 2015 20:27:29 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445891249.38.0.838751261361.issue25432@psf.upfronthosting.co.za>


feliep added the comment:

I think that the following part could replace the part of the other text that's between ###. It's more objective and easier to understand. 

classinfo may could be a tuple of type objects, or may contains others tuples that contains type objects (other sequence types are not accepted).

Return true if the object argument is an instance of the classinfo argument, or of a (direct, indirect or virtual) subclass thereof. If object is not an object of the given type, the function always returns false. ### If classinfo is not a class (type object), it may be a tuple of type objects, or may recursively contain other such tuples (other sequence types are not accepted). ### If classinfo is not a type or tuple of types and such tuples, a TypeError exception is raised.

What do you think?

----------
nosy: +felipevolpone

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

From report at bugs.python.org  Mon Oct 26 16:28:49 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 20:28:49 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445891329.89.0.77643081695.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I don't want to be distracted by "new in 3.1" tags when reading
> the 3.6 documentation.

This is true, but on the other hand you might want to see the [new in 3.4] while looking at 3.6 docs and working on a program that must support Python 3.3+.  Anyway we can discuss this again once we have a patch -- depending on how it is implemented, it might be easy enough to include the tag only for functions added in the last 2 releases, or perhaps the tag won't be particularly distracting and can be used for all versions.

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

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

From report at bugs.python.org  Mon Oct 26 16:37:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 20:37:45 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445891865.72.0.126540958772.issue25432@psf.upfronthosting.co.za>


R. David Murray added the comment:

The fact that nested tuples are accepted is just bizarre, IMO :(.

It could say something like "If classinfo is a (possibly nested) list of types, return True if any of the types match."

----------

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

From report at bugs.python.org  Mon Oct 26 17:25:11 2015
From: report at bugs.python.org (Felipe Volpone)
Date: Mon, 26 Oct 2015 21:25:11 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445894711.35.0.701642544948.issue25432@psf.upfronthosting.co.za>


Felipe Volpone added the comment:

r.david.murray: I liked your way.

----------

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

From report at bugs.python.org  Mon Oct 26 18:13:14 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 22:13:14 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445897594.41.0.861751864625.issue25432@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

David, if you are suggesting that the initial negative clause of "If classinfo is not a class (type object)" is not needed, I agree.  If classinfo is a tuple, is is not a class.  'list of types' has to be 'tuple of types'. I think 'match' needs to be expanded to 'is an instance of'. How about

"If classinfo is a tuple of type objects (or recursively, other such tuples), return true if object is an instance of any of the types.

This leaves out the left to right ordering of the tests, but I think that is implied by how Python generally works.  Short circuiting certainly is.

----------

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

From report at bugs.python.org  Mon Oct 26 18:55:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 22:55:25 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445900125.37.0.988277354625.issue25432@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure, that's fine with me.  I was trying to minimize words, but clarity is good.

----------

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

From report at bugs.python.org  Mon Oct 26 20:00:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Oct 2015 00:00:58 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <20151027000055.25483.79091@psf.io>


Roundup Robot added the comment:

New changeset cb554248ce54 by Martin Panter in branch '3.4':
Issue #23391: Restore OSError constructor argument documentation
https://hg.python.org/cpython/rev/cb554248ce54

New changeset 7b1a9a12eb77 by Martin Panter in branch '3.5':
Issue #23391: Merge OSError doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/7b1a9a12eb77

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

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

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

From report at bugs.python.org  Mon Oct 26 20:51:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 00:51:15 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445907075.1.0.296279726175.issue23391@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will leave opening a bug for the args issue for someone else. But if you come up with a sensible solution or find out all the details, I am happy to help write up or review the documentation changes.

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

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

From report at bugs.python.org  Mon Oct 26 23:56:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 03:56:56 +0000
Subject: [docs] [issue16785] Document the fact that constructing OSError
 with erron returns subclass if possible
In-Reply-To: <1356521712.57.0.0819210166931.issue16785@psf.upfronthosting.co.za>
Message-ID: <1445918216.2.0.500088260967.issue16785@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hopefully revision cb554248ce54 is good enough to close this. The documentation now says

'''
The constructor often actually returns a subclass of OSError, as described in ?OS exceptions? below. The particular subclass depends on the final ?errno? value. This behaviour only occurs when constructing OSError directly or via an alias, and is not inherited when subclassing.
'''

Serhiy?s first case does not set the ?errno? attribute (by design I assume). In the second case, I suspect the behaviour has changed since 2012, or it depends on the platform. On Windows, the 'spam' argument is meant to become ?winerror?, which can override ?errno? if it is an integer. 3.6 on Linux:

>>> OSError(errno.ENOENT, 'error msg', 'filename', 'spam')
FileNotFoundError(2, 'error msg')

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

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

From report at bugs.python.org  Tue Oct 27 01:27:45 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 27 Oct 2015 05:27:45 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1445923665.02.0.69355565322.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Okay, so I think this needed to be documented in signal.set_wakeup_fd(). 

IMO this reduces usefulness of set_wakeup_fd(). If I need to install custom handler by my self, I can write to fd in my own custom handler.

And,  installing custom handler omits existing handler, but we can not execute existing signal handler from python script. In my real-world case, SIGWINCH signal does not delivered to curses library. 

pep-475(https://www.python.org/dev/peps/pep-0475/#backward-compatibility) claims that 

    "For applications using event loops, signal.set_wakeup_fd() is the recommanded option to handle signals. "

But I think side effect of signal.set_wakeup_fd() is lager than pep-475 authors expected.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: not a bug -> 
status: closed -> open

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

From report at bugs.python.org  Tue Oct 27 05:03:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Oct 2015 09:03:26 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445936606.63.0.595340037641.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is an outdated comment in Objects/exceptions.c that explains args hacking. It refers to no longer supported syntax:

    except OSError, (errno, strerror):

----------

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

From report at bugs.python.org  Tue Oct 27 08:35:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 12:35:01 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445949301.84.0.578565301766.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

This looks good enough to me. I would have probably avoided littering the page with too many Deprecated and Note boxes, but I can respect your and Berker?s preference to add the separate box.

----------

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

From report at bugs.python.org  Tue Oct 27 09:17:21 2015
From: report at bugs.python.org (Tony R.)
Date: Tue, 27 Oct 2015 13:17:21 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445891329.89.0.77643081695.issue25467@psf.upfronthosting.co.za>
Message-ID: <1156CC23-00CB-4CAA-A1E2-E055E639D171@gmail.com>


Tony R. added the comment:

> On Oct 26, 2015, at 4:28 PM, Ezio Melotti <report at bugs.python.org> wrote:
> 
> This is true, but on the other hand you might want to see the [new in 3.4] while looking at 3.6 docs and working on a program that must support Python 3.3+.  Anyway we can discuss this again once we have a patch -- depending on how it is implemented, it might be easy enough to include the tag only for functions added in the last 2 releases, or perhaps the tag won't be particularly distracting and can be used for all versions.

Smart use of CSS and a sprinkle of JavaScript could solve this.  

- Add all versions in the markup
- By default, use CSS to hide all except latest version
- Using JavaScript and a simple `localStorage` variable, save a preference to ?lower the version threshold? if desired

I tend to prefer non-JS solutions when possible, but this would only take a few lines of code.  (And of course, one `localStorage` variable along the lines of `minimumAddedInPythonVersion = ?3.2?`, or whatever.)

?Tony

----------

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

From report at bugs.python.org  Tue Oct 27 09:52:10 2015
From: report at bugs.python.org (Anton Tagunov)
Date: Tue, 27 Oct 2015 13:52:10 +0000
Subject: [docs] [issue25490] small mistake in example for random.choice()
Message-ID: <1445953930.63.0.811107354907.issue25490@psf.upfronthosting.co.za>


New submission from Anton Tagunov:

Invalid example at this page: https://docs.python.org/3.6/library/random.html

'.items()' is missed in the line below:

>>> population = [val for val, cnt in weighted_choices for i in range(cnt)]


The correct variant:

>>> population = [val for val, cnt in weighted_choices.items() for i in range(cnt)]

----------
assignee: docs at python
components: Documentation
messages: 253537
nosy: Anton Tagunov, docs at python
priority: normal
severity: normal
status: open
title: small mistake in example for random.choice()
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 27 10:24:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 14:24:32 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445955872.66.0.955532925887.issue25017@psf.upfronthosting.co.za>


R. David Murray added the comment:

The note should actually be parallel to the http one (assuming 2to3 does do the translation), rather than say "use instead", which would be incorrect advice for a python2 user :)

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

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

From report at bugs.python.org  Tue Oct 27 11:32:17 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Oct 2015 15:32:17 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlMjU0NjddIFB1dCDigJxkZXByZWNhdGVk4oCdIHdh?=
 =?utf-8?q?rnings_first?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445959937.27.0.146244844886.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would rather avoid a JS-based solution.

It should be possible to create a mixin that adds the checks for deprecated/versionadded directives among the children of the node, and then define new directives for functions/methods/classes that inherit from the existing one and the mixin.
These directives can be added to https://hg.python.org/cpython/file/tip/Doc/tools/extensions/pyspecific.py

----------

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

From report at bugs.python.org  Tue Oct 27 11:55:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Oct 2015 15:55:50 +0000
Subject: [docs] [issue25490] small mistake in example for random.choice()
In-Reply-To: <1445953930.63.0.811107354907.issue25490@psf.upfronthosting.co.za>
Message-ID: <1445961350.26.0.470489250183.issue25490@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no mistake. weighted_choices is a list of pairs.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Oct 27 16:41:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 20:41:58 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445978518.71.0.7314340036.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

Not quite. This is a two-step deprecation:

1. ?htmllib? is removed in favour of HTMLParser. The API is different, so no automatic 2to3 change would be practical.

2. HTMLParser is renamed to ?html.parser?, and 2to3 handles this. This is already documented at <https://docs.python.org/2/library/htmlparser.html>.

----------

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

From report at bugs.python.org  Tue Oct 27 17:40:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 21:40:28 +0000
Subject: [docs] [issue25017] htmllib deprecated: Which library to use?
 Missing sane default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445982028.47.0.660136645339.issue25017@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, then the note should be dropped.

----------

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

From report at bugs.python.org  Tue Oct 27 17:48:58 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 27 Oct 2015 21:48:58 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
Message-ID: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

Introduced in the initial version of statistics was """" starting a docstring

https://hg.python.org/cpython/annotate/685e044bed5e/Lib/statistics.py#l380

Somewhere the fourth quote is dropped, as it doesnt appear in the docs:

https://docs.python.org/3/library/statistics.html#statistics.median_grouped

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: cpython-statistics.patch
keywords: patch
messages: 253568
nosy: John.Mark.Vandenberg, docs at python
priority: normal
severity: normal
status: open
title: Four quotes used to begin docstring
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40871/cpython-statistics.patch

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

From report at bugs.python.org  Tue Oct 27 18:02:23 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 27 Oct 2015 22:02:23 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445983343.86.0.082492713413.issue25494@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

The additional quotation mark is shown in help()

>>> help(statistics.median_grouped)
Help on function median_grouped in module statistics:

median_grouped(data, interval=1)
    "Return the 50th percentile (median) of grouped continuous data.

----------

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

From report at bugs.python.org  Tue Oct 27 19:10:17 2015
From: report at bugs.python.org (Mouse)
Date: Tue, 27 Oct 2015 23:10:17 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
Message-ID: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>


New submission from Mouse:

binascii b2a_base64() documentation says:

The length of data should be at most 57 to adhere to the base64 standard.

This is incorrect, because there is no base64 standard that restricts the length of input data, especially to such a small value.

What RFC4648 (that superseded RFC3548 that your documentation still keeps referring to) actually says is that MIME enforces the limit ofthe OUTPUT LINE length at 76, but NOT of the entire output, and certainly not of the entire input.

Please correct the documentation, making it conformant with what the ACTUAL base64 standard says.

See https://en.wikipedia.org/wiki/Base64 and
https://tools.ietf.org/html/rfc4648

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 253572
nosy: docs at python, mouse07410
priority: normal
severity: normal
status: open
title: binascii documentation incorrect
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 27 20:52:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 00:52:04 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1445993524.75.0.0352164006805.issue25495@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree that the documentation is not optimal.  To give you some background, binascii was primarily implemented to support the email module, and the standard it is referring to is in fact the MIME standard that references base64 (I believe at the time the independent base64 standard did not exist).  The number 57 is derived from the fact that 57 * 4/3 = 76; that is, input data of length 57 will result in an encoded line that is equal to the maximum recommended line length.  Thus in encoding an email the email package (originally, it no longer does this) passed the data in in 57 byte chunks and appended the resulting lines to the output buffer.

So, this documentation is historically correct, but no longer particularly useful.  Suggested improvements are welcome.  

This state of affairs exists because the binascii module doesn't really have a current maintainer. Someday I'd love to have enough time to pick it up, since I maintain email and it is still used by email (and could be used better, with some module improvements).

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

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

From report at bugs.python.org  Tue Oct 27 21:21:06 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 28 Oct 2015 01:21:06 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445995265.64.0.593460356816.issue25494@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I don't know why you believe docstrings are programmatically linked to the library reference...

Here is the file that is used to make the online documentation: https://hg.python.org/cpython/file/tip/Doc/library/statistics.rst

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

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

From report at bugs.python.org  Tue Oct 27 21:35:27 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Wed, 28 Oct 2015 01:35:27 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445996127.4.0.042917931607.issue25494@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

Thank you for clarifying that.
Does that mean that this issue should not be assigned to docs at python and should not have a Component of 'Documentation'?

----------

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

From report at bugs.python.org  Tue Oct 27 22:14:58 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 28 Oct 2015 02:14:58 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445998498.23.0.928469184408.issue25494@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

It probably shouldn't be assigned to docs at python, but it's still a typo in the source code, so it should probably be under Library anyway.

LGTM

----------

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

From report at bugs.python.org  Tue Oct 27 23:06:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Oct 2015 03:06:07 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <20151028030603.24889.75342@psf.io>


Roundup Robot added the comment:

New changeset 041701817c5d by Zachary Ware in branch '3.4':
Issue #25494: Remove extra quote from docstring.
https://hg.python.org/cpython/rev/041701817c5d

New changeset 2dd97ad96021 by Zachary Ware in branch '3.5':
Issue #25494: Merge with 3.4
https://hg.python.org/cpython/rev/2dd97ad96021

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

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

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

From report at bugs.python.org  Tue Oct 27 23:07:32 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 28 Oct 2015 03:07:32 +0000
Subject: [docs] [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1446001652.54.0.0274284099509.issue25494@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Documentation is fine for docstrings, it gets the attention of the docs@ list.  Library is also fine, since the change actually goes in Lib/.  Both is most correct :)

Thanks for the report and patch!

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

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

From report at bugs.python.org  Wed Oct 28 02:57:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Oct 2015 06:57:03 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1446015423.47.0.147584529353.issue25432@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Doing this now.

----------
assignee: docs at python -> terry.reedy

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

From report at bugs.python.org  Wed Oct 28 03:16:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Oct 2015 07:16:05 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <20151028071602.21949.27018@psf.io>


Roundup Robot added the comment:

New changeset aaf8a25133ff by Terry Jan Reedy in branch '2.7':
Issue #25432: Explain isinstance behaviour when type is a tuple.
https://hg.python.org/cpython/rev/aaf8a25133ff

New changeset 8b1418e5dcc8 by Terry Jan Reedy in branch '3.4':
Issue #25432: Explain isinstance behaviour when type is a tuple.
https://hg.python.org/cpython/rev/8b1418e5dcc8

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

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

From report at bugs.python.org  Wed Oct 28 03:16:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Oct 2015 07:16:54 +0000
Subject: [docs] [issue25432] isinstance documentation: explain behavior when
 type is a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1446016614.06.0.329156315672.issue25432@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Oct 28 05:41:33 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 28 Oct 2015 09:41:33 +0000
Subject: [docs] [issue25496] Default value for compresslevel is not
 documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1446025293.39.0.857142174313.issue25496@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +berker.peksag, docs at python
stage:  -> needs patch
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Wed Oct 28 06:58:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 28 Oct 2015 10:58:37 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446029917.57.0.693103265654.issue25482@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Oct 28 10:54:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Oct 2015 14:54:44 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446044084.27.0.494145185003.issue25482@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> IMO this reduces usefulness of set_wakeup_fd(). (...)

Sorry, I don't understand your use case. Could you elaborate. What do you need?

--

According to the GNU libc doc, the signal SIGWINCH is *ignored* by default:
"Window size change. This is generated on some systems (including GNU) when the terminal driver?s record of the number of rows and columns on the screen is changed. The default action is to ignore it."
https://www.gnu.org/software/libc/manual/html_node/Miscellaneous-Signals.html

For signal.set_wakeup_fd() I agree that the doc can be enhanced. It's not explicit that only signals with a *Python* signal handler (at least, a signal handler registered by signal.signal) write into the "wakeup FD".

----------

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

From report at bugs.python.org  Wed Oct 28 12:04:54 2015
From: report at bugs.python.org (Michael Crouch)
Date: Wed, 28 Oct 2015 16:04:54 +0000
Subject: [docs] [issue21333] Document recommended exception for objects that
 shouldn't be pickled
In-Reply-To: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za>
Message-ID: <1446048294.19.0.675989186886.issue21333@psf.upfronthosting.co.za>


Michael Crouch added the comment:

When pickling an object fails on line 70 of copy_reg.py, a "TypeError" is raised. However, according to section 11.1.3 of the Standard Library documentation, when an unpicklable object is passed to the dump() method the "PicklingError" exception will be raised.

----------
components: +Library (Lib) -Documentation
nosy: +Michael Crouch
versions: +Python 2.7 -Python 3.5

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

From report at bugs.python.org  Wed Oct 28 12:10:29 2015
From: report at bugs.python.org (Mouse)
Date: Wed, 28 Oct 2015 16:10:29 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446048629.51.0.822430885171.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Yes I know where this came from. :-)

Here is my proposed change.

Replace the statement 

The length of data should be at most 57 to adhere to the base64 standard.

with:

To be MIME-compliant, the Base64 output (as defined in RFC4648) should be broken into lines of at most 76 characters long. This post-processing of the output is the responsibility of the caller. Note that the original PEM context-transfer encoding limited line length to 64 characters.


Would this change be agreeable to you?

----------

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

From report at bugs.python.org  Wed Oct 28 13:10:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 17:10:04 +0000
Subject: [docs] [issue21333] Document recommended exception for objects that
 shouldn't be pickled
In-Reply-To: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za>
Message-ID: <1446052204.45.0.960571450426.issue21333@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PicklingError is raised in following cases:

1. Programmical Pickler error (Pickler.__init__() was not called by subclass' __init__()).

2. Due to protocol or implementation limitations: memoizing more than 2**32 objects, saving non-ASCII globals with protocol < 3, etc. Exception type is implementation depended. Sometimes OverflowError or struct.error can be raised instead.

3. When __reduce__/__reduce_ex__ returns invalid value: neither str or tuple, a tuple has wrong size, first tuple element is not a callable, first argument for __newobj__/__newobj_ex__ has no __new__ or doesn't match a type of pickled object, global lookup is failed or doesn't match pickled object, etc.

4. When extension code is not an integer or out of range.

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

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

From report at bugs.python.org  Wed Oct 28 16:02:17 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 20:02:17 +0000
Subject: [docs] [issue25496] Default value for compresslevel is not
 documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1446062537.44.0.75864273904.issue25496@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Hi Sworddragon,

Where compresslevel is not mentioned in the doc ?

Thank you

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

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

From report at bugs.python.org  Wed Oct 28 16:18:08 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 20:18:08 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446063488.28.0.522148690394.issue25495@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Here is a patch with the submitted description.

----------
keywords: +patch
nosy: +matrixise
Added file: http://bugs.python.org/file40878/issue25495.patch

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

From report at bugs.python.org  Wed Oct 28 16:44:03 2015
From: report at bugs.python.org (Mouse)
Date: Wed, 28 Oct 2015 20:44:03 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446065043.88.0.903708668232.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Thank you for the quick turn-around, and for taking care of this issue!

----------

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

From report at bugs.python.org  Wed Oct 28 17:34:44 2015
From: report at bugs.python.org (Sergei Lebedev)
Date: Wed, 28 Oct 2015 21:34:44 +0000
Subject: [docs] [issue25500] _find_and_load_unlocked doesn't always use
 __import__
Message-ID: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>


New submission from Sergei Lebedev:

According to the current import system documentation

> When calling ``__import__()`` as part of an import statement, the import system first checks the module global namespace for a function by that name. If it is not found, then the standard builtin ``__import__()`` is called.

However, one can easily verify this isn't (always) the case::

    import sys

    assert "glob" not in sys.modules
    __import__ = print
   
    import glob  # Doesn't print anything.

I've traced the import statement from ``ceval.c`` to the frozen ``importlib._bootstrap`` and it seems the cause of the problem is in ``_find_and_load_unlocked``, which simply ignores the ``_import`` argument in the case above::

    def _find_and_load_unlocked(name, import_):
        path = None
        # ... parent processing ...
        spec = _find_spec(name, path)
        if spec is None:
            raise ImportError(_ERR_MSG.format(name), name=name)
        else:
            # XXX import_ is not used.
            module = _SpecMethods(spec)._load_unlocked()
        # ... more parent processing ...
        return module

I'm not sure if this is a bug in the documentation or implementation, so any feedback is appreciated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 253635
nosy: docs at python, superbobry
priority: normal
severity: normal
status: open
title: _find_and_load_unlocked doesn't always use __import__
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 28 17:37:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 21:37:23 +0000
Subject: [docs] [issue25500] _find_and_load_unlocked doesn't always use
 __import__
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1446068243.87.0.215205722833.issue25500@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, eric.snow

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

From report at bugs.python.org  Wed Oct 28 18:30:53 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Oct 2015 22:30:53 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
Message-ID: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The asyncio docs still use `yield from` and @asyncio.coroutine all over the place instead of async/await. It would be best to update the docs to follow best practices (unless there is some reason I can't think of as to why this hasn't happened yet).

----------
assignee: docs at python
components: Documentation
messages: 253636
nosy: brett.cannon, docs at python, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Use async/await through asyncio docs
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct 28 18:31:36 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Oct 2015 22:31:36 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446071496.46.0.816226934613.issue25501@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Oct 28 18:41:56 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Oct 2015 22:41:56 +0000
Subject: [docs] [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1446072116.23.0.78782978.issue25500@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think the documentation is wrong. Going all the way back to Python 2.7, you will see that importing a module emits IMPORT_NAME as the bytecode. That bytecode only looks for __import__ in the builtin  namespace: https://hg.python.org/cpython/file/2.7/Python/ceval.c#l2588 . That then calls PyImport_ImportModuleLevel(): https://hg.python.org/cpython/file/2.7/Python/bltinmodule.c#l49 . That then just ends up executing import.

If you look at PyImport_Import() in Python 2.7 that comes the closest to what the docs reference, but that still uses __builtins__.__import__ based on finding __builtins__ from the global namespace: https://hg.python.org/cpython/file/2.7/Python/import.c#l2825 . But that isn't directly called by import itself and is just a C-level API.

If you look in Python 3, then you will see that as far back as Python 3.3 the code in importlib is more or less the same: __import__ is used when importing a parent and then importlib is used for the rest: https://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py#l944 . This was introduced so that the accelerated C version of __import__ would be used to import the parent rather than automatically going down the pure Python path for stuff such as resolving names and such. This was never done to explicitly import using something defined in the globals namespace (although this does lead to supporting it).

And if you go all the way back to Python 3.0 you will notice that getting __import__ from the builtins namespace only has been in place: https://hg.python.org/cpython/file/3.0/Python/ceval.c#l1959 .

So I think the key point here is that the bytecode for IMPORT_NAME doesn't match the docs. So the question is do we want to add the feature to Python 3 to look for import in the globals or would we rather leave it as is and fix the docs?

----------
title: _find_and_load_unlocked doesn't always use __import__ -> docs claim __import__ checked for in globals, but IMPORT_NAME bytecode does not

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

From report at bugs.python.org  Wed Oct 28 19:13:11 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Oct 2015 23:13:11 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446073991.79.0.289009115065.issue25501@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It makes it more awkward to keep the asyncio docs in sync between 3.4 and 3.5. Also it makes copying examples harder for users who need compatibility with 3.4 or 3.3.

----------

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

From report at bugs.python.org  Wed Oct 28 19:15:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 23:15:46 +0000
Subject: [docs] [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1446074146.86.0.223912047638.issue25500@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fix the docs.

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

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

From report at bugs.python.org  Wed Oct 28 19:49:19 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Oct 2015 23:49:19 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446076159.1.0.240089883429.issue25501@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Also sphinx (pygments actually) still do not support async/await syntax highlighting yet.

----------
nosy: +asvetlov

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

From report at bugs.python.org  Wed Oct 28 19:56:24 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Oct 2015 23:56:24 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446076584.3.0.279554963401.issue25501@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

We have dropped 3.3 in aiohttp BTW.
Proper handling of resource leaks is too annoying without PEP 442 which don't crash with core dump starting from Python 3.4.1

----------

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

From report at bugs.python.org  Thu Oct 29 01:38:59 2015
From: report at bugs.python.org (Sworddragon)
Date: Thu, 29 Oct 2015 05:38:59 +0000
Subject: [docs] [issue25496] tarfile: Default value for compresslevel is not
 documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1446097139.71.0.29638095227.issue25496@psf.upfronthosting.co.za>


Sworddragon added the comment:

At tarfile, but the compresslevel argument is mentioned there but not its default value.

----------
title: Default value for compresslevel is not documented -> tarfile: Default value for compresslevel is not documented

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

From report at bugs.python.org  Thu Oct 29 02:17:25 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Oct 2015 06:17:25 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446099445.7.0.636492072308.issue25482@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The OP probably wants something like the Linux-specific signalfd() syscall.

----------

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

From report at bugs.python.org  Thu Oct 29 03:14:19 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 29 Oct 2015 07:14:19 +0000
Subject: [docs] [issue13828] Further improve casefold documentation
In-Reply-To: <1326992763.46.0.576190503242.issue13828@psf.upfronthosting.co.za>
Message-ID: <1446102859.11.0.133821459272.issue13828@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

I think the str.casefold() docs are fine as far as they go, rightly covering what it _does_ rather than _how_, yet providing a reference for the details. But what they lack is more complete information. For example I discovered this:

>>> x = "?les and shu?es"
>>> x
'?les and shu?es'
>>> x.casefold()
'files and shuffles'

In view of this I would add one sentence:

    In addition to lowercasing, this function also expands ligatures, for example, "?" becomes "fi".

----------
nosy: +mark

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

From report at bugs.python.org  Thu Oct 29 08:06:44 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 29 Oct 2015 12:06:44 +0000
Subject: [docs] [issue25509] PyImport_ImportModule inaccurately described
Message-ID: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>


New submission from Memeplex:

The documentation (for 3.5) states that "[PyImport_ImportModule] is a simplified interface to PyImport_ImportModuleEx()" but the current implementation calls PyImport_Import instead, which is a higher level interface that takes into account import hooks. Older versions of PyImport_ImportModule (say 2.0) did call PyImport_ImportModuleEx, but that's no longer the case.

The PyImport_Import* naming convention got a bit messy with the years and maybe I'm not understanding the intention quite well, but it seems to me that the documentation is outdated and that there is a change in semantics for PyImport_ImportModule.

----------
assignee: docs at python
components: Documentation
messages: 253674
nosy: docs at python, memeplex
priority: normal
severity: normal
status: open
title: PyImport_ImportModule inaccurately described
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 29 10:44:24 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 29 Oct 2015 14:44:24 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446129864.04.0.17027074771.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

> Benjamin Peterson added the comment:
> 
> The OP probably wants something like the Linux-specific signalfd() syscall.

Yes.

Long explanation:

I have an console text editor written in Python/curses(http://kaaedit.github.io/).

This editor didn't work with Python 3.5 because select.select() stop raising InterruptedError.

Following is sample code to reproduce. This code displays size of terminal. If you resize your terminal, screen is updated and new size is displayed.

---------------------------

import curses, select, sys

def main(stdscr):
    i=0
    while True:
        y, x = stdscr.getmaxyx()
        stdscr.addstr(i % 10, 0, "%d x:%d y:%d" % (i, x, y))
        i+=1
        stdscr.refresh()
        try:
            s=select.select([sys.stdin], [], [])   # wait for user input and some sockets.
        except InterruptedError:
            stdscr.addstr(i % 10, 0, "%d InterruptedError" % i)
            i+=1
            continue
        try:
            c=stdscr.get_wch()
        except curses.error:
            stdscr.addstr(i % 10, 0, "%d curses.error" % i)
            i+=1
            continue
        if c == 'q':
            break

curses.wrapper(main)

---------------------------

Resizing terminal generates SIGIWNCH signal. In Python 3.4, select.select() raises InterruptedError when the signal sent. Also, Ncurses library catches the signal and update internal data to reflect new terminal size.

To detect resizing in Python 3.5, I had to set signal handler for SIGWINCH as following sample. 

---------------
import curses, select, sys, signal, os

rfd, wfd = os.pipe()
os.set_blocking(wfd, False)

def f(*args): pass
signal.signal(signal.SIGWINCH, f)
signal.set_wakeup_fd(wfd)

def main(stdscr):
    i=0
    while True:
        y, x = stdscr.getmaxyx()
        stdscr.addstr(i, 0, "%d x:%d y:%d" % (i, x, y))
        i+=1
        stdscr.refresh()
        try:
            s=select.select([sys.stdin, rfd], [], [])
        except InterruptedError:
            stdscr.addstr(i, 0, "%d InterruptedError" % i)
            i+=1
            continue
        try:
            c=stdscr.get_wch()
        except curses.error:
            stdscr.addstr(i, 0, "%d curses.error" % i)
            i+=1
            continue
        if c == 'q':
            break

curses.wrapper(main)
-------------

This code doesn't display updated size of terminal because SIGWINCH signal is not sent to nurses library. I have to call curses.resizeterm() manually to tell new terminal size to nurses.

I don't know this is common situation or not, but In general, it is not safe to set signal handler when the signal is used by third-party library.

----------

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

From report at bugs.python.org  Thu Oct 29 11:28:51 2015
From: report at bugs.python.org (David Jones)
Date: Thu, 29 Oct 2015 15:28:51 +0000
Subject: [docs] [issue25511] multiprocessing pool blocks SIGTERM from being
 handled
Message-ID: <1446132531.63.0.0289004562765.issue25511@psf.upfronthosting.co.za>


New submission from David Jones:

This is probably related to #21913, but more specifically concerns the documentation. I have a sub process of a larger program that handles a SIGTERM sent by the main process for a clean shutdown. However, if I launch a parallel task in the sub process, via multiprocessing.Pool.imap_unordered, all signals are blocked until pool finishes running the task. 

If this isn't going to be fixed, then it ought to at least be clearly documented. It took a very long time to diagnose this problem. It requires a programmer to understand the underlying implementation of a high-level construct, thus defeating the purpose of using a high level construct.

Also, is there a way to work around this?

----------
assignee: docs at python
components: Documentation
messages: 253678
nosy: djones, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing pool blocks SIGTERM from being handled
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 29 12:27:14 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 29 Oct 2015 16:27:14 +0000
Subject: [docs] [issue17006] Add advice on best practices for hashing secrets
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1446136034.0.0.19384273561.issue17006@psf.upfronthosting.co.za>


Changes by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

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

From report at bugs.python.org  Thu Oct 29 12:27:27 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 16:27:27 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446136047.84.0.7324888002.issue25501@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Once 3.4.4 launches the need to keep the docs synced with a version that doesn't support async/await goes away. And worrying about 3.3 isn't necessary since asyncio was added in 3.4.

So once 3.4.4 is released and we close the 3.4 branch to bugfixes can we update the docs in asyncio and add a note at the top saying the examples all use async/await from 3.5 and if you need 3.4 compatibility to please look at the 3.4 docs? Otherwise how long do you want to wait until we can start using async/await in the documentation? My worry is that people are going to blindly copy the examples and tweak them for their needs since the asyncio docs are a bit dense and thus just simply overlook the fact that async/await exists.

----------

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

From report at bugs.python.org  Thu Oct 29 13:50:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 17:50:38 +0000
Subject: [docs] [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446141038.92.0.329536468194.issue25509@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Oct 29 13:51:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 17:51:55 +0000
Subject: [docs] [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446141115.61.0.977760571225.issue25509@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Semantic change was probably because of the lack of import hook support which is required since Python 3.3. So the docs just need to be fixed rather than the semantics.

----------

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

From report at bugs.python.org  Thu Oct 29 15:26:37 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Thu, 29 Oct 2015 19:26:37 +0000
Subject: [docs] [issue24778] mailcap.findmatch: document shell command
 Injection danger in filename parameter
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1446146797.06.0.358245124953.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

My patch for mailcap.py. Please check and apply my patch please.

1) I have removed the os.system() calls for security reasons.

2) New "findmtach_list()" function witch returns the commandline as a [list] witch can be passed to subprocess instead of passing it to os.system().

3) New run() function to execute the cmd_list with subprocess. 

4) The test() function now uses findmatch_list() and run() instead of the old findmatch() and os.system() calls.  

5) The subst() function is now shorter an does a quote(filename) when its replacing %s with a filename.

6) The "old" findmatch() function is still there if the user still likes to have the commandline as a "string". 
Attention ! With this old findmatch() function it's still possible that a shell command in the filename like '$(ls).txt' will be executed when the users passes the string to os.system() outside the mailcap script. Use findmatch() only for backwards compatibility.

7) Use the new findmatch_list() an run() for future projects.

8) Add 1)-7) to the docs

Thank you.

----------
Added file: http://bugs.python.org/file40897/mailcap patch.zip

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

From report at bugs.python.org  Thu Oct 29 16:12:28 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 29 Oct 2015 20:12:28 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446149548.48.0.382565913351.issue25501@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Honestly I think it's better if most people keep using coroutine/yield-from instead of async/await for a few more releases; their code will be more portable, since it takes forever to update old datacenters. We put in async/await with an eye towards the future. But we're keeping yield-from around for a long time too. And that's also why we support asyncio for 3.3.

----------

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

From report at bugs.python.org  Thu Oct 29 16:34:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 20:34:26 +0000
Subject: [docs] [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446150866.37.0.789777796122.issue25501@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Oct 29 18:09:31 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Thu, 29 Oct 2015 22:09:31 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446156571.19.0.0237866378849.issue25041@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Provided patch provides documentation for the AF_PACKET address_family.

----------
keywords: +patch
nosy: +Winterflower
Added file: http://bugs.python.org/file40898/af_packet_doc.patch

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

From report at bugs.python.org  Thu Oct 29 19:21:47 2015
From: report at bugs.python.org (Anne Rosa Wangnick)
Date: Thu, 29 Oct 2015 23:21:47 +0000
Subject: [docs] [issue11796] Comprehensions in a class definition mostly
 cannot access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1446160906.71.0.466072881851.issue11796@psf.upfronthosting.co.za>


Anne Rosa Wangnick added the comment:

With https://bugs.python.org/issue13557 closed, this one should be reopened to amend 6.2.8 Generator expressions: "[However, the leftmost for clause is immediately evaluated] (in the local context)[, so that an error produced by it can be seen ...]"

----------
nosy: +Anne Rosa Wangnick

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

From report at bugs.python.org  Thu Oct 29 23:04:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Oct 2015 03:04:45 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446174285.77.0.67042339296.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for bringing this up, it has often bugged me.

My understanding, based on the original wording and places where this is used, is that the data is often pre-processed into 57-byte chunks, rather than post-processing it. Maybe it is worthwhile restoring that info. It should help understanding the presence of the newline parameter (or why a newline is always added in 3.5).

Also, the link between RFC 4648 and this function could be made even more explicit. Maybe move ?as defined? into the first sentence, or change ?the Base64 output? to ?the function?s output?.

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

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

From report at bugs.python.org  Thu Oct 29 23:14:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2015 03:14:07 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446174847.48.0.547994124857.issue25482@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's very easy to get the same behaviour on Python 3.4 (without PEP 475) and Python 3.5 (with PEP 475). Just add the following code at the top of your example:
----
import signal

def sighandler(signum, frame):
    raise InterruptedError

signal.signal(signal.SIGWINCH, sighandler)
---

You can use any Python exception, not only InterruptedError.

PEP 475 only changes the behaviour on signals with an handler which doesn't raise an exception.

----------

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

From report at bugs.python.org  Thu Oct 29 23:33:43 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 30 Oct 2015 03:33:43 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446176023.24.0.0656408248728.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Thank you for good sample. This should be written in PEP 475.

But installing new signal handler can cause different behavior. 

As in my previous example, if other 3rd party libraries(ncurses in my case) need to handle the signal, signal is consumed by Python handler and not delivered to the library.

----------

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

From report at bugs.python.org  Fri Oct 30 03:11:22 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 30 Oct 2015 07:11:22 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1446189082.21.0.796005052677.issue18531@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

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

From berker.peksag at gmail.com  Fri Oct 30 03:15:14 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Fri, 30 Oct 2015 07:15:14 -0000
Subject: [docs] document AF_PACKET socket address format (issue 25041)
Message-ID: <20151030071514.31364.66989@psf.upfronthosting.co.za>


http://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst
File Doc/library/socket.rst (right):

http://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode131
Doc/library/socket.rst:131: - A tuple ``(interface, eth_prot, pkttype,
ha_type, addr, addr_len``, )
    addr_len``, )

should read

    addr_len)``

http://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode132
Doc/library/socket.rst:132: is used for the  :const:`AF_PACKET` address
family, where ``interface`` is a
Double space before :const:`AF_PACKET`.

http://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode132
Doc/library/socket.rst:132: is used for the  :const:`AF_PACKET` address
family, where ``interface`` is a
``interface`` -> *interface*

``eth_prot`` -> *eth_prot*

(same change for others)

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

From report at bugs.python.org  Fri Oct 30 03:17:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 30 Oct 2015 07:17:05 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446189425.07.0.534394686494.issue25041@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! The patch looks good to me. I left a few minor comments on Rietveld: http://bugs.python.org/review/25041/

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

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

From alec.nunn at gmail.com  Thu Oct 29 13:38:37 2015
From: alec.nunn at gmail.com (Alec Nunn)
Date: Thu, 29 Oct 2015 13:38:37 -0400
Subject: [docs] Typo In Code Example
Message-ID: <CABgbBqB9EDUm5Hefh_-_sx9CCWg8pSj8UhjxvNY7QTeO1-QBPQ@mail.gmail.com>

??
For the _readline_ module, there is a typo in the second code example,
starting with the documentation for Python 3.5 (I have also noticed it in
the documentation for the Python 3.6 (dev) documentation).

import atexitimport osimport *realine*histfile =
os.path.join(os.path.expanduser("~"), ".python_history")

Should be fixed to:

import atexitimport osimport *readline*histfile =
os.path.join(os.path.expanduser("~"), ".python_history")

Referenced URL(s):
- https://docs.python.org/3.5/library/readline.html
- https://docs.python.org/3.6/library/readline.html

-- 
??

Alec Nunn
?alec.nunn at gmail.com?
??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151029/dd8902af/attachment.html>

From yanzhaoxun at greendh.com  Fri Oct 30 04:17:22 2015
From: yanzhaoxun at greendh.com (=?UTF-8?B?6ZiO5YWG54+j?=)
Date: Fri, 30 Oct 2015 16:17:22 +0800 (CST)
Subject: [docs] =?utf-8?q?Bug_on_=22open=22_function?=
Message-ID: <153516745.3349577.1446193042031.JavaMail.xmail@wmthree-3>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20151030/dc6c5e82/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: open text failure.png
Type: image/png
Size: 47328 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20151030/dc6c5e82/attachment-0001.png>

From report at bugs.python.org  Fri Oct 30 06:02:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2015 10:02:26 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1446176023.24.0.0656408248728.issue25482@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa6kEqL+U7cnQtxs_VZeNLTLxf-X-2RZmfJE2GKeUyP6w@mail.gmail.com>


STINNER Victor added the comment:

> As in my previous example, if other 3rd party libraries(ncurses in my case) need to handle the signal, signal is consumed by Python handler and not delivered to the library.

In the Python signal handler, can't you call the ncurses function that
should be called when the terminal is resized?

----------

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

From report at bugs.python.org  Fri Oct 30 06:07:26 2015
From: report at bugs.python.org (Pavel)
Date: Fri, 30 Oct 2015 10:07:26 +0000
Subject: [docs] [issue25517] regex howto example in "Lookahead Assertions"
Message-ID: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>


New submission from Pavel:

The example advises ".*[.](?!bat$).*$" expression "to match filenames where the extension is not bat". But here is an example which passes such check:

>>> re.match("(.*)[.](?!bat$).*$", "test.a.bat")
<_sre.SRE_Match object at 0x7ff221996f30>

To my mind use of negative lookbehind expressions (not covered so far in the HOWTO) is better:

>>> re.match("(.*)[.].*(?<!.bat)$", "test.a.bat")
>>>

----------
assignee: docs at python
components: Documentation
messages: 253725
nosy: Pavel, docs at python
priority: normal
severity: normal
status: open
title: regex howto example in "Lookahead Assertions"
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct 30 07:07:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Oct 2015 11:07:05 +0000
Subject: [docs] [issue25517] regex howto example in "Lookahead Assertions"
In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>
Message-ID: <1446203225.24.0.14475077483.issue25517@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that lookbehind assertions still are not documented in Regular Expression HOWTO.

The example that demonstrates negative lookahead assertion is ".*[.](?!bat$)[^.]*$". But then we should explain why ".*" is changed to "[^.]*".

----------
nosy: +akuchling, georg.brandl, serhiy.storchaka
stage:  -> needs patch
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Oct 30 07:13:06 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 30 Oct 2015 11:13:06 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446203586.55.0.356333057399.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Yes, I can. So, for my custom text editor,  problem have solved already.

But I still think it is desirable for Python to have something like signalfd(),  because not all functions used in the signal handler of third party library can be called from user's Python script in general.

----------

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

From report at bugs.python.org  Fri Oct 30 07:29:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2015 11:29:12 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1446203586.55.0.356333057399.issue25482@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbbz3LAJx+g7QK7=u9vH3ts9FXmCQSxi65Sw-k8GfD6nw@mail.gmail.com>


STINNER Victor added the comment:

Atsuo Ishimoto added the comment:
> But I still think it is desirable for Python to have something like signalfd(),  because not all functions used in the signal handler of third party library can be called from user's Python script in general.

I don't think that you can use signalfd() in your case. When you use
signalfd(), signals must be blocked, so the signal handlers are *not*
called (not the Python signal handler, not the C signal handler, no
signal handler for the masked signals).

----------

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

From report at bugs.python.org  Fri Oct 30 07:39:35 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 30 Oct 2015 11:39:35 +0000
Subject: [docs] [issue25482] signal.set_wakeup_fd() doesn't work if the
 signal don't have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446205175.85.0.860687545067.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Ah, I didn't know it. Thank you for clarification.

----------

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

From report at bugs.python.org  Fri Oct 30 12:21:40 2015
From: report at bugs.python.org (Andrew Scheller)
Date: Fri, 30 Oct 2015 16:21:40 +0000
Subject: [docs] [issue25519] Minor difflib documentation bug
Message-ID: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>


New submission from Andrew Scheller:

In the documentation for difflib.HtmlDiff.__init__ there's a couple of references to ``ndiff()``. I believe these should be modified to :func:`ndiff` (as used elsewhere in the difflib documentation) so that they get nicely hyperlinked in the HTML documentation.

See e.g. https://docs.python.org/2/library/difflib.html#difflib.HtmlDiff.__init__ and https://docs.python.org/3/library/difflib.html#difflib.HtmlDiff.__init__
where 'ndiff()' isn't hyperlinked, and https://docs.python.org/3/library/difflib.html#difflib.restore where 'ndiff()' *is* hyperlinked.

----------
assignee: docs at python
components: Documentation
messages: 253743
nosy: docs at python, lurchman
priority: normal
severity: normal
status: open
title: Minor difflib documentation bug
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/issue25519>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:29:08 2015
From: report at bugs.python.org (Mouse)
Date: Fri, 30 Oct 2015 16:29:08 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446222548.62.0.494818619484.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

As far as I remember, the data was not "originally processed in 57-byte chunks". I've been around the first PEM and MIME standards and discussions (and code, though not in Python, which wasn't around then) to be in position to know. :)

Whether the user prefers to process data in chunks or not, is up to the user. 
Not to mention that PEM is long gone, and MIME also changed somewhat. 

The link between this function and RFC4648 can and should be more explicit, but I think just referring to it is enough. 

Do you have a recommendation for additional info to explain newline issues?

Yes, changing "Base64 output" to "function output" makes perfect sense.

Thanks!

----------

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

From zachary.ware+pydocs at gmail.com  Fri Oct 30 15:03:06 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 30 Oct 2015 14:03:06 -0500
Subject: [docs] Bug on "open" function
In-Reply-To: <153516745.3349577.1446193042031.JavaMail.xmail@wmthree-3>
References: <153516745.3349577.1446193042031.JavaMail.xmail@wmthree-3>
Message-ID: <CAKJDb-OyT+hNYdn_cKdj2zy=g5T8xoi2f=27DVuqkNxpDVYdJA@mail.gmail.com>

Hi,

On Fri, Oct 30, 2015 at 3:17 AM, ??? <yanzhaoxun at greendh.com> wrote:
> Dear Staff:
>
>    I encountered a bug on "open" function on my Office computer, Pentium
> E5700 with 2GB of memory in Windows 7 32bit
>
>    f = open("README.txt","r") should open the README file in Python
> directory, but it failed.
>
>    Attached is the screenshot of the problem. Hope it helps.

Firstly, this is not the correct place to report non-documentation
bugs.  This list is meant for discussion of the Python documentation.
Bug reports may be sent to python-list at python.org, or reported on
bugs.python.org.

However, this is not a bug.  Python is raising a FileNotFoundError
exception because it can't find the file you want, probably because
Python's current working directory is not what you expect.  Try
'import os;print(os.getcwd())' to see what Python's current working
directory is, or pass an absolute path to open() to open the file you
want.

I hope this message helps your understanding.  If you have further
questions about this, please direct them to python-list at python.org.

Regards,
-- 
Zach

From report at bugs.python.org  Fri Oct 30 18:50:38 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Oct 2015 22:50:38 +0000
Subject: [docs] [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446245438.49.0.294822901895.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was only referring to the original Python documentation and library. See the base64.encode() implementation for an example which does do this 57-byte pre-chunking. Simplified:

MAXLINESIZE = 76 # Excluding the CRLF
MAXBINSIZE = (MAXLINESIZE//4)*3  # 57
...
while True:
    s = input.read(MAXBINSIZE)
    if not s:
        break
    line = binascii.b2a_base64(s)
    output.write(line)

Here?s my attempt to rewrite the doc (3.6 version):

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

To be MIME-compliant, base 64 output should be broken into lines at most 76 characters long. One way to do this is to call this function with 57-byte chunks and ``newline=True``. Also, the original PEM context-transfer encoding limited the line length to 64 characters.
'''

But if PEM is long gone as you say, perhaps we don?t need that last sentence?

----------

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

From report at bugs.python.org  Fri Oct 30 19:31:12 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 23:31:12 +0000
Subject: [docs] [issue25519] Minor difflib documentation bug
In-Reply-To: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>
Message-ID: <1446247872.68.0.271057505448.issue25519@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Oct 30 19:42:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 23:42:03 +0000
Subject: [docs] [issue25519] Minor difflib documentation bug
In-Reply-To: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>
Message-ID: <20151030234200.100246.23245@psf.io>


Roundup Robot added the comment:

New changeset 4ed175ee3cca by Terry Jan Reedy in branch '2.7':
Issue #25519: Mark difflib.ndiff as a functions where not already.
https://hg.python.org/cpython/rev/4ed175ee3cca

New changeset b7686cb0b698 by Terry Jan Reedy in branch '3.4':
Issue #25519: Mark difflib.ndiff as a functions where not already.
https://hg.python.org/cpython/rev/b7686cb0b698

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

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

From report at bugs.python.org  Fri Oct 30 19:42:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 23:42:45 +0000
Subject: [docs] [issue25519] Minor difflib documentation bug
In-Reply-To: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>
Message-ID: <1446248565.77.0.610969106575.issue25519@psf.upfronthosting.co.za>


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


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

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

From vadmium+py at gmail.com  Sat Oct 31 00:01:45 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sat, 31 Oct 2015 04:01:45 -0000
Subject: [docs] document AF_PACKET socket address format (issue 25041)
Message-ID: <20151031040145.26364.22510@psf.upfronthosting.co.za>


https://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst
File Doc/library/socket.rst (right):

https://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode131
Doc/library/socket.rst:131: - A tuple ``(interface, eth_prot, pkttype,
ha_type, addr, addr_len``, )
Perhaps use the square bracket notation (as for AF_TIPC):

(ifname, proto[, pkttype[, hatype[, addr]]])

https://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode136
Doc/library/socket.rst:136: is an optional integer specifying the ARP
hardware type, ``addr`` and
Not sure but it might be more correct to refer to Linux?s ARPHRD_*
constants, some of which are ?dummy types for non-ARP hardware?.
Otherwise, clarify that this is internal and not in network byte-order,
as would be the case for a real ARP packet.

https://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode137
Doc/library/socket.rst:137: ``addr_len``  are optional arguments
specifying the physical address
Address length is implied in the length of ?addr?, right?

>>> s = socket(AF_PACKET, SOCK_RAW, proto=htons(3))
>>> s.getsockname()  # Only five parameters
('', 3, 0, 0, b'')
>>> s.bind(("wifi", 3, PACKET_HOST, 1, bytes(6), 6))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes at most 5 arguments (6 given)
>>> s.bind(("wifi", 3, PACKET_HOST, 1, bytes(6)))  # Length is implied

https://bugs.python.org/review/25041/diff/15849/Doc/library/socket.rst#newcode141
Doc/library/socket.rst:141: .. XXX document them!
Remove this

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

From report at bugs.python.org  Sat Oct 31 00:02:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 04:02:49 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446264169.64.0.0480173224324.issue25041@psf.upfronthosting.co.za>


Martin Panter added the comment:

Quickly looking through the history (annotate function on Mercurial web frontend):

* Revisions 3d4a7cd0bf17, c8ef864ba861 (2001): AF_PACKET support added on Linux. Partially documented in C comment and socket.bind() docstring. AF/PF_PACKET, PACKET_* constants also added.

* #947352 (Python 2.4), 8b3288f607e1: Support specifying hardware address, for sendto().

Here are some more things might be good to tease out:

1. Please don?t invent new parameter names without a good reason. I suggest (ifname, proto, pkttype, hatype, addr). These are already used in the bind() doc string, most are consistent with Linux?s struct sockaddr_ll fields, and ?proto? is consistent with Python?s socket() constructor.

2. There is an error message mentioning ?protoNumber? which could also be adjusted for consistency

3. When Python generates the ifname string, it uses the empty string for ifindex zero (matching any interface), although it does not look like parsing this back is supported

4. proto is endian-corrected, in contrast with Linux?s version being in network byte-order

5. Default pkttype is zero. This is equal to PACKET_HOST, so could be useful. Might also be worth changing the source code to explicitly use PACKET_HOST.

6. addr has to be a bytes-like object

7. Packet support is specific to Linux, and may not be compiled in

8. Existence of *_PACKET and PACKET_* constants

9. socket.bind() doc string needs updating since revision c8ef864ba861 (missing fifth parameter, addr)

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

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

From report at bugs.python.org  Sat Oct 31 07:40:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 11:40:02 +0000
Subject: [docs] [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1446291602.09.0.693117787277.issue25415@psf.upfronthosting.co.za>


Martin Panter added the comment:

If existing subclasses like FileIO call the base, that is an implementation detail. But custom subclasses of the Raw, Buffered, and Text base classes should not be prohibited from chain calling the base?s __init__() method, nor should they have to override __init__() if there is no special initialization to be done. For IOBase itself, I don?t see a strong argument either way, but it makes sense to keep it consistent with the other three base classes.

I propose this patch, which changes ?There is no public constructor? to ?The constructor accepts no arguments?. In my mind this blesses making custom subclasses, which already seems to be tested and used in practice.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.6
Added file: http://bugs.python.org/file40908/no-args.patch

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

From report at bugs.python.org  Sat Oct 31 08:32:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:32:10 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
Message-ID: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch generally changes ?a? to ?an? where appropriate in the main documentation, doc strings, source code comments, and a couple error messages in the test suite. Since it touches so many files, I thought it would be good to get a quick review.

----------
assignee: docs at python
components: Documentation
files: a-an.patch
keywords: patch
messages: 253784
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Correct "a" article to "an" article
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40909/a-an.patch

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

From report at bugs.python.org  Sat Oct 31 08:33:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:33:24 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446294804.36.0.418230725832.issue25523@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file40909/a-an.patch

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

From report at bugs.python.org  Sat Oct 31 08:34:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:34:01 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446294831.65.0.30808668818.issue25523@psf.upfronthosting.co.za>


Martin Panter added the comment:

Rebased so it should be reviewable

----------
Added file: http://bugs.python.org/file40910/a-an.patch

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

From report at bugs.python.org  Sat Oct 31 10:10:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Oct 2015 14:10:55 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446300654.98.0.906971171865.issue25523@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suppose that changes was generated by a script. But some changes looks not satisfying a simple rule.

In Doc/library/multiprocessing.rst, Doc/library/socket.rst, Doc/whatsnew/3.2.rst, Misc/HISTORY, Modules/_hashopenssl.c "a" is just deleted. Is it deliberately?

In Doc/library/smtplib.rst "a" is replaced to "an" before a word starting with consonant: SMTP. Is it correct?

Aren't files in Lib/test/decimaltestdata/ imported from external source? Then we shouldn't change them.

The rest of changes LGTM, but I'm not sure about mentioned above.

----------
nosy: +r.david.murray, serhiy.storchaka

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

From report at bugs.python.org  Sat Oct 31 10:52:37 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 31 Oct 2015 14:52:37 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446303157.69.0.787665294129.issue25523@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

> In Doc/library/smtplib.rst "a" is replaced to "an" before a word starting with consonant: SMTP. Is it correct?

One of the peculiriarities of the English language is that, in front of acronyms, you have two different ways to decided which to use between "a" and "an" - first (and probably what you thought), is to think of what the acronym means (or which letter it begins with). The other way, which Martin probably used, is to use what would sound be if it was said out loud, and "An ess-emm-tee-pee" sounds better overall.

In other words, both work, and it's down to personal preference. However, if we decide to use "an" here for this reason, it should (IMO) remain consistent across all of the documentation. I've only briefly looked over the patch as I have to head out soon, but I wanted to make this point anyway.

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

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

From report at bugs.python.org  Sat Oct 31 10:58:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:58:55 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446303535.66.0.264556725356.issue25523@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, those deletions are intentional, they make the English read better (to me as a native speaker, at least :)  As Emanuel said, the SMTP thing comes from reading it as an acronym, which is how I generally do it, and I suppose most people do.  Given how thorough Martin has been here, I'm guessing this was the one place that an wasn't used :)

This all looks good to me, except that I would rewrite

  and an isfile and isdir check on it

as

  and isfile and isdir checks on it

Agree with Serhiy's caveat about decimaltestdata.  Adding Mark to nosy to double check, but I don't think that file should be changed.

----------

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

From report at bugs.python.org  Sat Oct 31 10:59:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:59:16 +0000
Subject: [docs] [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446303556.62.0.867438102117.issue25523@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct 31 11:36:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Oct 2015 15:36:13 +0000
Subject: [docs] [issue13828] Further improve casefold documentation
In-Reply-To: <1326992763.46.0.576190503242.issue13828@psf.upfronthosting.co.za>
Message-ID: <1446305773.79.0.792292359439.issue13828@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> In addition to lowercasing, this function also expands ligatures, for example, "?" becomes "fi".

+1 I would have found that sentence to be helpful.

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

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

From berker.peksag at gmail.com  Sat Oct 31 17:56:31 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sun, 1 Nov 2015 00:56:31 +0300
Subject: [docs] Typo In Code Example
In-Reply-To: <CABgbBqB9EDUm5Hefh_-_sx9CCWg8pSj8UhjxvNY7QTeO1-QBPQ@mail.gmail.com>
References: <CABgbBqB9EDUm5Hefh_-_sx9CCWg8pSj8UhjxvNY7QTeO1-QBPQ@mail.gmail.com>
Message-ID: <CAF4280J1Mo+SsnUs1F2o_x-4Eyek25YaWb1FXDGsQeBjQUGwpg@mail.gmail.com>

On Thu, Oct 29, 2015 at 8:38 PM, Alec Nunn <alec.nunn at gmail.com> wrote:
> For the _readline_ module, there is a typo in the second code example,
> starting with the documentation for Python 3.5 (I have also noticed it in
> the documentation for the Python 3.6 (dev) documentation).

Hi Alec,

Thanks for the report! I've fixed it in
https://hg.python.org/cpython/rev/f884590ee620

--Berker

From report at bugs.python.org  Sat Oct 31 21:58:58 2015
From: report at bugs.python.org (Memeplex)
Date: Sun, 01 Nov 2015 01:58:58 +0000
Subject: [docs] [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446343138.26.0.104349348162.issue25509@psf.upfronthosting.co.za>


Memeplex added the comment:

Brett, I'm not sure about that, notice that the "import hook" as is mentioned in the docs is just the current __import__ in the builtins module (which could have been replaced and in this sense would be a "hook") but not proper import hooks. I think the original distinction between PyImport_ImportModule and PyImport_Import is still sensible today. Originally PyImport_ImportModule directly called the import machinery, while PyImport_Import called it indirectly through builtins.__import__ (which could have been replaced). Now, for some reason, for good or for bad, PyImport_ImportModule also goes through builtins.__import__. The documentation is wrong but what is the fix? Revert PyImport_ImportModule or redocument it?

----------

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

From report at bugs.python.org  Sat Oct 31 23:01:37 2015
From: report at bugs.python.org (Memeplex)
Date: Sun, 01 Nov 2015 03:01:37 +0000
Subject: [docs] [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446346897.84.0.676231747221.issue25509@psf.upfronthosting.co.za>


Memeplex added the comment:

Well it's like that since 2.1 so I guess the doc is wrong indeee.

----------

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